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 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627
|
Network Working Group P. Furniss
Request for Comments: 1698 Consultant
Category: Informational October 1994
Octet Sequences for Upper-Layer OSI
to Support Basic Communications Applications
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document states particular octet sequences that comprise the OSI
upper-layer protocols (Session, Presentation and ACSE) when used to
support applications with "basic communications requirements". These
include OSI application protocols such as X.400 P7 and Directory
Access Protocol, and "migrant" protocols, originally defined for use
over other transports.
As well as the octet sequences which are the supporting layer headers
(and trailers) around the application data, this document includes
some tutorial material on the OSI upper layers.
An implementation that sends the octet sequences given here, and
interprets the equivalent protocol received, will be able to
interwork with an implementation based on the base standard, when
both are being used to support an appropriate application protocol.
Table of Contents
1. Introduction ...................................................2
2. General ........................................................3
2.1 Subdivisions of "basic communication applications" ...........3
2.2 Conformance and interworking .................................5
2.3 Relationship to other documents ..............................5
3. Contexts and titles ............................................6
3.1 The concepts of abstract and transfer syntax .................6
3.2 Use of presentation context by cookbook applications..........7
3.3 Processing Presentation-context-definition-list ..............8
3.4 Application context ..........................................9
3.5 APtitles and AEqualifiers ....................................9
4. What has to be sent and received ..............................10
4.1 Sequence of OSI protocol data units used ....................10
4.2 Which OSI fields are used ...................................12
Furniss [Page 1]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
4.3 Encoding methods and length fields ..........................14
4.3.1 Session items .............................................14
4.3.2 ASN.1/BER items (Presentation and ACSE) ...................14
4.4 BER Encoding of values for primitive datatypes ..............15
4.5 Unnecessary constructed encodings ...........................16
5. Notation ......................................................16
6. Octet sequences ...............................................17
6.1 Connection request message ..................................17
6.2 Successful reply to connection setup ........................20
6.3 Connection rejection ........................................22
6.4 Data-phase TSDU .............................................23
6.5 Closedown - release request ................................24
6.6 Closedown - release response ................................25
6.7 Deliberate abort ............................................25
6.8 Provider abort ..............................................27
6.9 Abort accept ................................................27
7. References ....................................................27
8. Other notes ...................................................28
9. Security Considerations .......................................29
10. Author's Address .............................................29
1. Introduction
The upper-layer protocols of the OSI model are large and complex,
mostly because the protocols they describe are rich in function and
options. However, for support of most applications, only a limited
portion of the function is needed. An implementation that is not
intended to be a completely general platform does not need to
implement all the features. Further, it need not reflect the
structuring of the OSI specifications - the layer of the OSI model
are purely abstract.
This document presents the protocol elements required by the OSI
upper layers when supporting a connection-oriented application with
only basic communication requirements - that is to create a
connection, optionally negotiate the data representation,
send/receive data, close a connection and abort a connection.
Optionally, data may be sent on the connection establishment, closing
and abort messages.
In this document, the protocol elements needed are given in terms of
the octet sequences that comprise the 'envelope' around the
application data. The envelope and its enclosing data form a
Transport Service Data Unit (TSDU) that can be passed via the OSI
Transport Service [ISO8072] (which in turn may be supported as
specified in [RFC1006] or any class of the OSI Transport Protocol
[ISO8073]).
Furniss [Page 2]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
The octet sequences to be sent and the description of the alternative
forms that may be received are equivalent to an informal re-
specification of the relevant parts of the upper-layer protocols.
The "relevant parts" are determined by the requirements of the
supported applications (this is a reflexive definition! - if
application Z needs something that is not here, it is not supported).
The formal specifications remain the base standards, the appropriate
profiles and the requirements of the application. However, an
implementation based on this document will be able to interwork with
an implementation based directly on the full standards when both are
supporting a basic communication application. The "full"
implementation will exhibit only part of its potential behaviour,
since the application will only invoke part.
In addition to the octet sequences, the document includes some
tutorial material.
2. General
2.1 Subdivisions of "basic communication applications"
Distinctions can be made within the "basic communication
applications", as defined above, based on how much use they make of
the OSI upper-layer services, and thus how much of the protocol
described in this memo will be used to support a particular
application. One distinction is:
a) whether application data is sent on the connection
establishment, close and abort, or only during "date phase"
on an established connection; OR
b) whether the application data is of only one kind (abstract
syntax) and one format (transfer syntax) or more than one
(i.e., how much use is made of the Presentation layer syntax
negotiation and identification features)
Further distinctions are possible, but in this memo, elements of
protocol needed (or not needed) by four groups of "basic
communications application" are identified. All groups have "basic
communications requirements" in requiring only connection, data
transfer and (perhaps) orderly release of connection. The four groups
are:
Group I: applications which send data only on an established
connection, and use a single abstract and transfer syntax.
Furniss [Page 3]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
Group II: applications which send data on connection
establishment and release and use a single abstract and transfer
syntax.
Group III: applications that send data of only one kind (one
abstract syntax) on the connection, but which have more than one
format (transfer syntax) specified (they use the Presentation
context negotiation facility).
Group IV: applications that will send data of several kinds on the
connection (and which much therefore distinguish on each write
which kind is being sent).
Group III applications are equivalent to Group I (or possibly Group
II) after the establishment exchange has negotiated the particular
transfer syntax that will be used on the connection.
Possible examples of the Groups are:
Group I: Application protocols designed for use over transport-
level protocols. Typically these are non-OSI protocols "migrated"
to an OSI environment. X Window System protocol is an example.
Group II: OSI-originated protocols with simple requirements,
including many of the ROSE-based ones, such as Directory Access
Protocol.
Group III: Protocols that can be treated as Group I, but for
which more than one encoding of the data is known, such as a
standardised one and a system-specific one - all implementations
understand the standard encoding, but Presentation layer
negotiation allows like-implementations to use their internal
encoding for transfer, without loss of general interworking. The
same could apply to OSI protocols.
Group IV: OSI protocols with multiple abstract syntaxes (but with
each individual message from a single abstract syntax) that do
not use any of the special Session functional units - X.400 P7 is
an example.
Some of the OSI protocols that are not included are those that use
more than one abstract syntax in a single message (such as FTAM or
Transaction Processing) or use Session functional units (RTSE-based
protocols, Virtual Terminal).
Furniss [Page 4]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
2.2 Conformance and interworking
The protocol elements specified in this memo correspond to the kernel
functional units of Session, Presentation and ACSE, and the duplex
functional unit of Session.
The octet sequences given below are derived from the specifications
in the International Standards for the protocols Session [ISO8327],
Presentation [ISO8822] and ACSE [ISO8650]. The intention of this memo
is to summarise those specifications, as applicable to the supported
application groups, so that an implementation could be developed
without direct reference to the original standards, but capable of
interworking with implementations that had made direct reference. The
OSI standards (especially Presentation) allow considerable
flexibility in the encoding of the protocol data units. Accordingly,
this memo defines particular octet sequences to be sent, and
describes the variations that can be expected in data received from
an implementation based directly on the OSI standards, rather than on
this cookbook. It is intended that an implementation that sends these
sequences and that is capable of interpreting the variations
described will be fully able to interwork with an implementation
based directly on the OSI standards. An implementation that is only
capable of interpreting the octet sequences specified in this memo
for transmission may not be able to interwork with standards-based
implementations.
The intent is to be able to interwork with conformant implementations
in support of the relevant application (or group of applications).
Some of the OSI standards have conformance requirements that go
beyond that necessary for successful interworking, including
detection of invalid protocol. Tests for conformance sometimes go
beyond the strict conformance requirements of the standard.
Consequently an implementation based on this memo may or may not be
able to formally claim conformance to the International Standard. It
may be able to legitimately claim conformance, but fail a conformance
test, if the test is over-specified. (Efforts are being made to
correct this, but in the meantime, the target is interworking with
conformant implementations.)
2.3 Relationship to other documents
The flexibility allowed in the Session, Presentation and ACSE
standards is restricted in the Common Upper-Layer Requirements Part 1
[CULR-1]). This is a proposed International Standardised Profile
(pdISP 11188-1) that can be assumed to be obeyed by most
implementations. This memo applies the restrictions of CULR-1,
especially where these concern maximum sizes of fields and the
like.Points where advantage is taken of a CULR-1 limitation are
Furniss [Page 5]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
noted.
Additional parts of CULR are under development. Part 3 [CULR-3]
covers the protocol elements needed for "basic communications
applications", and is being developed in (informal) liaison with this
memo. CULR-3 is presented as a normal profile, largely consisting of
prescribed answers to the questions in the PICS (Protocol
Implementation Conformance Statement) of the three protocols. CULR-3
does not make the distinction between the four Groups. An
implementation of this memo (at least if it supported Group IV) would
be able to claim conformance to CULR-3, with the possible exception
of any more-than-interworking conformance requirements inherited by
CULR-3 from the base standards.
An extension [XTI/mOSI] to the X/Open Transport Interface [XTI] is
shortly to be published as a preliminary specification. This defines
an API to the OSI upper-layers, again as appropriate to a basic
communications application. XTI/mOSI would be usable as an interface
to support applications in groups I, II and III, and possibly group
IV.
3. Contexts and titles
3.1 The concepts of abstract and transfer syntax
OSI includes the concepts of "abstract syntax" and "transfer syntax".
These are terms for the content (abstract syntax) and format "on-
the-line" (transfer syntax) of the protocol elements. The combination
of an abstract syntax and transfer syntax is called a presentation
context.
Application protocols devised explicitly under OSI auspices have used
ASN.1 for the definition of the abstract syntax, and nearly all use
the Basic Encoding Rules applied to the ASN.1 to define the transfer
syntax. However, there is no such requirement in OSI in general or in
OSI Presentation, and still less is there any requirement to change
the representation of existing application protocols to ASN.1 (for
their definition) or BER (for their transmission). It is not
generally realised (even in OSI circles) that all communicating
applications, in all environments, are using some form of these,
although under different names and without the explicit
identification that the OSI Presentation provides. OSI separates the
identification of the content and format of the data from the
addressing.
Formal specifications of non-OSI application protocols (such as
TELNET, FTP, X Windows System) generally do not use ASN.1, but will
invariably be found to define abstract and transfer syntaxes. For a
Furniss [Page 6]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
less formalised protocol used between similar systems, the abstract
syntax may be defined simply in programming language structures, and
the transfer syntax determined by how some compiler represents this
in memory.
The OSI Presentation protocol requires that "names" be assigned to
the abstract and transfer syntaxes of the application data that is
carried. The names are always object identifiers ("oid"): globally
unique names assigned hierarchically. Presentation supports the
negotiation of a transfer syntax for a particular abstract syntax -
several can be offered and one selected.
This transfer syntax negotiation facility may be especially useful
for non-ASN.1 syntaxes where there is more than one representation
available (perhaps differing in byte-ordering or character code). In
such a case, on the connection establishment, all of the transfer
syntaxes supported by the initiator are offered, and any one of these
accepted by the responder, at its own choice. If the two systems
share some "native" format they can negotiate that, avoiding
transformation into and out of a more general format that is used for
interworking with unlike systems. The same applies to an ASN.1-
defined abstract syntax, but in practice non-BER encodings of ASN.1
are rare.
3.2 Use of presentation context by cookbook applications
An application protocol not originally specified with OSI
Presentation in mind (a "migrant" protocol) will not normally need to
identify the abstract and transfer syntaxes being used - they are
known by some other means (effectively inferred from the addressing).
A generic (anonymous, if you like) name for both syntaxes can be used
and [CULR-3] defines object identifiers for "anonymous" abstract and
transfer syntax names (currently called "default", but this is
expected to change).
In some cases object identifier names will be assigned for the
syntaxes of a migrant application protocol. If these exist, they
should be used. However, since the processing required will be the
same, it will be legitimate to offer both the generic and specific
names, with the responder accepting the specific (if it knew it) and
the generic if the specific were not known - this will provide a
migration option if names are assigned to the syntaxes after
implementations are deployed using the generic names.
For abstract syntaxes defined in ASN.1 object identifier names will
have been assigned to the abstract syntax with the specification.
This name MUST be used to identify the abstract syntax. The transfer
syntax will most often be the Basic Encoding Rules (BER) object id,
Furniss [Page 7]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
but alternatives (e.g., Packed Encoding Rules) are possible.
For group III and group IV applications, specific object identifier
names must be used for all the abstract and transfer syntaxes. If
these names are not assigned with the specification (e.g., if the
specification not in ASN.1) they can be assigned by whoever needs
them - ideally the "owner" of the syntax specification.
3.3 Processing Presentation-context-definition-list
In Presentation context negotiation on connection establishment the
initiator sends a list (the presentation context definition list) of
the abstract syntaxes it intends to use, each with a list of transfer
syntaxes. Each presentation context also has an integer identifier.
To build the reply, a responder has to examine this list and work out
which of the offered presentation contexts will be accepted and which
(single) transfer syntax for each. The responder sends back the reply
field, the Presentation-context-definition-result-list, in the accept
message. The result list contains the same number of result items as
the definition-list proposed presentation-contexts. They are matched
by position, not by the identifiers (which are not present in the
result- list). An acceptance also includes the transfer syntax
accepted (as there can be several offered). This can be copied from
the definition list.
For the group I, group II and group III cases, only the ACSE and one
application-data P-context will be used and all other contexts
rejected. For the group IV case, several presentation contexts will
be accepted.
However, even for group I applications there may be synonyms for an
application-data Presentation-context. Unknown synonyms are rejected.
The reply shown in 6.2 includes a rejection (It can therefore not be
the reply to the connection request shown in 6.1, since that has only
two items in the definition list.)
In all cases, the connection responder must identify and keep the
presentation context identifiers (called pcid's here) for all the
accepted presentation contexts. These are integers (odd integers, in
this case). CULR-1 limits them to no greater than 32767, but they
will usually be <= 255 (so taking up one octet).
A presentation context is sometimes used (i.e., data is sent using
it) before the negotiation is complete. As will be seen in section 6,
in these cases, the transfer syntax name sometimes appears with the
integer identifier.
Furniss [Page 8]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
3.4 Application context
The Association Control Service Element also exchanges the name
(another Object Identifier) of the application context, which
identifies what the communication is all about, again independently
of the naming and addressing. As for the syntaxes, although some
name must be present in the protocol, a generic name can be used for
applications that do not have a specific name assigned. (This will
almost certainly be a group I application - if a specific name is
assigned, it must be used.) The only negotiation allowed is that the
reply may be different from that sent by the initiator. CULR-3
provides a generic application context name (i.e., assigns an object
identifier).
3.5 APtitles and AEqualifiers
In addition to the addressing constructs (transport address and
possibly session and presentation selectors), the communicating
application entities have names - Application-Entity titles
(AEtitle). These are carried by ACSE as two fields -the
Application-process titles (APtitle) and the Application-entity
qualifier (AEqualifier). The AEtitle is compound, and the APtitle
consists of all but the last element, which is the AEqualifier. (This
explanation can be run backwards). There are two non-equivalent
forms. AP-titles and AE-titles can be Directory Name or an Object
Identifier. AE-qualifiers can be Relative Distinguished Name (RDN) or
an integer - the forms must match, since the AE-qualifier is the last
component of the AP-title. In practice, the Directory form is likely
to be the only one seen for a while.
Use of the these names is rather variable. This cookbook proposes
that implementations should be able to handle any value for the
partner's names, and set (as initiator) its own names. This is
primarily to facilitate OSI:non-OSI relaying (e.g., X/osi:X/tcp),
allowing the names of the end-system to be carried to the relay,
where they can be converted into hostnames, and the lower-layer
address determined. OSI assumes that name-to-address lookup is
possible (via the Directory or other means), but does not assume
address-to-name will work. Thus the calling AE-title is needed if the
responder is to know who the initiator is. However, most protocols
work perfectly well without these names being included.
As for their encoding, a RDN will almost always be a single attribute
value assertion, with the attribute defined either by the Directory
standard [ISO9594 = X.500], or in [Internet/Cosine Schema] [RFC1274].
Using the notation defined below, the encoding of an RDN using a
Directory-defined standard attribute is:
Furniss [Page 9]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
31 80 {1 - RDN, [SET OF]
30 80 {2 - AttributeValueAssertion, [SEQUENCE]
06 03 5504yy -- OID identifying an attribute named in
-- the Directory standard
-- which one is determined by yy
13 La xxxxxx -- [Printable string]
-- could be T61 string, with tag 14
00 00 }2 - end of AVA
00 00 }1 - end of RDN
The most likely attributes for an RDN have the following hex values
for yy.
CommonName 03
Country 06
Locality 07
State/Province 08
Organisation 0A
OrganisationUnit 0B
For non-Directory attributes, the object id name must be substituted
(thus changing the immediately preceding length)
If there are multiple attribute value assertions in the RDN, the
group between {2 and 2} is repeated (with different attributes).
Order is not significant.
The encoding of a [Directory] Name for the AP-titles is the RDNs
(high- order first) within
30 80 {1 - [SEQUENCE] Name
-- put the RDN encodings here
00 00 }1
An Object Identifier AP-title is encoded as a primitive (see below),
with the "universal" tag for an object identifier, which is 6. The
integer AE-qualifier uses the universal tag for an integer, which is
2.
4. What has to be sent and received
4.1 Sequence of OSI protocol data units used
OSI defines its facilities in terms of services but these are
abstract constructs (they do not have to correspond to procedure
calls) - the significant thing is the transmission of the resulting
protocol data unit (PDU). The PDU at each layer carries (as user
data) the PDU of the layer above. The different layers follow
Furniss [Page 10]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
different conventions for naming the pdus. This section gives an
overview of the sequence of PDUs exchanged - the details of these are
given in section 6.
The requirements of the application are to create a connection
(strictly an association for the application-layer in OSI, but called
a connection here), to send and receive data and to close the
connection. The PDUs used are thus:
To create connection:
First create transport-level connection
Initiator sends the message defined in 6.1, which is Session
CONNECT carrying Presentation CONNECT request [CP] carrying
ACSE A-ASSOCIATE request [AARQ] optionally carrying application
data.
Responder replies with the message defined in 6.2, which is
Session ACCEPT carrying Presentation CONNECT response [CPA]
carrying ACSE response [AARE] optionally carrying application
data.
- If the responder rejects the attempt, the reply will be Session
REJECT. This is defined in 6.3, where the REJECT carries no
user data. A received REJECT may carry Presentation, ACSE and
application data, although 6.3 shows only how to reject at
Session level..
To send/receive data on an connection
send the message defined in 6.4, which is an empty Session
GIVE-TOKEN followed by Session S-DATA carrying Presentation P-
DATA [TD] containing the application data (The GIVE-TOKEN is
just two octets required by Session for some backwards
compatibility.)
To close connection gracefully
One side sends the message defined in 6.5, which is Session
FINISH carrying P-RELEASE request carrying A-RELEASE request
[RLRQ] optionally carrying application data (This side may now
receive, but not send data.)
The other side replies with the message defined in 6.6, which
is Session DISCONNECT carrying P-RELEASE response carrying A-
RELEASE response [RLRE] optionally carrying application data
Furniss [Page 11]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
First side disconnects transport connection on receiving the
reply
To close connection abruptly but also send application data
Send the message defined in 6.7, which is Session ABORT
carrying Presentation U-ABORT [ARU] carry ACSE U-ABORT [ABRT]
carrying application data (delivery not guaranteed)
On receiving Session ABORT, disconnect transport
To close connection abruptly
- Either send the message defined in 6.8, which is Session ABORT
carrying nothing;
Or, just disconnect at transport level
A group I application is assumed (by definition) not to send data on
the establishment and release exchanges, a group II application will.
It would be possible to use the abort-with-data facility with a group
I to send a (possibly non-standardised) error message for diagnostic
purposes.
A special rule is used if a release collision occurs (i.e., FINISH+P-
RELEASE+RLRQ received after sending the same): the side that
initiated the original upper-layer connection waits and the other
side replies with the DISCONNECT etc.
4.2 Which OSI fields are used
There are a number of fields (parameters) in the pdus involved. These
can be categorised by what is needed to support applications (of a
particular Group) in general - a field may be "useful", "send-only",
"fixed", "fixed with default", "internal" or "not important". Even
those that are not important may be received from another
implementation, but since the application has no use for them, they
can be ignored. If an implementation is intended to support only a
particular application, it may be able to downgrade the "useful" to
"not important".
The text below describes the processing that is required for each
category and which fields are in each category.
"Useful" - when sending, an implementation of general use should be
able to set any (legal) value of these fields (via the upper
interface from the application or via some configuration or lookup
Furniss [Page 12]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
mechanism) and SHOULD pass received values for the Calling values to
the application (for specific applications, these fields may be
either required or unnecessary.)
AARQ:
Called application-process title
Called application-entity qualifier
Calling application-process title
Calling application-entity qualifier
"Send-only" - to interwork, the implementation must be able to set
any value of these, but can ignore any received value. Both are octet
strings.
Presentation selector (up to 4 octets, limited by CULR-1)
Session selector (up to 16 octets, limited by base standard)
"Fixed" (constant for all applications)
abstract and transfer syntax identifiers for presentation context
for ACSE Version numbers - 2 for session, 1 for Presentation
and ACSE
"Fixed with default" - the value is specific to the application. For
non-ASN.1 abstract syntaxes (group I or group II only) applications,
the anonymous values assigned by the OIW minimal OSI profile [CULR-3]
can be used. The CULR-3 default application context can be used where
a proper context name is neither available nor needed.
Application context
CULR-3 default is {1 0 11188 3 3}
Abstract syntax identifier for application data
CULR-3 anonymous name is {1 0 11188 3 1 1}
Transfer syntax identifier for application data
CULR-3 anonymous name is {1 0 11188 3 2 1}
"Internal" - an arbitrary value can be sent; a received value must be
stored for use in sending.
Presentation context identifiers for ACSE and the application
data (always odd integers)
"Not important" - for interworking, any legal received value for the
other fields must be received (i.e., the pdu is parsed successfully),
but can then be ignored. There is no requirement (in this cookbook)
to check the existence, value or internal format of these fields.
Furniss [Page 13]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
All other fields (which includes a large number of session
fields)
4.3 Encoding methods and length fields
Both Session and ASN.1/BER [ISO8824, ISO8825] use a type-length-value
structure for their encodings, but different ones. Presentation
protocol and ACSE protocol use the ASN.1/BER encoding and
consequently a Presentation PDU containing an ACSE PDU can be
constructed or parsed as if it were a single structure.
All the protocols contain pdu fields with a compound structure. If
one of these is being ignored it may be necessary (for BER, not
session) to determine the lengths of its components to find the
length of the ignored field.
Many of the lengths in the specification below will vary, dependent
on the values of the fields.
4.3.1 Session items
The type field of a session item is always a single octet.
For session items, given a particular length, there is no
flexibility:
If the length is less than 255, represent as one octet
If the length is greater, represent as three octets, first is
0xFF, next two are the length, high-order octet first.
(Some "real" implementations are known to use the second encoding in
all cases. This is wrong, but should only concern conformance
testers.)
4.3.2 ASN.1/BER items (Presentation and ACSE)
The type field for ASN.1-BER is the tag. Although it is possible for
large tags (>30) to be multi-octet, there are no large tags in the
protocols involved in this memo. Bit 6 (0x20) of the tag octet is 1
if the item is constructed (i.e., the value is itself one or more
ASN.1 BER items) or 0 if it is primitive.
There is considerable flexibility, at senders option, in how lengths
are represented in BER. There are three forms: short, long and
indefinite.
Short (usable only if the length is less than 127) : one octet
Furniss [Page 14]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
Long (usable for *any* length) : first octet has the top bit set,
the rest is a count of how many octets are holding the length
value; that many subsequent octets hold the length. A long length
may use more than the minimum number of octets (so 0x8400000001
is a valid representation of length 1)
Indefinite (usable only for the length of a compound field) : the
single octet is 0x80, then one or more items (their tag-length-
values) and finally two octets of 0x00 (equivalent to tag and
length of zero).
To be able to interwork generally, an implementation must be able to
handle any of these forms when receiving.
The encodings specified in the octet sequences below use indefinite
length for all constructed items with a few exceptions. This slightly
increases the number of octets sent, but means that the length of a
varying field (e.g., user data, or a varying object identifier)
affects only the length of the item itself, and not the enclosing
lengths. It is thus possible to use the octet sequences as templates
interspersed by the varying fields.
It is important to note that this choice of indefinite (which is
equivalent to the "Canonical Encoding Rules" variant of BER) applies
only to the Presentation and ACSE protocols themselves. It does not
apply to ASN.1/BER encoded application data. The processing required
of application data may suggest alternative "best" options.
4.4 BER Encoding of values for primitive datatypes
The following ASN.1 primitive datatypes are used in the thinosi
stack.
Integers are encoded in twos-complement, high-order first. Unlike
lengths, they must be encoded in the minimum number of octets (no
leading 00 padding).
Object Identifiers have a rather peculiar, but compressed encoding:
Combine the first two integers of the OID into one element by
multiplying the first (always 0, 1 or 2) by 40, and add the
second.
Each element (that one, and each subsequent integer in the OID
taken on its own), is a taken as a binary number and divided into
7-bit "bytes". This is apportioned into bits 1-7 of the minimum
number of octets. Bit 8 is one for all octets of the sequence
except the last. (This means that elements of less than 127 are
Furniss [Page 15]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
single octet integers.)
Printable Strings - as if in ISO 646 (ASCII)
OCTET STRING - just put the octets there
4.5 Unnecessary constructed encodings
BER allows the sender to break some items (such as OCTET STRINGS,
character strings) into several pieces (i.e., as constructed
encoding) or send them as primitive. CULR-1 requires that this is
only done to one level. The pieces of both OCTET STRING and character
string are tagged as if they were OCTET STRING - they have the tag
04. This memo does not include any of these optional constructions,
but they may be received in interworking.
5. Notation
The constructs are shown in their tag - length - value form. All
numbers are in hexadecimal. Comments are preceded by a '-' character.
Multiple '-' mean the comment is more than just information.
The tag column contains one of:
single fixed octets.
* in the tag field indicates one or more pdu fields (possibly
constructed) that may be received but are not sent. If received
they can be ignored.
! indicates the tag is defined elsewhere.
. is a place holder for the column.
? preceding the tag value indicates that the field is not always
present - the comment will explain.
The length column contains one of
explicit value
Ls - a length according to session rules which depends on the
total size of the value (usually constructed)
La - a length according to BER rules
. is a placeholder
Furniss [Page 16]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
yy is exactly one octet (i.e., one hex digit per y) holding part
of the length
The value column contains one of
the hex value
xxxxxx - value of varying length (sometimes constructed)
{n - (n = number) the start of a constructed value
n - (n=number) the end of the constructed value with the
corresponding number. (The number is sometimes omitted on the
innermost nest of construction)
yy - as part of a value - a variable value, each y represents one
hex digit
? a value, possibly constructed that may be received but is not
sent. It may be ignored if received
Note that all presentation lengths may be received in one of the
alternative forms. All constructed lengths are shown in indefinite
form. If a received length is definite, the corresponding end item
(which will be shown here as 00 00 }n) will become . . }n.
In the comments, the notation {n} refers to the constructed item
bracketed by the {n, }n fields.
6. Octet sequences
6.1 Connection request message
- CONNECT SPDU
0D Ls {1 - "SI" value for CONNECT = 13
* Ls ? - Connection Identifier
05 06 {2 - Connect/Accept Item
13 01 00 - protocol options (probably mandatory)
* Ls ?
16 01 02 -- version number (bottom bit = v1, next bit =v2.
-- may get offers of either or both
* Ls ?
14 02 0002 - Session User Requirements (functional units)
- Id (20), length (always 2), duplex fu only.
-- On receipt, other bits may be set
-- check that the 2 bit is set
* Ls ? - we do not send any Calling Session Selector
Furniss [Page 17]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
?34 Ls xxxx -- Called Session Selector (i.e., the other end's)
-- up to 16 octets - you must set what the other
-- side demands. - May be anything characters,
-- binary etc.
- {3} disappeared in editing
C1 Ls {4 -- User Data, Identifier=193. if length is > 512,
-- then identifier is 194 (hex C2) instead
- CP - P-CONNECT-RI PPDU. Everything below is in ASN.1 BER
31 80 {5 - [SET]
--- Mode-selector (the {6} group) could possibly
--- come after everything else {7}
--- This will probably only be done by
--- evil-minded conformance testers
A0 80 {6 - Mode-selector [0] IMPLICIT SET
80 01 01 - [0] IMPLICIT INTEGER {normalmode(1)}
00 00 }6
A2 La {7 - [2] unnamed IMPLICIT SEQUENCE
* La ?
?82 La xxxx - [2] Called-presentation-selector
- CULR says maximum length is 4
-- must be what the other side wants
A4 80 {8 - [4] Presentation-context-definition-list
--- items (the outer SEQUENCEs) within the {8} list may
--- be in any order.
30 80 {9 - [SEQUENCE]
02 01 01 -- Defines pcid for ACSE; received value will be
-- a one or two octet odd integer
06 04 52010001 - [OID] for ACSE abstract syntax
30 80 { - [SEQUENCE]
06 02 5101 - [OID] Transfer syntax name is BER
00 00 } - end t-s list
00 00 }9 - end acse pctx defn
30 80 {10 - [SEQUENCE]
02 01 03 -- [INTEGER] Defines pcid for application data;
-- received value will be a one or two octet odd
-- integer
06 La xxxxxx - [OID] object identifier name of application
- abstract syntax (if CULR-3 default is used, this
- line is 06 06 28D734030101)
30 80 {11
06 La xxxxxx - [OID] t-s name for application data
- (if CULR-3 default is used, this line is
- 06 06 28D734030201)
-- will be several of these if multiple t-s offered
-- (application is Group III)
-- all will have the same tag 06
00 00 }11 - end transfer syntax list for application p-ctx
00 00 }10 - end application pctx definition
Furniss [Page 18]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
-- if multiple presentation contexts are offered, (Group
-- IV), the {10} SEQUENCE will repeat appropriately
-- if multiple contexts are to be accepted, all the
-- pcid's must be remembered
00 00 }8 - end of p-ctx-def-list
* La ?
61 80 {12 - [APPLICATION 1] User-data - Fully-encoded
30 80 {13 - [SEQUENCE] PDV-list
02 01 01 -- [INTEGER], value is acse pcid
A0 80 {14 - [0] Single-ASN1
- ACSE A-ASSOCIATE request APDU - AARQ
60 80 {15 - [APPLICATION 0] - AARQ
* La ? - protocol version defaults to 1 (only one defined)
A1 80 { - [1] Application-context
06 La xxxxxx -- object identifier name of application context
- (if CULR-3 default is used, this line is
- 06 05 28D7340303)
00 00 }
-- Called application process title {16} and application
-- entity qualifier may or may not be needed (see 3.4)
?A2 80 {16 - [2] Called Application-Process title
?! La xxxxxx -- see 3.5 - either a Directory Name or an oid
?00 00 }16 - end Called APtitle
?A3 80 {17 - [3] Called Application-Entity Qualifier
?! La xxxxxx -- see 3.5
?00 00 }17
* La ?
Calling AP-title and AE-qualifier may or may not be needed.
?A6 80 {18 - [6] Calling Application-Process title
?! La xxxxxx -- see 3.5
?00 00 }18
?A7 80 {19 - [7] Calling Application-Entity Qualifier
?! La xxxxxx -- see 3.5
?00 00 }19
* La ?
-- the user information field may or may not be required
-- (not required for Group I)
?BE 80 {20 - [30] IMPLICIT SEQUENCE
?28 80 {21 - [EXTERNAL]
?06 La xxxxxx -- [OID] This is the oid identifying the transfer
-- syntax used for the user data.
-- It is (almost certainly) required even if only
-- one transfer syntax was proposed.
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxxxx -- [0] single-ASN.1-type - the application data
-- (see paragraph at end of this section below}
?00 00 }21 - end of EXTERNAL
Furniss [Page 19]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }20 - end of user information field
00 00 }15 - end of AARQ
00 00 }14 - end of single-ASN-type
00 00 }13 - end of PDV-list
00 00 }12 - end of Presentation User-data
00 00 }7 - end of third element of CP-type SET
00 00 }5 - end of CP-type
The application data carried in the EXTERNAL is shown (as A0 La xxxx)
assuming it is a single-ASN.1 type, which it often will be for group
II (since these tend to be OSI applications). The xxxx will be the
BER encoding of the application pdu (probably something like Z-BIND
or Y- INITIALIZE). The length may be indefinite.
If the application data is not a single ASN.1 type, but is an octet-
aligned value, the A0 La xxxx is replaced by 81 La xxxx, where xxxx
is the value. In this case the length must be definite (unless an
"unnecessary" constructed encoding is used.)
Identical considerations apply to the other EXTERNALs carried in the
ACSE pdus.
6.2 Successful reply to connection setup
If the connection attempt is successful, the following is sent to the
initiator on a T-DATA.
0E Ls {1 - ACCEPT SPDU
* Ls ?
05 06 {2 - Connect/Accept Item
13 01 00 - Protocol Options
* Ls ?
16 01 02 - version number (this shows version 2 only)
-- if version 2 was not offered, omit all of {2}
* Ls ?
14 02 0002 - Session User Requirements (functional units)
- duplex fu only (kernel is automatic)
* Ls ?
C1 Ls {3 -- User Data.
- CPA - P-CONNECT response
31 80 {4 - [SET]
-- again, Mode-selector could come at the end
A0 80 { - Mode-selector [0]
80 01 01 - normal mode - [0], length=1, value=1
00 00 }
A2 80 {5 - [2] SEQUENCE (unnamed)
Furniss [Page 20]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
* La ?
A5 80 {6 - [5] P-context-definition-result-list
-- following result items are in the order
-- corresponding to the pctx-definition-list in
-- the connect
-- this example assumes that was ACSE, user, rubbish
-- with rubbish rejected
30 80 {7 - [SEQUENCE] result item for acse
80 01 00 -- [0] result, value 0 is acceptance
81 02 5101 - [1] accepted transfer syntax name = BER
- note that this has an implicit tag, not 06
00 00 }7 - end result item for acse p-ctx
30 80 {8 - [SEQUENCE] result item for application-data pctx
80 01 00 - [0] value 0 is acceptance
81 La xxxxxx - [1] oid for transfer syntax, as on definition list
-- if there were several (groupIII) , the one you
-- liked most
00 00 }8 - end result item for app-data p-ctx
00 00 }6 - end p-ctx-def-result-list
* La ?
61 80 {10 - [APPLICATION 1] User-data, Fully-encoded
30 80 {11 - [SEQUENCE] PDV-list
02 01 01 -- [INTEGER] value is pcid for ACSE, as stored from
-- the pctx-definition-list on the P-CONNECT
-- request
A0 80 {12 - [0] single-ASN1-type
- A-ASSOCIATE response APDU - AARE
61 80 {13 - [APPLICATION 1] identifies AARE
* La ?
A1 80 {14 - [1] Application-context
06 La xxxxxx - [OID] name of application context
- usually the same as on AARQ, can differ
00 00 }14
A2 03 {15 - [2] result
02 01 00 - [INTEGER] value 0 means accepted
00 00 }15
A3 80 {16 - [3] result-source-diagnostic
- (curiously, a non-optional field)
A1 80 {17 - [1] acse-service-user
02 01 00 - [INTEGER] value 0 = null ! (why no implicit tag)
00 00 }17 - end acse-service-user
00 00 }16 - end result source diagnostic
* La ?
-- the user information field may or may not be required
- (not used for Group I)
?BE 80 {20 - [30] IMPLICIT SEQUENCE
Furniss [Page 21]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
?28 80 {21 - [EXTERNAL]
-- the transfer-syntax oid is not present this time
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxx -- [0] single-ASN1-type (see note at end of 6.1)
?00 00 }21 - end of EXTERNAL
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }20 - end of user information field
00 00 }13 - end AARE
00 00 }12 - end single-asn1-type
00 00 }11 - end PDV-list
00 00 }10 - end Presn user-data
00 00 }5 - end [2] implicit sequence in cpa
00 00 }4 - end CPA-type set
The following sequence are the octets need to reject a presentation
context that was offered in the presentation-context-definition-list.
Since the result-list matches the definition list by position, it is
placed at the corresponding point within {6} (e.g., it would come
immediately after {8}, if the rejected context was the third one.
-- next SEQUENCE is a rejection of a pctx
30 80 {9 - [SEQUENCE] result item for a rejected pctx
80 01 02 -- [0] result, value 2 is provider rejection
82 01 00 - [2] reason, value 0 is reason-not-specified
-- there are other reasons, but let's keep it
-- simple
00 00 }9 - end result item for rejected pctx
6.3 Connection rejection
Refusal is at session-level, but by session user, with no reason
given. This is a compromise avoiding making unfounded accusations of
(session) protocol misbehaviour. If the implementation finds it does
not like the received message, it is not essential to attempt to
communicate with the partner why, though this may be helpful if the
reason is correctly identified. (In most cases, a wise implementor
will make sure an error message goes somewhere or other).
0C 03 {1 - REFUSE SPDU
* Ls ?
32 01 00 - rejected by SS-user, no reason
The far-end may send interesting things explaining why you are not
getting interworking. If this is a session reason, the reason code
will one octet between 81 and 86. If the rejection is higher than
session, this will be carried on S-REFUSE (so first octet is still
Furniss [Page 22]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
0C) and the higher pdu will appear as part of the reason code, which
will start with 02. (The only remaining code is 01 = user
congestion.)
6.4 Data-phase TSDU
This is the core of the skinny stack. The lengths shown use a
particular set of choices for indefinite and definite lengths that
means that the application data length only affects one field. Making
the two earlier indefinite lengths definite would require more
calculation - adding 4 octets after the application data is assumed
to be quicker. This header is also designed to be 20 octets long,
thus maintaining 4-byte alignment between transport and application
buffers. Implementations are recommended to use this encoding. It is
possible to rapidly match incoming data against it - if there is no
mismatch until the length field, the location of the beginning of the
data can be determined without further analysis.
SPDUs
01 00 . - S-GIVE-TOKEN - required by basic concatenation
- but no parameters
01 00 . - S-DATA - no parameters - what follows is User
- Information, not User Data, so is not included in
- the SPDU length fields
- P-DATA PPDU - TD (why TD ? Typed-data id TTD !)
61 80 {1 - User-data [APPLICATION 1]
30 80 {2 - [SEQUENCE] PDV-list
02 01 03 - [INTEGER] pcid for application data, P-CONNECT PPDU
- remembered by both sides
81 83yyyyyy xxxxxx -- [1] octet-aligned presentation data value(s)
-- length of length (3 octets) then three octets yyyyyy
-- for the length of the user data xxxxxx
00 00 }2 - End-of-contents for end of PDV-list
00 00 }1 - End-of-contents for end of Presentation User-data
If the application data is in ASN.1, and a single ASN.1 value is
being sent on the TSDU, the same header can be used except for the
tag on the presentation data values, which becomes A0 (= [0],
constructed).
If there are multiple data values to be sent, this header can be
expanded in several ways:
a) if there are several ASN.1 values from the same
presentation context, they can be concatenated and
treated as an octet-aligned value (using the header
as shown above, with tag 81 (or A1 - I think its
primitive) or each ASN.1 value can be an item
Furniss [Page 23]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
(tagged A0), one after the other
b) if the data values are from different presentation
contexts (group IV), each is in its own {2} group
within the {1}.
On receipt, for the simple octet-aligned case, the data value may
itself have a constructed encoding - this will make the tag A1, and
it will contain elements each tagged 04 (OCTET STRING). According to
CULR- 1, these elements are primitive (otherwise they would be 24 of
course).
6.5 Closedown - release request
When all is done, and you want to close down gracefully, send this on
T-DATA.
- FINISH SPDU
09 10 {1 - 9 identifies FINISH
* Ls ? - No Transport Disconnect item
- default is release Transport-connection
C1 0E {2 - User data (code 193)
- P-RELEASE req/ind PPDU (has no name)
61 80 {3 - [APPLICATION 1], user data, fully-encoded
30 80 {4 - [SEQUENCE] PDV-list
02 01 01 -- pcid for ACSE, remembered from setup
A0 80 {5 - [0] single asn.1-type
- A-RELEASE request APDU - RLRQ
62 80 {6 - [APPLICATION 2] identifies RLRQ
80 01 00 - [0] reason, value 0 means normal
* La ?
-- the user information field may or may not be required
- ( not required for Group I)
?BE 80 {7 - [30] IMPLICIT SEQUENCE
?28 80 {8 - [EXTERNAL]
-- the transfer-syntax oid is not present this time
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxxx -- [0] single-ASN.1-type application data
-- (see note at end of 6.1)
?00 00 }8 - end of EXTERNAL
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }7 - end of user information field
00 00 }6 - end of RLRQ
00 00 }5 - end of single asn.1-type
00 00 }4 - end of PDV-list
00 00 }3 - end of Presentation User-data
Furniss [Page 24]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
6.6 Closedown - release response
On receiving a FINISH, you send this to tell the other end it is all
over
- Session DISCONNECT SPDU
0A Ls {1 - SI=10, DISCONNECT
C1 Ls {2 - User data
- P-RELEASE rsp PPDU
61 80 {3 - [APPLICATION 1], user data, fully-encoded
30 80 {4 - [SEQUENCE] PDV-list
02 01 01 -- [INTEGER] pcid for ACSE, remembered from setup
A0 80 {5 - [0] single asn.1-type
- A-RELEASE response APDU - RLRE
63 80 {6 - [APPLICATION 3] identifies RLRE
80 01 00 - [0] reason, value 0 means normal
* La ?
-- the user information field may or may not be required
- (not required for Group I)
?BE 80 {7 - [30] IMPLICIT SEQUENCE
?28 80 {8 - [EXTERNAL]
-- the transfer-syntax oid is not present this time
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxxx -- [0] single-ASN.1-type application data
-- (see note at end of 6.1)
?00 00 }8 - end of EXTERNAL
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }7 - end of user information field
00 00 }6 - end of RLRE
00 00 }5 - end of single asn.1-type
00 00 }4 - end of PDV-list
00 00 }3 - end of Presentation userdata
6.7 Deliberate abort
It is not clear whether this is any use - just clearing the Transport
connection will be more effective. It goes on T-DATA, but asks for
the far-side to close the T-connection.
- Session ABORT SPDU
19 Ls {1 - SI of 25 is ABORT
11 01 03 - Transport Disconnect PV, code 17
-- value = '...00011'b means please
-- release T-conn, user abort
* Ls ?
C1 11 {2 - Session User Data
Furniss [Page 25]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
- P-U-ABORT PPDU - ARU
A0 80 {3 - [0] implicit sequence for normal mode
A0 80 {4 - [0] presentation-context-identifier-list
30 80 {5 - [SEQUENCE]
02 01 01 - [INTEGER]pcid for ACSE
06 02 5101 - [OID] for acse transfer syntax = BER
00 00 }5
-- there will be one {6} group for each application
-- presentation context that is used in this message
-- if there is no user data, the {6} group can be
-- omitted
30 80 {6
02 01 03 - [INTEGER] pcid for application data
06 La xxxxxx - [OID] transfer syntax for application data
00 00 }6
00 00 }4 - end of presentation-context-identifier-list
61 80 {7 - [APPLICATION 1], user data, fully-encoded
30 80 {8 - [SEQUENCE] PDV-list
02 01 01 - [INTEGER] pcid for ACSE as on CP PPDU
A0 05 {9 - [0] single asn.1-type
- A-ABORT APDU - ABRT
64 80 {10 - [APPLICATION 4] identifies ABRT
80 01 01 - [0] value 1 is acse-service-provider
-- the user information field may or may not be required
?BE 80 {11 - [30] IMPLICIT SEQUENCE
?28 80 {12 - [EXTERNAL]
-- the transfer-syntax oid is not present this time
-- (according to CULR-1)
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxxx -- [0] single-ASN.1-type application data
-- (see note at end of 6.1)
?00 00 }12 - end of EXTERNAL
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }11 - end of user information field
00 00 }10 - end of ABRT
00 00 }9 - end of single asn.1-type
00 00 }8 - end of PDV-list
00 00 }7 - end of Presentation user-data
00 00 }3 - end of ARU-PPDU
Furniss [Page 26]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
6.8 Provider abort
Generated when an internal error occurs (i.e., something has gone
mildly (?) wrong in the cookbook implementation). Rather than accuse
anyone of protocol errors, we just abort at session.
ABORT SPDU
19 03 {1 - SI=25 = ABORT SPDU
11 01 09 - Transport Disconnect PV, code 17
-- value = '...01001'b release T-conn
-- no reason
* Ls ?
6.9 Abort accept
If a Session abort (of any kind) is sent, it is possible that the
far-end will send back an abort accept. If this happens, disconnect
the transport. (The abort messages above do not propose that the
transport connection be reused, and in this case, an abort accept is
just the far-end passing the transport-disconnect initiative back.)
This session message need never be sent - just disconnect transport
on receiving an abort.
ABORT ACCEPT SPDU
1A 00 . - SI=26 = ABORT ACCEPT SPDU, no parameters
7. References
[CULR-1] ISO/IEC DISP 11188-1 - Information Technology -
International Standardised Profile - Common Upper Layer Requirements
- Part 1: Basic Connection oriented requirements (DISP ballot ends
June 1994).
[CULR-3] Draft of Common Upper-layer requirements - Part 3: Minimal
OSI upper layers facilities (A later draft will be proposed as ISP
11188/3).
[ISO8072] Information processing systems - Open Systems
Interconnection - Transport service definition; ISO, 1986.
[ISO8073] Information processing systems - Open Systems
Interconnection - Transport protocol specification; ISO, 1986.
[ISO8326] Information processing systems - Open Systems
Interconnection - Basic connection oriented session service
definition; ISO, 1987 (or review copy of revised text = ISO/IEC
JTC1/SC21 N4657, April 1990).
Furniss [Page 27]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
[ISO8327] Information processing systems - Open Systems
Interconnection - Basic connection oriented session protocol
specification; ISO, 1987 (or review copy of revised text = ISO/IEC
JTC1/SC21 N4656, April 1990).
[ISO8649] Information processing systems - Open Systems
Interconnection - Service definition for the Association Control
Service Element; ISO, 1989.
[ISO8650] Information processing systems - Open Systems
Interconnection - Protocol specification for the Association Control
Service Element; ISO, 1989.
[ISO8822] Information processing systems - Open Systems
Interconnection - Connection-oriented presentation service
definition; ISO, 1989.
[ISO8823] Information processing systems - Open Systems
Interconnection - Connection-oriented presentation protocol
specification; ISO, 1989.
[ISO8824] Information technology - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1), ISO/IEC 1990.
[ISO8825] Information technology - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation
One, ISO/IEC 1990.
[RFC1006] Rose, M., and D. Cass, "ISO Transport Services on Top of
the TCP", STD 35, RFC 1006, Northrop Research and Technology Center,
May 1987.
[ISO9594] Information technology - Open Systems Interconnection - The
Directory; ISO/IEC, 1990.
[RFC 1274] Barker, P., and S. Kille, "The COSINE and Internet X.500
Schema", RFC 1274, University College London, November 1991.
8. Other Notes
The Session, Presentation and ACSE standards have been the subject of
considerable amendment since their first publication. The only one
that is significant to this cookbook is Session addendum 2, which
specifies session version 2 and unlimited user data. New editions of
these standards, incorporating all the amendments, will be published
during 1994.
Furniss [Page 28]
RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
The coding choices made in the cookbook are (nearly) those made by
the "Canonical Encoding Rules", which are a form of Basic Encoding
Rules with no optionality, specified in the new edition of ISO/IEC
8825. A defect report has been proposed against Presentation and
ACSE, suggesting that a note to the protocol specifications recommend
use of the canonical encoding options when sending, and then
optimising for this on receipt.
9. Security Considerations
Security issues are not discussed in this memo.
10. Author's Address
Peter Furniss
Peter Furniss Consultants
58 Alexandra Crescent
Bromley, Kent BR1 4EX
UK
Phone & Fax +44 81 313 1833
EMail: P.Furniss@ulcc.ac.uk
Furniss [Page 29]
|