File: rfc2126.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1403 lines) | stat: -rw-r--r-- 51,032 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403






Network Working Group                                     Y. Pouffary
Request for Comments: 2126              Digital Equipment Corporation
Category: Standards Track                                    A. Young
                                                     ISODE Consortium
                                                           March 1997


               ISO Transport Service on top of TCP (ITOT)

Status of the Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document is a revision to STD35, RFC1006 written by Marshall T.
   Rose and Dwight E. Cass. Since the release of RFC1006 in May 1987,
   much experience has been gained in using ISO transport services on
   top of TCP. This document refines the protocol and will eventually
   supersede RFC1006.

   This document describes the mechanism to allow ISO Transport Services
   to run over TCP over IPv4 or IPv6. It also defines a number of new
   features, which are not provided in RFC1006.

   The goal of this version is to minimise the number of changes to
   RFC1006 and ISO 8073 transport protocol definitions, while maximising
   performance, extending its applicability and protecting the installed
   base of RFC1006 users.

Table of Contents

   1. Introduction, Motivation.....................................2
   2. The Model....................................................3
   2.1 ISO Transport Model.........................................3
   2.2 ISO Transport over TCP (ITOT) Model.........................4
   2.3 Overview of Protocol and Service............................5
   3 Service Definition............................................5
   3.1 Transport Service Definition................................5
   3.1.1 Transport Service Definition Primitives...................6
   3.2 Network Service Definition..................................7
   3.2.1 ISO 8348 CONS primitives..................................7
   3.2.2 TCP Service primitives....................................8
   3.2.3 Mapping TCP as a Network Service Provider.................8



Pouffary & Young            Standards Track                     [Page 1]

RFC 2126              ISO Transport on top of TCP             March 1997


   3.2.3.1 Network Connection Establishment........................8
   3.2.3.2 Network Data Transfer...................................9
   3.2.3.3 Network Connection Release.............................10
   4. Transport Protocol Specification............................10
   4.1 Class 0 over TCP...........................................10
   4.1.1 Connection Establishment.................................11
   4.1.2 Data Transfer............................................11
   4.1.3 Connection Release.......................................11
   4.2 Class 2 over TCP...........................................12
   4.2.1 Connection Establishment.................................12
   4.2.2 Data Transfer............................................13
   4.2.3 Connection Release.......................................15
   4.3 TPKT Packet Format.........................................15
   5. Address representations.....................................16
   5.1 String representation of ITOT access point addresses.......17
   5.2 OSI Network Address encoding...............................17
   6. Notes to Implementors.......................................17
   6.1 TCP Connection Establishment...............................17
   6.2 TCP Data transfer..........................................17
   6.3 Class negotiation..........................................18
   6.4 Default maximum TPDU size..................................18
   6.5 Class 0 TPDU bit encoding..................................18
   6.6 Class 2 Options............................................19
   6.7 Class 2 Expedited Data Acknowledgement.....................21
   6.8 Class 2 Normal Data and Expedited Data handling............21
   6.9 Class 2 Forward Connection procedure.......................22
   6.10 TPKT......................................................22
   7. Rationale - Interoperability with RFC1006...................22
   8. Security Considerations.....................................23
   Acknowledgements...............................................23
   References.....................................................23
   Authors' Addresses.............................................25

1. Introduction, Motivation

   There are two basic approaches which can be taken when "porting" ISO
   applications to TCP/IP ([RFC793],[RFC791]) and IPv6 [IPV6]
   environments. One approach is to port each individual application
   separately, developing local protocols on top of TCP. A second
   approach is based on the notion of layering the ISO Transport Service
   over TCP/IP. This approach solves the problem for all applications
   which use the ISO Transport Service. This document describes the
   second approach.

   The protocol described in this memo is based on the observation that
   both the Internet Protocol Suite and the ISO Protocol Suite are
   layered systems.  A key aspect of the layering principle is that of
   layer-independence.  The concept of layer-independence means that if



Pouffary & Young            Standards Track                     [Page 2]

RFC 2126              ISO Transport on top of TCP             March 1997


   one preserves the services offered by a particular layer (the
   Service-Provider) then the Service-User at that layer is completely
   unaffected by changes in the underlying layers or by the protocol
   used within the layer.

   This document defines a Transport Service which appears to be
   identical to the Services and Interfaces offered by the ISO Transport
   Service Definition [ISO8072], but which will in fact implement the
   ISO Transport Protocol [ISO8073] on top of TCP/IP (IPv4 or IPv6),
   rather than the ISO Network Service [ISO8348].

   The basis of this document is STD35, RFC1006 [RFC1006] written by
   Marshall T. Rose and Dwight E. Cass and it defines two transport
   classes of service.  Transport Class 0 refines and supersedes the
   RFC1006 protocol and is aimed at preserving the RFC1006 installed
   base.  Transport Class 2 defines a number of new features which are
   not provided in RFC1006, such as independence of Normal and Expedited
   Data channels and Explicit Transport Disconnection. These new
   features are largely based on RFC1859 [RFC1859] and extend the
   applicability of RFC1006 to new groups of applications.

   This document specifies changes to the standards mentioned above and
   must be read in the context of the above mentioned standards. It will
   not be meaningful on its own.

   The 'well known' TCP port 102 is reserved for hosts which implement
   the Protocol described in this document. Note that the Protocol does
   not mandate the use of TCP port 102 for all connections.

2. The Model

   This section describes the differences between the model used by the
   ISO Transport and that described in this document.

2.1 ISO Transport Model

   The ISO 8072 standard describes the ISO Transport Service Definition
   (TS).  The ISO Transport Service Definition describes the services
   offered by the Transport Service Provider and the interfaces used to
   access these services.

   The ISO 8073 standard describes the ISO Transport Protocol
   Specification (TP).  The ISO Transport Protocol specifies common
   encoding rules and a number of classes of transport protocol
   procedure which can be used with different network Quality of
   Service.





Pouffary & Young            Standards Track                     [Page 3]

RFC 2126              ISO Transport on top of TCP             March 1997


   The ISO 8348 standard describes the ISO Network Service Definition
   (NS).  The ISO Network Service Definition describes the services
   offered by the network service Provider and the interfaces used to
   access these services.

   The ISO Network Service specifies two type of service:

   - Connection Oriented Network Service (CONS)

   - ConnectionLess Network Service (CLNS)

   The ISO Transport Protocol specifies five classes of procedures when
   operating over CONS and one class of procedure when operating over
   CLNS.

   The relationship of these ISO standards is illustrated below:

            Transport Service User
              |
              |-ISO Transport Service Definition [ISO8072]
              |
         +--------------------------------------------------+
         |  Transport Service Provider                      |
         |  ISO Transport Protocol Specification [ISO8073]  |
         +--------------------------------------------------+
              |
              |-ISO Network Service Definition [ISO8348]
              |

2.2 ISO Transport over TCP (ITOT) Model

   This document defines a model which provides ISO Transport Service,
   with minor extensions, running over TCP.

   The ISO 8072 Transport Service is supported with minor modifications.
   See section 3.1.

   The ISO 8073 Transport Protocol with some modifications is used to
   provide the modified Transport Service.

   The Transmission Control Protocol is used in place of the ISO 8348 to
   provide a CONS like service. See section 4.

   This document specifies a simple encapsulation mechanism between the
   modified ISO 8073 Transport Protocol and the TCP.






Pouffary & Young            Standards Track                     [Page 4]

RFC 2126              ISO Transport on top of TCP             March 1997


   ISO 8073 Transport Protocol specifies five classes when operating
   over ISO 8348 CONS. This document specifies how to operate class 0
   and 2 over TCP. This document does not prevent use of other classes
   from operating over TCP, but their specification is beyond the scope
   of this document.

   The relationship of these standards is illustrated below:

            Transport Service User
              |
              |-ISO Transport Service (modified)
              |
         +--------------------------------------------------+
         |  Transport Service Provider                      |
         |  ISO Transport Protocol (modified) Specification |
         +--------------------------------------------------+
              |
              |-TCP as a Connection Oriented Network Service
              |

2.3 Overview of Protocol and Service

   This document defines use of the ISO Transport Protocol (with some
   extensions) running over TCP. Two variants of the protocol are
   defined, "Class 0 over TCP" and "Class 2 over TCP", which are based
   closely on the ISO Transport Class 0 and 2 Protocol.

   Section 3 defines the Service offered to the Transport User by this
   protocol, and shows the differences from the ISO Transport Service.
   The mapping between the Service primitives in the ISO Network Service
   and TCP are defined. Section 4 defines the Transport Protocol.

3 Service Definition

   This section describes the Transport Service offered to the Transport
   User.  It also defines the mapping between the Network Service
   Definition and the TCP Service Definition.

3.1 Transport Service Definition

   ISO 8072 Transport Service is supported with the following
   extensions:

   - Use of Quality of Service parameter is not defined

   - Access to Non-disruptive Transport Disconnection





Pouffary & Young            Standards Track                     [Page 5]

RFC 2126              ISO Transport on top of TCP             March 1997


3.1.1 Transport Service Definition Primitives

   Information is transferred to and from the TS-User in the Transport
   Service primitives listed below:

   Actions

      T-CONNECT.REQUEST
         - a TS-User indicates that it wants to establish transport
           connection

      T-CONNECT.RESPONSE
         - a TS-User indicates that it will honour the request

      T-DISCONNECT.REQUEST
         - a TS-User indicates that the transport connection is to
           be closed

      T-DATA.REQUEST
         - a TS-User sends data

      T-EXPEDITED DATA.REQUEST
         - a TS-User sends "expedited" data

   Events

      T-CONNECT.INDICATION
         - a TS-User is notified that a transport connection
           establishment is in progress

      T-CONNECT.CONFIRMATION
         - a TS-User is notified that the transport connection has been
           established

      T-DISCONNECT.INDICATION
         - a TS-User is notified that the transport connection is closed

      T-DATA.INDICATION
         - a TS-User is notified that data can be read from the transport
              connection

      T-EXPEDITED_DATA.INDICATION
         - a TS-User is notified that expedited data can be read from
           the transport connection







Pouffary & Young            Standards Track                     [Page 6]

RFC 2126              ISO Transport on top of TCP             March 1997


3.2 Network Service Definition

   This section describes how TCP is used to provide ISO 8348 CONS.

3.2.1 ISO 8348 CONS primitives

   Information is transferred to and from the NS-provider in the Network
   Service Primitives listed below:

   Actions

      N-CONNECT.REQUEST
         - a NS-user indicates that it wants to establish a network
           connection

      N-CONNECT.RESPONSE
         - a NS-user indicates that it will honour the request

      N-DISCONNECT.REQUEST
         - a NS-user indicates that the network connection is to be
           closed

      N-DATA.REQUEST
         - a NS-user sends data

      N-EXPEDITED_DATA.REQUEST
         - a NS-user sends "expedited" data

   Events

      N-CONNECT.INDICATION
         - a NS-user is notified that a network connection establishment
           is in progress

      N-CONNECT.CONFIRMATION
         - a NS-user is notified that the network connection has been
           established

      N-DISCONNECT.INDICATION
         - a NS-user is notified that the network connection is closed

      N-DATA.INDICATION
         - a NS-user is notified that data can be read from the network
           connection

      N-EXPEDITED_DATA.INDICATION
         - a NS-user is notified that expedited data can be read from
           the connection



Pouffary & Young            Standards Track                     [Page 7]

RFC 2126              ISO Transport on top of TCP             March 1997


3.2.2 TCP Service primitives

   The mapping between, ISO 8348 CONS primitives and TCP Service
   primitives, defined in this document assumes that the TCP offers the
   following service primitives:

   Actions

      TCP-LISTEN_PORT
         - PASSIVE open on given port

      TCP-OPEN_PORT
         - ACTIVE open to the given port

      TCP-READ_DATA
        - data is read from the connection

      TCP-SEND_DATA
        - data is sent on the connection

      TCP-CLOSE
        - the connection is closed (pending data is sent)

   Events

      TCP-CONNECTED
        - open succeeded (either ACTIVE or PASSIVE)

      TCP-CONNECT_FAIL
        - ACTIVE open failed

      TCP-DATA_READY
        - Data can be read from the connection

      TCP-ERRORED
        - the connection has errored and is now closed

      TCP-CLOSED
        - an orderly disconnection has started

3.2.3 Mapping TCP as a Network Service Provider

3.2.3.1 Network Connection Establishment

   In order to perform a N-CONNECT.REQUEST action, the TS-Provider
   performs a TCP-OPEN_PORT to the desired IPv4 or IPv6 address using
   the selected TCP port. When the TCP signals either success or
   failure, this results in an N-CONNECT.INDICATION action.



Pouffary & Young            Standards Track                     [Page 8]

RFC 2126              ISO Transport on top of TCP             March 1997


   In order to await a N-CONNECT.INDICATION event, a server performs a
   TCP-LISTEN_PORT to the selected TCP port.  When a client successfully
   connects to this port, the TCP-CONNECTED event occurs and an implicit
   N-CONNECT.RESPONSE action is performed.

   Mapping parameters between the TCP service and the ISO 8348 CONS
   service is done as follow:

   Network Service                 TCP
   ---------------                 ---
   CONNECTION ESTABLISHMENT

           Called address          server's IPv4 or IPv6 address
                                   and TCP port number.

           Calling address         client's IPv4 or IPv6 address

           all others parameters   ignored

   Please also refer to 'Notes to Implementors' section 6.1.

   TCP port 102 is reserved for implementations conforming to this
   specification.  Use of any TCP port is conformant to this
   specification.

3.2.3.2 Network Data Transfer

   In order perform a N-DATA.REQUEST action, the TS-provider constructs
   the desired transport protocol data unit (TPDU), encapsulates the
   TPDU in a discrete unit called TPKT and uses the TCP-SEND_DATA
   primitive.  Please also refer to 'Notes to Implementors' section 6.2.

   In order to trigger a N-DATA.INDICATION action, the TCP indicates
   that data is ready through TCP-DATA_READY event and a TPKT is read
   using the TCP-READ_DATA primitive.

   Mapping parameters between the TCP service and the ISO 8348 CONS
   service is done as follow:

   Network Service                 TCP
   ---------------                 ---
   DATA TRANSFER

           NS User Data (NSDU)     DATA







Pouffary & Young            Standards Track                     [Page 9]

RFC 2126              ISO Transport on top of TCP             March 1997


3.2.3.3 Network Connection Release

   In order to perform an N-DISCONNECT.REQUEST action, the TS-provider
   simply closes the TCP connection through TCP-CLOSE primitive.

   In order to trigger a N-DISCONNECT.INDICATION, the TCP indicates that
   the connection has been closed through TCP-CLOSE event.  If the TCP
   connection has failed the TCP indicates that the connection has been
   closed through TCP-ERRORED event, this trigger a N-
   DISCONNECT.INDICATION.

   Mapping parameters between the TCP service and the ISO 8348 CONS
   service is done as follow:

   Network Service                 TCP
   ---------------                 ---
   CONNECTION RELEASE

           all parameters          ignored

4. Transport Protocol Specification

   ISO 8073 Transport Protocol Classes 0 and 2 are supported with
   extensions as defined in each subsections below.

   A Transport Protocol class is selected for a particular transport
   connection based on the requirements of the TS-User.

   ISO 8073 Transport Protocol exchanges information between peers in
   discrete units of information called transport protocol data units
   (TPDU). The protocol defined in this document encapsulates these
   TPDUs in discrete units termed Packets (TPKT).

   This document mandates the implementation of ISO 8073 Transport
   Protocol options negotiation (which includes class negotiation).

   Please refer to 'Notes to Implementors' section 6.3 with respect to
   Class negotiation and to the 'Rationale' section 7. with respect to
   Interoperability with RFC1006.

4.1 Class 0 over TCP

   Class 0 provides the functions needed for connection establishment
   with negotiation, data transfer with segmentation, and protocol error
   reporting.  It provides Transport Connection with flow control based
   on that of the NS-provider (TCP).  It provides Transport
   Disconnection based on the NS-provider Disconnection.




Pouffary & Young            Standards Track                    [Page 10]

RFC 2126              ISO Transport on top of TCP             March 1997


   Class 0 is suitable for data transfer with no Explicit Transport
   Disconnection.

4.1.1 Connection Establishment

   The principles used in connection establishment are based upon those
   described in ISO 8073, with the following extensions:

   - Connect Data may be exchanged using the user data fields
     of Connect Request (CR) and Connect Confirm (CC) TPDUs

   - Use of "Expedited Data Transfer Service" may be negotiated
     using the negotiation mechanism specified in ISO 8073. The
     default is to not use "Expedited Data Transfer Service".

   - Non-standard TPDU size may be negotiated using the negotiation
     mechanism specified in ISO 8073. The maximum TPDU size is 65531
     octets. The Default maximum TPDU size is 65531 octets.
     Please refer to 'Notes to Implementors' section 6.4.

4.1.2 Data Transfer

   The elements of procedure used during transfer are based upon those
   presented in ISO 8073, with the following extension:

      - Expedited Data may be supported (if negotiated during connection
        establishment) by sending the defined Expedited Data (ED) TPDU.

   The ED TPDU is sent inband on the same TCP connection as all of the
   other TPDUs.

   To support Expedited Data a non-standard TPDU is defined. The format
   used for the ED TPDU is nearly identical to the format for the Normal
   Data (DT) TPDU. The only difference between ED TPDU and DT TPDU is
   that the value used for the TPDU code is ED and not DT. The size of a
   Expedited Data user data field is 1 to 16 octets.

   For TPDU bit encoding please refer to 'Notes to Implementors' section
   6.5.

4.1.3 Connection Release

   The elements of procedure used during a connection release are
   identical to those presented in ISO 8073.

   Transport Disconnection is based on the NS-provider (TCP)
   Disconnection and is therefore disruptive.




Pouffary & Young            Standards Track                    [Page 11]

RFC 2126              ISO Transport on top of TCP             March 1997


4.2 Class 2 over TCP

   Class 2 provides the functions needed for connection establishment
   with negotiation, data transfer with segmentation, and protocol error
   reporting.  It provides Transport Connection with flow control based
   on that of the NS-provider (TCP). It provides Explicit Transport
   Disconnection.

   Class 2 is suitable when independence of Normal and Expedited Data
   channels are required or when Explicit Transport Disconnection is
   needed.

4.2.1 Connection Establishment

   The principles used in connection establishment are based upon those
   described in ISO 8073, with the following extensions:

   - Connection Request and Connection Confirmation TPDUs may
     negotiate use of "Transport Expedited Data Transfer" service.
     "Transport Expedited Data Transfer" service is selected
     by setting bit 1 of the "Additional Option" parameter,
     and is negotiated using the mechanism specified in ISO 8073.

     The default is to not use "Transport Expedited Data Transfer
     Service".

   - Connection Request and Connection Confirmation TPDUs may
     negotiate use of "Expedited Data Acknowledgement".
     "Expedited Data Acknowledgement" is selected by setting
     bit 6 of the "Additional Option" parameter, and is
     negotiated using the mechanism specified in ISO 8073.

     The default is to not use "Expedited Data Acknowledgement"
     for Expedited Data transfer.

   - Connection Request and Connection Confirmation TPDUs may
     negotiate use of the "Non-blocking Expedited Data" service.
     "Non-blocking Expedited Data" is selected by setting
     bit 7 of the "Additional Option" parameter, and is
     negotiated using the mechanism specified in ISO 8073.

     The default is to not use the "Non-blocking Expedited
     Data" service.

   - Connection Request and Connection Confirmation TPDUs may
     negotiate use of either "Forward Connection (Splitting
     and Recombining)" or "Reverse Connection" procedure for
     Expedited Data transfer.



Pouffary & Young            Standards Track                    [Page 12]

RFC 2126              ISO Transport on top of TCP             March 1997


     Use of "Forward Connection" or use of "Reverse Connection"
     procedure is selected by setting bit 4 of the "Additional
     Option" parameter, and is negotiated using the mechanism
     specified in ISO 8073.

     The default is to use "Forward Connection" procedure for
     Expedited Data transfer.

   - Connection Request and Connection Confirmation TPDUs must not
     negotiate the use of "Explicit Flow Control".

   - Non-standard TPDU size may be negotiated using the negotiation
     mechanism specified in ISO 8073. The maximum TPDU size is 65531
     octets. The default maximum TPDU size is 65531 octets.
     Please refer to 'Notes to Implementors' section 6.4.

   In the absence of a Flow Control policy, the use of ISO 8073
   Multiplexing procedure lead to degradation of the quality of service.
   The Protocol defined in this document does not supported
   Multiplexing.

   For the values of the "Additional Option" parameter please refer to
   'Notes to Implementors' section 6.6.

   For Class 2 options Profile please also refer to 'Notes to
   Implementors' section 6.6.

4.2.2 Data Transfer

   The elements of procedure used during transfer are based upon those
   presented in ISO 8073, with the following extensions:

   - Expedited Data may be supported (if negotiated during connection
     establishment) by sending Expedited Data (ED) TPDU.

   - "Expedited Data Acknowledgement" may be supported (if negotiated
     during connection establishment) by sending Expedited Data
     Acknowledgement (EA) TPDU.

     When using "Expedited Data Acknowledgement", ED TPDUs require
     acknowledgement, and once an ED TPDU is transmitted no further
     DT/ED TPDUs may be sent until the outstanding ED TPDU has been
     acknowledged.

     When non-use of "Expedited Data Acknowledgement" has been
     negotiated, ED TPDUs require no acknowledgement, and further DT/ED
     TPDUs may be sent immediatly.




Pouffary & Young            Standards Track                    [Page 13]

RFC 2126              ISO Transport on top of TCP             March 1997


     Please refer to 'Notes to Implementors' section 6.7 and section
     6.8.

   - "Non-blocking Expedited Data" service may be supported (if
     negotiated during connection establishment).

     When using "Non-blocking Expedited Data" service, the sender of an
     ED TPDU shall send the ED TPDU on both the Normal Data and
     Expedited Data TCP connections. Transmission of subsequent DT TPDU
     will not be interrupted.  The receiver of ED TPDU counts how many
     ED TPDU it has seen on each TCP connection, and will only deliver
     to the TS-User the ED TPDU from the TCP connection with the higher
     count.

     When non-use of "Non-blocking Expedited Data" has been negotiated,
     ED TPDUs will not be duplicated.

     Please refer to 'Notes to Implementors' section 6.7 and section
     6.8.

   - For Expedited Data transfer, there are two possible
     procedures for the establishment and assignment of the Expedited
     Data TCP connection. Which one is used is negotiated during
     connection establishment.

     Both the "Forward Connection" procedure and "Reverse Connection"
     procedure guarantee independence of the Normal Data TCP connection
     from the Expedited Data TCP connection. They also ensure that a
     busy Normal Data TCP connection cannot block an Expedited Data TCP
     connection.

     The Expedited Data TCP connection created by either procedure must
     be between the same pair of hosts as the Normal Data TCP
     connection, must not be shared among Transport Connections, and
     must remain established until the Transport Connection is
     terminated, at which time it must be closed.

     TCP connections created for Expedited Data transfer should also use
     the TCP primitives defined in this document.

     The Forward Connection (Splitting and Recombining) procedure is
     defined in ISO 8073. This procedure allows a transport connection
     to make use of multiple TCP connections. Please refer to 'Notes to
     Implementors' section 6.9.

     The Reverse Connection procedure is not defined in ISO 8073.  When
     using the Reverse Connection procedure the initiator of a Transport
     Connection creates a Normal Data TCP connection using an



Pouffary & Young            Standards Track                    [Page 14]

RFC 2126              ISO Transport on top of TCP             March 1997


     arbitrarily-chosen local TCP port 'x' and a known remote TCP port
     (either the ITOT well-known port, or some other). The initiator
     listens for an incoming TCP connection on the TCP port 'x'. The
     responder of the Transport Connection must create a second TCP
     connection (to be used for Expedited Data) using an arbitrarily-
     chosen local TCP port 'y' and the remote TCP port 'x' , before it
     can issue a CC TPDU on the Normal Data TCP connection. The
     initiator need not listen for further TCP connections on port 'x'
     after the Expedited Data TCP connection is established.

4.2.3 Connection Release

   The elements of procedure used during a connection release are based
   upon those described in ISO 8073. A connection can be terminated by
   the TS-user in one of two ways:

   - Disruptive Disconnect

   - Non-Disruptive Disconnect

   Disconnect Request (DR) and Disconnect Confirm (DC) TPDUs are
   exchanged in both cases. The DR TPDU carries a Reason code indicating
   the reason for the Disconnection.

   Disruptive Disconnect specifies that all TPDUs still at the source
   are not required to be sent to the destination before the connection
   is disconnected. The DR Reason code is normal (80 hex).

   Non-Disruptive Disconnect specifies that all TPDUs already given to
   the local TS-provider must be delivered to the remote TS-user, before
   the connection is disconnected. The DR Reason code is normal (80 hex)
   with Additional Information parameter value set to 80 hex.

4.3 TPKT Packet Format

   A fundamental difference between the TCP and the ISO Network Service
   expected by ISO Transport is that the TCP manages a continuous stream
   of octets, with no explicit boundaries.

   ISO Transport expects information to be sent and delivered in
   discrete objects termed Network Service Data Units (NSDU). Although
   ISO Transport allows combination of more than one TPDU inside a
   single NSDU for the purposes of discussion an NSDU is identical to a
   TPDU. Please refer to ISO 8073 for the valid set of concatenated
   TPDUs.






Pouffary & Young            Standards Track                    [Page 15]

RFC 2126              ISO Transport on top of TCP             March 1997


   The protocol described by this memo uses a simple packetization
   scheme in order to delimit TPDU.  Each packet (TPKT), is viewed as an
   object of variable length composed of an integral number of octets.

   A TPKT consists of two part:

   - a Packet Header

   - a TPDU.

   The format of the Packet Header is constant regardless of the type of
   TPDU. The format of the Packet Header is as follows:

   +--------+--------+----------------+-----------....---------------+
   |version |reserved| packet length  |             TPDU             |
   +----------------------------------------------....---------------+
   <8 bits> <8 bits> <   16 bits    > <       variable length       >

   where:

   - Protocol Version Number
     length: 8 bits
     Value:  3

   - Reserved
     length: 8 bits
     Value:  0 - (See 'Notes to Implementors' section 6.10)

   - Packet Length
     length: 16 bits
     Value:  Length of the entire TPKT in octets, including Packet
             Header

   - TPDU
     ISO Transport TPDU as defined in ISO 8073 and as defined in this
     document.

5. Address representations

   It is desirable to be able to represent ITOT access point addresses
   as:

      - Printable strings

      - OSI Network Addresses (often known as NSAP addresses
        or simply NSAPAs)

   This section defines the formats which MUST be used in each case.



Pouffary & Young            Standards Track                    [Page 16]

RFC 2126              ISO Transport on top of TCP             March 1997


5.1 String representation of ITOT access point addresses

   RFC1278 [RFC1278] defines a general string representation for OSI
   Presentation Addresses, including specific reference to RFC1006
   addresses which encapsulate IPv4 addresses. RFC1278 is also
   applicable to ITOT addresses which encapsulate IPv4 addresses.

   This RFC is currently being updated to define a string representation
   for ITOT addresses which encapsulate IPv6 addresses.

   ITOT access point address string representation specify an IP address
   (IPv4 or IPv6) and an optional TCP port number.

5.2 OSI Network Address encoding

   RFC1277 [RFC1277] defines a general mechanism to encode addressing
   information within OSI Network Addresses (NSAPA), including specific
   reference to RFC1006 using IPv4. RFC1277 is also applicable to ITOT
   addresses using IPv4.

   The RFC "IPv6 addresses inside an NSAPA" [IPv6] defines general
   mechanisms for the support of NSAP addressing in an IPv6 network. It
   also defines how to embed an IPv6 address inside a OSI NSAP address.

   This RFC is applicable to ITOT addresses using IPv6. For ITOT
   addresses, the default selector of the NSAPA is defined to have the
   value '10000000'B.

   It should be noted that given that an IPv6 addresses can encode IPv4
   addresses, this format can also encode ITOT addresses using IPv4.

6. Notes to Implementors

6.1 TCP Connection Establishment

   Implementors should be aware that ISO transport protocols assume that
   they will be told by the network service provider (in this case
   TCP/IP) when the network connection being used to transmit their
   TPDUs is unexpectedly terminated.  It is therefore strongly suggested
   that the TCP keep alive mechanism be selected, as this ensures
   reporting of network connection loss.

6.2 TCP Data transfer

   For performance reason it is suggested that the Nagle algorithm [RFC
   896] be disabled (using the TCP_NODELAY socket option). This feature
   allows TPKT data to be sent without delay.




Pouffary & Young            Standards Track                    [Page 17]

RFC 2126              ISO Transport on top of TCP             March 1997


6.3 Class negotiation

   The principle used in Class negotiation is identical to those
   described in ISO 8073. Class and options are negotiated during
   Connection establishment. The choice made by the Transport will
   depend upon the TS-User requirements as expressed via T-CONNECT
   service primitives.

   The initiator of the Transport Connection proposes a preferred class
   and may propose an alternative class.

   The responder selects one class defined in the table below.

   If the preferred class is not selected then on receipt of the connect
   confirm TPDU the initiator adjusts its operation according to the
   class selected.

   +---------------------------------------------+----------------------+
   |           Proposed in CR TPDU               |      CC TPDU         |
   |                                             |                      |
   |Preferred class     |    Alternative class   |      Response        |
   +--------------------+------------------------+----------------------+
   |                    |                        |                      |
   |class 0             |    none                |      class 0         |
   |                    |                        |                      |
   |class 2             |    class 0             |      class 2 or 0    |
   |                    |                        |                      |
   |class 2             |    none                |      class 2         |
   |                    |                        |                      |
   +---------------------------------------------+----------------------+

6.4 Default maximum TPDU size

   The default maximum TPDU size value specified in this document breaks
   ISO Transport negotiation rule which states that the maximum TPDU
   size specified or defaulted by the CC TPDU cannot be greater than the
   maximum TPDU size proposed by the CR TPDU.

   To avoid the consequences of this, it is strongly recommended that
   the CC TPDU always specifies the maximum TPDU size value.

6.5 Class 0 TPDU bit encoding

   This protocol no longer allows credit and TPDU-NR (bits 0 to 6)
   fields to be ignored on input, which is in line with ISO 8073
   encoding rules.  RFC1006 TPDU encoding defined inconsistent encoding
   rules.




Pouffary & Young            Standards Track                    [Page 18]

RFC 2126              ISO Transport on top of TCP             March 1997


6.6 Class 2 Options

   Class 2 Additional Option parameter value

   +--------------------------------------------------------------------+
   |  BIT   |                    OPTION                                 |
   +--------------------------------------------------------------------+
   |        |                                                           |
   |    8   | Not applicable                                            |
   |        |                                                           |
   |    7   | = 1 Use of Non-blocking Expedited Data                    |
   |        | = 0 Non-use of Non-blocking Expedited Data (default)      |
   |        |                                                           |
   |(*) 6   | = 1 Use of Expedited Data Acknowledgement                 |
   |        | = 0 non-use of Expedited Data Acknowledgement (default)   |
   |        |                                                           |
   |    5   | Not applicable                                            |
   |        |                                                           |
   |(*) 4   | = 1 Use of Reverse Connection procedure                   |
   |        | = 0 Use of Forward Connection procedure (default)         |
   |        |                                                           |
   |    3   | Not applicable                                            |
   |        |                                                           |
   |    2   | Not applicable                                            |
   |        |                                                           |
   |    1   | = 1 Use of Transport Expedited Data Service               |
   |        | = 0 Non-use of Transport Expedited Data Service (default) |
   |        |                                                           |
   +--------------------------------------------------------------------+

   (*) In ISO 8073, bit 4 is defined as use of "Network Expedited"  and
   bit 6 is defined as "Request Acknowledgement".



















Pouffary & Young            Standards Track                    [Page 19]

RFC 2126              ISO Transport on top of TCP             March 1997


   Class 2 Options Profile

   +--------------------------------------------------------------------+
   |  Bits     Service selected                                         |
   | 1 4 6 7                                                            |
   +--------------------------------------------------------------------+
   | 0 x x x   Non-use of Transport Expedited Data Service              |
   |           ---------------------------------------------------------|
   |                        Bits 4 6 7 are not applicable (*)           |
   +--------------------------------------------------------------------+
   | 1 x x x   Use of Transport Expedited Data Service                  |
   |           ---------------------------------------------------------|
   | 1 0 x x       Use of Expedited Data Service with Forward Connection|
   |               -----------------------------------------------------|
   | 1 0 1 0                Forward Connection with Expedited Data      |
   |                        Acknowledgement                             |
   | 1 0 1 1                Forward Connection with Expedited Data      |
   |                        Acknowledgement and use of Non-blocking     |
   |                        Expedited Data  (**)                        |
   |                        --------------------------------------------|
   | 1 0 0 0                Forward Connection with non-use of Expedited|
   |                        Data Acknowledgement  (***)                 |
   | 1 0 0 1                Forward Connection with non-use of Expedited|
   |                        Data Acknowledgement and use of Non-blocking|
   |                        Expedited Data                              |
   |               -----------------------------------------------------|
   | 1 1 x x       Use of Expedited Data Service with Reverse Connection|
   |               -----------------------------------------------------|
   | 1 1 1 0                Reverse Connection with Expedited Data      |
   |                        Acknowledgement                             |
   | 1 1 1 1                Reverse Connection with Expedited Data      |
   |                        Acknowledgement and use of Non-blocking     |
   |                        Expedited Data  (**)                        |
   |                        --------------------------------------------|
   | 1 1 0 0                Reverse Connection with non-use of Expedited|
   |                        Data Acknowledgement  (***)                 |
   | 1 1 0 1                Reverse Connection with non-use of Expedited|
   |                        Data Acknowledgement and use of Non-blocking|
   |                        Expedited Data                              |
   +--------------------------------------------------------------------+

   (*) Note the default (0000) provides an RFC1006-like service with
   Explicit Transport Disconnection.

   (**) Note in this case use of Expedited Data Acknowledgement with use
   of Non-blocking Expedited Data is a wasted effort (See section 6.5)





Pouffary & Young            Standards Track                    [Page 20]

RFC 2126              ISO Transport on top of TCP             March 1997


   (***) Note in this case Normal and Expedited Data TPDU are not
   synchronised. (See section 6.6)

6.7 Class 2 Expedited Data Acknowledgement

   The Protocol specified in this document does not define any
   relationship between use of "Expedited Data Acknowledgement" option
   and use of "Non-blocking Expedited Data" service.

   However please note that when using "Non-blocking Expedited Data"
   service it is a wasted effort to use "Expedited Data
   Acknowledgement", since ED TPDUs are duplicated and sent on both the
   Normal Data and Expedited Data TCP connections.

6.8 Class 2 Normal Data and Expedited Data handling

   There exist two separate application requirements for using Expedited
   Data:

   1- Synchronisation of the order of delivery between Normal
      and Expedited Data TPDU.

   2- Independence of Normal and Expedited data channels. A busy
      Normal Data channel should not block an Expedited Data channel.

   The protocol described in this document can accommodate both
   requirements, separately or in combination.

   Synchronisation:
      If synchronised order of delivery between Normal and Expedited
      Data TPDU is required then use of either "Expedited Data
      Acknowledgement" TPDU or use of the "Non-blocking Expedited Data"
      service must be negotiated during connection establishment.

      If synchronised order of delivery between Normal and Expedited
      Data TPDU is not required then non-use of "Expedited Data
      Acknowledgement" need not be negotiated during connection
      establishment.

   Independence:
      If Independence of Normal and Expedited data channels is required
      then Forward or Reverse connection must be negotiated during
      connection establishment. Expedited data TPDU must be sent on the
      Expedited data channel.







Pouffary & Young            Standards Track                    [Page 21]

RFC 2126              ISO Transport on top of TCP             March 1997


      If Independence of Normal and Expedited data channels is not
      required then Forward connection should be negotiated during
      connection establishment and the Expedited data channels should
      never be established. Expedited data TPDU is then sent inband on
      the Normal data channel.

   Finally please note that independence of Normal and Expedited data
   channels without synchronisation relaxes the Transport Service
   definition of Expedited data and is not consistent with ISO 8072.

6.9 Class 2 Forward Connection procedure

   As defined in ISO 8073, when "Forward Connection" (Splitting and
   Recombining) procedure is used for Expedited Data transmission, ED
   TPDU must only be sent over an outgoing NS-provider TCP connection.

   As defined in ISO 8073, this document does not mandates use of the
   Splitting procedure for Expedited Data transmission. The
   Recombination procedure, which associates Data (normal and expedited)
   TPDUs arriving for a transport connection over two TCP connections
   must be handled.

   It is legal to send Expedited Data TPDU inband on the Normal Data TCP
   connection.

   Please note that the protocol specified in this document does not
   define when an Expedited Data TCP connection should be established.
   This is an implementation choice.

   When using "Non-blocking Expedited Data" service it is recommended to
   not delay establishing Expedited Data TCP connection.

6.10 TPKT

   This document specifies the value of the TPKT reserved field.

   Implementation should not interpret and act upon any value in a
   reserved field. To avoid Interoperability issues with RFC1006, this
   field should be ignored on input.

7. Rationale - Interoperability with RFC1006

   We have chosen to maintain the same TPKT protocol version in ITOT as
   in RFC1006 (version 3). The reason for this decision is that the
   changes in this document do not conflict with RFC1006. If we were to
   change the protocol version we would prevent existing RFC1006
   implementations which mandate version 3 from interoperating with the
   protocol defined in this document.



Pouffary & Young            Standards Track                    [Page 22]

RFC 2126              ISO Transport on top of TCP             March 1997


   One consequence of this decision relates to class negotiation.  The
   protocol described in this document introduces Class 2 over TCP, and
   it therefore introduces the need to be able to perform class
   negotiation between Class 2 and Class 0.  While all Transport
   implementations should be able to handle Class negotiation, we
   recognise that some RFC1006 implementations cannot. Therefore
   Implementors should be aware that Class 2 Connect Request (with no
   Alternative class) could be accepted with a Class 0 Connect Confirm,
   at which point the Connect Confirm should be rejected as specified in
   ISO 8073.

8. Security Considerations

   Security issues are not specifically addressed in this document.
   Operation of this protocol is no more and no less secure than
   operation of TCP and ISO 8073 protocols. The reader is directed there
   for further reading.

Acknowledgements

   The authors are pleased to acknowledge the suggestions and comments
   of Harald T. Alvestrand, Jim Bound, John Day, Mike Dyer, Peter
   Furniss, Dan Harrington, Steve Kille, Keith G. Knightson, Keith
   Sklower, Matt Thomas, Robert Watson and many other members of the
   IETF TOSI mailing list. The support of Allison Mankin of the IESG was
   essential.

References

   [ISO8072]  ISO. "International Standard 8072.  Information Processing
              Systems - Open Systems Interconnection: Transport Service
              Definition."

   [ISO8073]  ISO. "International Standard 8073.  Information Processing
              Systems - Open Systems Interconnection: Transport Protocol
              Specification." ISO 8073:1992 and 8073:1992/Amd.5:1995.

   [ISO8348]  ISO. "International Standard 8348.  Information Processing
              Systems - Open Systems Interconnection: Network Service
              Definition."

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.





Pouffary & Young            Standards Track                    [Page 23]

RFC 2126              ISO Transport on top of TCP             March 1997


   [RFC896]   Nagle, J., "Congestion Control in IP/TCP Inertnetworks",
              RFC 896, January 1984.

   [RFC1006]  Rose, M., and D. Cass, "ISO Transport Services on Top of
              the TCP Version 3", STD 35, RFC 1006, May 1987.

   [RFC1277]  Hardcastle-Kille, S., "Encoding Network Addresses to
              support operation over non-OSI lower layers", RFC 1277,
              November 1991.

   [RFC1278]  Hardcastle-Kille, S., "String encoding of Presentation
              Address", RFC 1278, November 1991.

              A string encoding of Presentation Address
              update to RFC1278, Work in Progress.

   [RFC1859]  Pouffary, Y., "ISO Transport Class 2 Non-use of Explicit
              Flow Control over TCP - RFC1006 extension", RFC 1859,
              October 1995.

   [IPV6]     Deering, S., and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 1883, December 1995.

              Hinden,, R., and S. Deeing, "IP Version 6 Addressing
              Architecture", RFC 1884, December 1995.

              Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
              and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.























Pouffary & Young            Standards Track                    [Page 24]

RFC 2126              ISO Transport on top of TCP             March 1997


Authors' Addresses

   Yanick Pouffary
   End Systems Networking
   Digital Equipment Corporation
   Centre Technique (Europe)
   B.P. 027
   950 Routes des colles
   06901 Sophia antipolis, France

   Phone: +33 92-95-62-85
   Fax:   +33 92-95-62-35
   EMail: pouffary@taec.enet.dec.com


   Alan Young
   ISODE Consortium
   The Dome
   The Square
   Richmond, UK

   Phone: +44 181 332 9091
   Fax:   +44 181 332 9019
   EMail: A.Young@isode.com



























Pouffary & Young            Standards Track                    [Page 25]