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
|
Network Working Group S. Mathur
Request for Comments: 1553 M. Lewis
Category: Standards Track Telebit Corporation
December 1993
Compressing IPX Headers Over WAN Media (CIPX)
Status of this 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 describes a method for compressing the headers of IPX
datagrams (CIPX). With this method, it is possible to
significantly improve performance over lower speed wide area
network (WAN) media. For normal IPX packet traffic, CIPX can
provide a compression ratio of approximately 2:1 including both IPX
header and data. This method can be used on various type of WAN
media, including those supporting PPP and X.25.
This memo ia a product of the Point-to-Point Protocol Extensions
(PPPEXT) Working Group of the IETF. Comments should be sent to
the authors and the ietf-ppp@ucdavis.edu mailing list.
Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST
This word, or the adjective "required", means that the
definition is an absolute requirement of the specification.
MUST NOT
This phrase means that the definition is an absolute
prohibition of the specification.
Mathur & Lewis [Page 1]
RFC 1553 CIPX December 1993
SHOULD
This word, or the adjective "recommended", means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications should be
understood and carefully weighed before choosing a
different course.
MAY
This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST be
prepared to interoperate with another implementation which
does include the option.
Introduction
Internetwork Packet Exchange (IPX) is a protocol defined by the
Novell Corporation [1]. It is derived from the Internet Datagram
Protocol (IDP) protocol of the Xerox Network Systems (XNS) family
of protocols. IPX is a datagram, connectionless protocol that does
not require an acknowledgment for each packet sent. The IPX
protocol corresponds to the network layer of the ISO model.
Usually, there is a transport layer protocol above IPX. The most
common transport protocol is the Netware Core Protocol (NCP), which
is used for file server access. The Sequenced Packet Exchange
(SPX) is the reliable connection-based transport protocol commonly
used by applications.
The IPX packet consists of a 30 octet IPX header, usually followed
by the transport layer protocol header. The NCP header is 6 octets
in length. The SPX header is 12 octets in length.
Two strategies are described below for compressing IPX headers.
This specification requires that implementations of CIPX support
both IPX header compression strategies. These header compression
algorithms are based on those Van Jacobson described [2] for TCP/IP
packets.
The first strategy is to compress only the IPX header. This
compression algorithm can be used to compress any IPX packet,
without affecting the transport protocol. This algorithm
compresses a 30 octet IPX header into a one to seven octet header.
The second strategy is to compress the combined IPX and NCP
headers. This algorithm compresses only NCP packets with NCP type
of 0x2222 and 0x3333. This algorithm compresses a 36 octet NCP/IPX
Mathur & Lewis [Page 2]
RFC 1553 CIPX December 1993
header into a one to eight octet header.
Lastly, it is possible and many times desirable, to use this type
of header compression in conjunction with some type of data
compression.
Data compression technology takes many forms. Link bit stream
compression is a common approach over very low speed asynchronous
links, normally performed by modems transparently. Transparent bit
stream compression is also offered in some DSUs, routers and
bridges. Data compression can be provided using protocols such as
CCITT V.42bis[3], MNP 5, Lempel-Ziv, or LAPB[4].
When using both header and data compression, the sequence of
compression is important. When sending packets, data compression
MUST be done after header compression. Conversely when receiving
packets, data decompression MUST be done before header
decompression.
IPX Compression Algorithm
The normal IPX header consists of the following fields: checksum,
packet length, transport control (hop count), packet type,
destination and source address fields.
+-----------------------+
| Checksum |
+-----------------------+
| Packet Length |
+-----------+-----------+
| Hops |Packet Type|
+-----------+-----------+
| Destination |
| Address |
| (12 Octets) |
+-----------------------+
| Source |
| Address |
| (12 Octets) |
+-----------------------+
IPX PACKET HEADER
The IPX header diagram above is shown without the field alignment
details. Consider each field of the IPX header separately, and how
it typically changes.
Historically, Novell has not used the Checksum field in the IPX
Mathur & Lewis [Page 3]
RFC 1553 CIPX December 1993
header, and has required that this field be set to 0xFFFF. Since the
Checksum field remains constant, it is clear that the value can be
compressed.
Where Checksums are implemented (not 0xFFFF), the Checksum MUST be
included in the compressed packet. Recalculating the checksum would
destroy the end-to-end reliability of the connection. Note that
Checksums are now implemented in the Fault Tolerant Servers.
For most links, the Packet Length can be determined from the MAC
layer. There are cases in which the length cannot be determined from
the MAC layer. For example, some hardware devices pad packets to a
required minimum length. For links where it is not possible to
determine the IPX packet length from the MAC layer, packet length
needs to be included in the compressed packet.
The Transport Control (Hops) field usually does not change between
two end-points. For the purposes of compression, we will assume that
it never changes, and will not examine this field when determining a
connection.
The Packet Type field is constant for any connection.
The Destination and Source Address fields are each made up of 12
octets: Network (4 octets), Node (6 octets), and Socket (2 octets)
fields. An IPX connection is the logical association between two
endpoints known by a given source and destination address pair. For
any specific IPX connection, the Destination and Source Address
fields are constant.
Hence, the fields that may need to be included in the compressed IPX
header are the Checksum and the Packet Length.
While using this IPX header compression algorithm, packets can be
lost. The loss of an Initial packet presents a problem. In this
case, if the sender later tries to send a compressed packet, the
receiving end cannot decompress the packet correctly.
Sufficient information is not available in the IPX header to
determine when a re-transmission has occured. For this reason, it is
necessary that the sender of an Initial packet be guaranteed that the
packet has been received. Therefore, we provide a mechanism for
Confirmation of an Initial packet.
NCP/IPX Header Compression
Since most IPX packets are Netware Core Protocol packets (packet type
17), compressing the NCP header will give us added performance. A
Mathur & Lewis [Page 4]
RFC 1553 CIPX December 1993
minimal CIPX implementation MUST also implement NCP/IPX compression.
+------------+
| NCP |
| Type |
+------------+
| Sequence |
| Number |
+------------+
| Connection |
|(low octet) |
+------------+
| Task |
| Number |
+------------+
| Connection |
|(high octet)|
+------------+
NCP HEADER
The NCP header is 6 octets in length consisting of the following
fields: NCP type, sequence number, connection number and task number.
The NCP type field values that are currently defined are:
1111 Create Connection
2222 NCP request from workstation
3333 NCP reply from file server
5555 Destroy Connection
7777 Burst Mode Packet
9999 Server Busy Packet
This NCP header compression algorithm only compresses packets that
have a type field value of 0x2222 or 0x3333. If the NCP type is
0x2222, this packet is a request from the client to the server.
Conversely if the NCP type is 0x3333, this is a response from the
server to the client. All other types of NCP packets are not
compressed at the NCP level, but are compressed at the IPX level.
The Create Connection (0x111), Destroy Connection (0x5555) and Server
Busy (0x9999) packets are not exchanged frequently enough to justify
special NCP compression. The Burst Mode (0x7777) packet is discussed
below.
The connection number is a constant for a given connection.
The sequence number is increased by one for each new request. Hence
the sequence number can be determined implicitly. The decompressor
Mathur & Lewis [Page 5]
RFC 1553 CIPX December 1993
increments the sequence number for each compressed packet it receives
for a connection.
The task number can change unpredictably, although it might remain
constant for several packets. If the NCP task number is different
from the last one for this connection, the NCP task number must be
included.
If the NCP packet is lost, it will be retransmitted through the
normal transport layer mechanisms. The Initial NCP packet does not
require confirmation, as a re-transmitted packet can be easily
identified. This is accomplished by comparing the sequence number of
the packet to the sequence number of the previous packet. If the
sequence number is not exactly one greater than the previous packet,
a new Initial packet must be sent, although the same connection slot
may be used.
In the event of compressed packet loss, the sequence number will be
too small. When the IPX Checksum is present, the loss can be
determined at the destination system by an incorrect checksum. When
there is no checksum present, the loss is more likely to be detected
upon receiving a later retransmission.
NCP Burst Mode Packets
The burst mode protocol uses the NCP type value of 0x7777. This type
of packet does not have the normal NCP header described above.
Instead, it has a 36 octet burst header. The above NCP header
compression algorithm should not be used to compress this packet.
The IPX header in this packet is still compressible with the IPX
header compression algorithm described.
SPX Packets
SPX packets are typically used by applications which require
reliable service such as print servers. It is possible to apply a
similar NCP/IPX technique to SPX/IPX packets. At this time, we
have not described such a mechanism. The IPX header in this
packet is still compressible with the IPX header compression
algorithm described.
Compression Header
IPX compression should be negotiated by some means (eg. IPXCP or
IPXWAN). Each end must negotiate the desired options, such as the
maximum number of concurrent connections which will be maintained
in each direction. Once IPX compression is negotiated, all IPX
packets sent over that link have a CIPX header added to the
Mathur & Lewis [Page 6]
RFC 1553 CIPX December 1993
beginning of the packet. The CIPX header is variable in length.
The one octet CIPX header is added even when a regular IPX packet
is sent over the link. By including the CIPX header on every
packet, we support the ability to run CIPX over various WAN links
as if it were a normal IPX packet. It does not rely on any new
link specific packet demultiplexing.
Implementations of this compression protocol must maintain send
and receive tables indicating the state of each connection. The
original header for each connection is stored in a "slot".
Typically, each client-server connection will use a separate slot.
Both sides keep a copy of the full IPX header corresponding to
each slot. The sending side (compressor) uses this information to
determine the fields that have changed. The receiving side
(decompressor) uses this information to reconstruct the original
packet header.
The CIPX packet header specifies the type of the packet and any
options for that packet. The minimum CIPX header is one octet in
length.
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| | | | | | | | |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet Type
| | | | 0 Compressed
| | | | 1 Regular
| | | | 3 Confirmed Initial
| | | | 5 Confirm
| | | | 7 Unconfirmed Initial
| | | | 9 Reject
| | | | 11-15 Reserved
| | | |
|__ |__ |__ |___________________ Packet Type Dependent Flags
FLAGS OCTET
As can be seen above, the low order bits specify the packet type.
All Compressed packets have a lowest bit of zero. The other
packet types are odd numbers.
Note that the Flags octet MUST NOT contain the value 0xFF. This
is necessary to distinguish the CIPX flags octet from a normal IPX
header with a 0xFFFF checksum field. It is important to be able
Mathur & Lewis [Page 7]
RFC 1553 CIPX December 1993
to recognize a normal IPX header regardless of the state of
compression. It is possible with some link layer protocols such
as X.25 Permanent Virtual Circuits that one end of the link may
fail and start sending regular IPX packets without the CIPX
header. CIPX implementations MUST recognize this situation and
renegotiate the use of CIPX.
Each packet type has associated flag bits, which are called Packet
Type Dependent Flags. Different packet types have different
Packet Type Dependent Flags. All bits that are reserved or are
not specified must be set to zero.
Since none of the packet types other than Compressed currently
uses any of the flag bits, the packet type field could easily be
expanded. Any future expansion must ensure that at least one of
the bits in the Flags octet remains zero so the value cannot be
0xFF.
Compressed Packet
This type of packet does not contain a packet header (either 30 byte
IPX, or 36 byte NCP). A slot number indicates to the receiver which
saved header to use to formulate the original packet header before
passing the packet up to IPX.
Mathur & Lewis [Page 8]
RFC 1553 CIPX December 1993
________________________________ Slot Number
| 0 Assume same as last packet
| 1 Included in packet
|
| ____________________________ Checksum
| | 0 Assume 0xFFFF
| | 1 Included in packet
| |
| | ________________________ Length
| | | 0 Determine from MAC length
| | | 1 Included in packet
| | |
| | | ____________________ Task Number (NCP only)
| | | | 0 Assume same as last packet
| | | | 1 Included in packet
| | | |
| | | | ________________ Reserved (Must be zero)
| | | | | | |
| | | | | | | ____ Packet Type
| | | | | | | | 0 Compressed Packet
v v v v v v v v
+---+---+---+---+---+---+---+---+
| | | | | 0 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+
7 6 5 4 3 2 1 0
Consider each flag in the flags octet, looking at the high order bits
working toward the lower order bits. Each of the fields is optional,
but if present will be found in the same order in the compressed
packet header.
Slot Number
The slot number flag indicates the slot number field is included in
the compressed packet. The slot number field is one octet in length
and specifies the number of the slot which corresponds to the Initial
packet header. Slots are numbered starting at zero and continue to
the maximum number of slots minus one.
By default, slot compression is disabled. If negotiated, slot
compression can be enabled for those slots which were created by the
Unconfirmed Initial packet. When set to one (1), the slot number
flag indicates the inclusion of the the slot number in the compressed
packet. When set to zero (0), the slot number flag indicates the
omission of the the slot number and specifies the use of the same
slot number as for the last packet.
Mathur & Lewis [Page 9]
RFC 1553 CIPX December 1993
Implementation Note:
Slot compression MUST only be enabled in a receiver which can
account for all erroneous and discarded packets. When a packet
has been discarded, the slot number is indeterminate for future
packets. The decompressor MUST discard all further packets
until a slot number is received.
Checksum
When set to one (1), the checksum flag indicates the compressed
packet will include the 2 octet checksum. When set to zero (0),
this flag indicates the omission of the checksum and the decompressor
is to assume the checksum is 0xFFFF. Note that meaningful checksums
must be included in the packet with the checksum flag set to one (1).
Length
When set to one (1), the length flag indicates the inclusion of the
IPX data length field in the compressed packet. When set to zero
(0), the length flag indicates the omission of the IPX data length
field in the compressed packet.
This is the Length field from the original IPX packet header. It
specifies the length of IPX header and data in the packet prior to
compression. It does not include the CIPX compression field such as
flags, slot number, checksum, length field, or the NCP task number.
Note that it is preferable to determine the length field from the MAC
layer whenever possible, by subtracting the length of the compression
header fields and adding the length of the saved packet header.
Since every octet is significant over lower speed WAN links, an
optimization is used in the specification of the length. It can be
specified as a one, two or three octet field. If the length is in
the range 0 to 127, then it is specified as a one octet field. If
the length is in the range 128 to 16383, it is specified as a two
octet field in high to low order, with the first octet in the range
128 to 191. Otherwise, if the length is greater than 16383, the
first octet contains 192, and the second and third octets contain the
full length. (This scheme is extensible to 8 octets, but currently
is not required in the IPX protocol suite.)
Mathur & Lewis [Page 10]
RFC 1553 CIPX December 1993
+-+-+-+-+-+-+-+-+
|0| length | length < 128
+-+-+-+-+-+-+-+-+
ONE OCTET LENGTH FIELD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0| length | length < 16384
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TWO OCTET LENGTH FIELD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0 0 0 0| length | length < 65535
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
THREE OCTET LENGTH FIELD
Task Number
When set to one (1), the NCP task number flag indicates the NCP task
number is included in the compressed packet (see NCP/IPX compression
above). When set to zero (0), the NCP task number flag indicates the
omission of the NCP task number in the compressed packet. When the
NCP task number is not included in the compressed packet, we use the
same NCP task number as that of last packet.
Based upon the bits set in the flags octet, optional portions are
included in the compressed IPX header. The minimum compressed IPX
header contains only the Flags octet. All fields in the original IPX
header have been compressed out of the header. The maximum
compressed IPX header can include up to 7 octets, the Flags, Slot,
Checksum (2 octets), and Length (3 octets) fields, or 8 octets if the
NCP Task Number is included. The minimum and maximum compressed IPX
packets are shown below. Header fields are one octet in length
except where noted.
Mathur & Lewis [Page 11]
RFC 1553 CIPX December 1993
+--------+---------
| Flags | DATA ...
| 0x00 |
+--------+---------
MINIMUM COMPRESSED IPX PACKET
+--------+--------+---------+---------+---------
| Flags | Slot |Checksum | Length | DATA ...
| 0xE0 | Number |2 octets |3 octets |
+--------+--------+---------+---------+---------
MAXIMUM COMPRESSED IPX PACKET
+--------+--------+---------+---------+--------+---------
| Flags | Slot |Checksum | Length |NCP Task| DATA ...
| 0xF0 | Number |2 octets |3 octets | Number |
+--------+--------+---------+---------+--------+---------
MAXIMUM COMPRESSED NCP/IPX PACKET
Regular Packet
The Regular packet type designates an IPX packet for which no
compression is desired. This type of packet is sent when a packet
cannot be compressed, or a decision is made not to compress it.
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet Type
| | | | 1 Regular
| | | |
|__ |__ |__ |___________________ Reserved (must be zero)
The Regular packet is rarely sent. Usually, the Regular packet is
sent when there is not enough memory for the overhead of a new
compression slot. Also, this type is included for future unforeseen
changes to the IPX protocol which defeat the effectiveness of
compression.
Implementation Note:
The Regular Packet can be used for packets that are sporadic,
which are not worth setting-up a compression slot. This may be
Mathur & Lewis [Page 12]
RFC 1553 CIPX December 1993
hard to determine for specific protocols. Various methods such
as hold-down and least-recently-used timers are currently being
used.
On receipt, the 1 octet header is simply removed and the packet
passed up to IPX.
The entire IPX packet follows the single Flags octet. Note for a
Regular Packet (not compressed or uncompressed), the slot number
field is not included.
Confirmed Initial Packet
The Confirmed Initial packet type is used by the compressor to inform
the decompressor of the original packet header which will be used for
subsequent compression, and to request Confirmation. The high order
4 bits are reserved for expansion to support additional protocols.
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet Type
| | | | 3 Confirmed Initial
| | | |
|__ |__ |__ |___________________ 0 IPX Protocol
1-15 Reserved
This type of packet is sent to inform the receiver to associate the
IPX packet header with a slot number. This packet is sent each time
a different header format is sent for a given slot, or when the
sender has not received a Confirmation Packet from the receiver.
The Flags octet lower 4 bits indicate the Confirmed Initial CIPX
packet type. The high order 4 bits are reserved for expansion to
support additional protocols. The Flags octet is always followed by
the Slot Number and an ID field. The ID field is one octet in
length.
For each slot, the ID will increment with every new header sent.
Different slots may have the same ID. The combination of slot and ID
uniquely identify a header. In practice, the ID octet can be any
number which is unique for a "reasonably long period" of time. A
reasonably long period is a function of transmission speed, round
trip delays, and network load. There must be very little chance of
duplicate slot and ID combinations within this period. Otherwise,
Mathur & Lewis [Page 13]
RFC 1553 CIPX December 1993
there is ambiguity as to which header is being identified.
Implementation Note:
There is no requirement to hold or resend the Confirmed Initial
packet until confirmation. When a new packet with the same IPX
header is to be sent, another Confirmed Initial packet should
be sent using the same slot, the same ID, and the new packet
data.
When a new packet with a different IPX header is to be sent, it
may be sent using a slot which has not received confirmation.
A Confirmed Initial packet is sent with the same slot, an
incremented ID, and the new packet data. Assuming a least-
recently-used policy for selecting a slot for a new IPX header,
this provides the ability to reuse slots when a Confirmed
Initial packet has been sent but not confirmed.
+---------+---------+---------+-/ /-+----------
| Flags | Slot | ID | IPX | DATA ...
| 0x03 | Number | | Header |
+---------+---------+---------+-/ /-+----------
CONFIRMED INITIAL PACKET
Note that a Confirmed Initial header is followed by a complete IPX
packet.
Confirm Packet
The Confirm packet type is used by the decompressor to tell the
compressor that it has received the Confirmed Initial packet.
When the compressor receives this, it can start sending Compressed
frames.
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet Type
| | | | 5 Confirm
| | | |
|__ |__ |__ |___________________ Reserved (must be zero)
A Confirm Packet is exactly 3 octets in length. It consists of the
Mathur & Lewis [Page 14]
RFC 1553 CIPX December 1993
Flags, Slot Number and ID fields. The Slot Number field contains the
number of the slot which is being acknowledged. The ID field
contains the ID of the Confirmed Initial Packet which is being
acknowledged.
+---------+---------+----------+
| Flags | Slot | ID |
| 0x05 | Number | |
+---------+---------+----------+
CONFIRM PACKET
Unconfirmed Initial Packet
The Unconfirmed Initial packet type is used by the compressor to
inform the decompressor of the original packet header which will be
used for subsequent compression while not requesting confirmation.
After sending an Unconfirmed Initial packet, the compressor may
immediately send Compressed packets without confirmation.
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet Type
| | | | 7 Unconfirmed Initial
| | | |
|__ |__ |__ |___________________ 0 NCP Protocol
1-15 Reserved
This type of packet is sent to inform the receiver to associate the
IPX packet header with a slot number. This packet is sent each time
a different header format is sent for a given slot.
The Flags octet lower 4 bits indicate the Unconfirmed Initial CIPX
packet type. The high order 4 bits are reserved for expansion to
support additional protocols. The Flags octet is always followed by
the Slot Number.
+---------+---------+-/ /-+-/ /-+---------
| Flags | Slot | IPX | NCP | NCP
| 0x07 | Number | Header | Header | DATA ...
+---------+---------+-/ /-+-/ /-+---------
Mathur & Lewis [Page 15]
RFC 1553 CIPX December 1993
UNCONFIRMED INITIAL PACKET
Note that an Unconfirmed Initial header is followed by a complete IPX
packet.
Reject Packet
The Reject packet type is used by the decompressor to tell the
compressor that it has received a CIPX packet with a header which it
does not support. This is provided to regulate future extensions to
CIPX.
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| | | | |___|___|___|___ Packet Type
| | | | 9 Reject
| | | |
|__ |__ |__ |___________________ Reserved (must be zero)
A Reject Packet is exactly 3 octets in length. It consists of the
Flags, Slot Number and Rejected Flags fields.
The Slot Number field contains the number of the slot of the packet
which is being rejected. Since the actual packet type may be unknown
or misunderstood, this field actually contains the second octet of
the rejected packet. In the normal case of a known CIPX packet type,
this will be the slot number of an initial packet.
The Rejected Flags field contains the first octet of the packet being
rejected. The packet type field is left untouched. Any flags which
are correctly recognized should be cleared. The remaining flags
indicate specific features that are being rejected. This information
should be sufficient for implementations to adjust the use of certain
packet types or dependent flags.
Implementation Note:
The Flags value of 0xFF is not a valid CIPX packet type.
Hence, such a packet type should be recognized as a standard
IPX header and forwarded without CIPX processing to the
appropriate routines. Under no circumstances should a Flags
value of 0xFF be rejected in a Reject Packet.
Mathur & Lewis [Page 16]
RFC 1553 CIPX December 1993
+---------+---------+----------+
| Flags | Slot | Rejected |
| 0x09 | Number | Flags |
+---------+---------+----------+
REJECT PACKET
Compression Negotiation over PPP Links
For PPP links [5], the use of header compression can be negotiated by
IPXCP [6]. By default, no compression is enabled.
The IPX-Compression-Protocol Configuration Option is used to indicate
the ability to receive compressed packets. Each end of the link must
separately request this option if bi-directional compression is
desired.
The PPP Protocol field is set to the same value as the usual IPX
packets, and all IPX packets sent over the link MUST conform to the
compressed format.
A summary of the IPX-Compression-Protocol Configuration Option format
to negotiate Telebit IPX header compression (CIPX) is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPX-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-Slot-Id | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
3
Length
6
IPX-Compression-Protocol
0002 (hex) for Telebit Compressed IPX headers (CIPX).
Max-Slot-Id
The Max-Slot-Id field is one octet and indicates the maximum
Mathur & Lewis [Page 17]
RFC 1553 CIPX December 1993
slot identifier. This is one less than the actual number of
slots; the slot identifier has values from zero to Max-Slot-
Id.
Options
The Options field is one octet, and is comprised of the "logical or"
of the following values:
0 No options.
1 The slot identifer may be compressed.
The slot identifier must not be compressed if there is no
ability for the PPP link level to indicate an error in
reception to the decompression module. Synchronization after
errors depends on receiving a packet with the slot identifier.
2 Redefine Compressed Packet type bits 1-3.
It was noted earlier that packet types have been chosen such
that only the Compressed Packet type is an even number value
with the lowest order bit of zero. All other packet types are
odd values with a lowest order bit of one. The reason for this
assignment was to make it possible to determine the Compressed
Packet type by examining only one bit. This make it possible
to use all the other 7 bits to indicate status in the
Compressed Packet. The 7 bits are composed of the upper 4 bits
which are permanently defined to indicate packet dependent
flags, plus bits 1-3 which are otherwise part of the Packet
Type. The upper 4 bits are defined above. The redefinition of
bits 1-3 of the Compressed Packet type is left for future
expansion.
7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| | | | | | | | 0 |
+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |___ Packet Type
| | | | | | | 0 Compressed Packet
| | | | | | |
| | | | |___|___|_______ Redefined bits
| | | |
|___|___|___|___________________ Compressed Packet flags
By default, this feature in not enabled and this flag is
set to zero. When this flag is set to one, it indicates
Mathur & Lewis [Page 18]
RFC 1553 CIPX December 1993
the desire to use this feature.
Compression Negotiation over IPXWAN Links
"IPXWAN" is the protocol Novell uses to exchange necessary router
to router information prior to exchanging standard IPX routing
information and traffic over WAN datalinks [7]. To negotiate the
Telebit compression option, we use Novell's allocated option number
for CIPX (00) in the IPXWAN timer request/response packet.
The Timer Request packet contains the following Telebit compression
option:
WOption Number 80 - Define compression type
WAccept Option 01 - 0=No, 1=Yes, 3=N/A
WOption Data Len 00 03 - Length of option
WOption Data 00 - Telebit's compression (CIPX)
WOption Data XX - Compression options
WOption Data NN - Compression slots
Where the WOption Data fields are:
00 Telebit's compression option described in this
document (CIPX).
XX Compression options as defined below:
0x01 Compress slot ID when possible
0x02 Redefine Compressed Packet type bits 1-3.
NN The requested # of compression slots.
Accept Option (for compression type) must be set to YES if the
option is supported and NO if the option is not supported. A Timer
Response must respond with only one header compression type set to
YES.
The Timer Response packet that accepts the option will look like
this:
WOption Number 80 - Define compression type
WAccept Option 01 - 0=No, 1=Yes, 3=N/A
WOption Data Len 00 03 - Length of option
WOption Data 00 - Telebit's compression (CIPX)
WOption Data XX - Compression options
WOption Data NN - Compression slots
Mathur & Lewis [Page 19]
RFC 1553 CIPX December 1993
Where the WOption Data fields are:
00 Telebit's compression option described in this
document (CIPX).
XX Compression options as defined below:
0x01 Compress slot ID when possible
0x02 Redefine Compressed Packet type bits 1-3.
NN The negotiated # of slots (The lower of each side's
requested number of slots)
IPX packets (except of course IPXWAN packets) are not sent over the
link until the IPXWAN negotiations are completed. Once IPXWAN
negotiations are completed, regular IPX packets can be sent over the
link.
If both ends of the link agree on the compression options, then the
IPX packets are sent using the specified options. If either end of
the link does not accept a compression option, then this compression
option will not be used. Compression will be done using any
remaining options. Options, by definition, are not required.
Implementations MUST support CIPX without any options.
It is the responsibility of the router sending the IPXWAN Timer
Response to inform the other router of the options that will be used.
The Timer Response MUST contain a subset of the options received in a
Timer Request.
To be clear, IPXWAN is used to set up a symmetrical compression link.
Compression is configured identically in both directions. Each end
will use the same number of slots and same compression options. It
is illegal for link ends to use different number of slots or
different options.
IPX Compression Performance
The performance of this algorithm will depend on the number of active
connections and the number of slots negotiated. If the number of
slots is greater than the number of connections, the hit rate should
be very high giving a very high compression ratio. The performance
also depends on the average size of the IPX packets. If the average
size of packets is small, then compression will result in a more
noticeable performance improvement.
Mathur & Lewis [Page 20]
RFC 1553 CIPX December 1993
avg_data_len + uncomp_header_len
Compression ratio = ----------------------------------
avg_data_len + avg_comp_header_len
Where 'avg_data_len' is the average length of data in the IPX packet,
and 'uncomp_head_len' is the uncompressed header length which is
fixed at 30 octets. Where 'avg_comp_header_len' is the average
length of the compressed IPX header. The length of the minimum
compressed IPX header is 1 octet. The length of the maximum
compressed NCP/IPX header is 8 octets (including the NCP task
number), but since no implementation yet sends packets with a length
greater than 16K, 7 octets is the commonly encountered maximum.
Perhaps a reasonable 'avg_comp_header_len' is 2, assuming the
inclusion of the flag and slot number octets.
The maximum length of the data in an IPX packet is 546 octets (576
octets - 30 octet IPX header), although newer implementations may
send packets of up to 4096 octets. The minimum length of the data in
an IPX packet is 1 octet. Within the normal distribution of small
NCP packets, perhaps a reasonable 'avg_data_len' is 26 octets.
546 + 30
Minimal Compression = -------- = 1.04
546 + 6
1 + 30
Maximal Compression = ------ = 15.50
1 + 1
26 + 30
Likely Compression = ------- = 2.00
26 + 2
Security Considerations
IPX provides some security features, which are fully applicable to
CIPX. CIPX does not significantly alter the basic security of IPX.
Mathur & Lewis [Page 21]
RFC 1553 CIPX December 1993
References
[1] Novell Inc., "IPX Router Specification", September 1992, Part
Number: 107-000029-001
[2] Jacobson, Van, "Compressing TCP/IP Headers for Low-Speed Serial
Links", RFC 1144, February 1990
[3] CCITT Recommendation V.42bis Error Correcting Procedures for DCEs
using Error Correction Procedures
[4] ISO 7776, Information Processing Systems - Data Communication -
High Level Data Link Control Procedures - Description of the X.25
LAPB-Compatible DTE Data Link Procedures
[5] Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 1548,
December 1993
[6] Simpson, W. A., "The PPP Internet Packet Exchange Control
Protocol (IPXCP)", RFC 1552, December 1993
[7] Allen, Michael, "Novell IPX Over Various WAN Media [IPXWAN]",
RFC 1551, December 1993
Acknowledgements
This compression algorithm incorporates many ideas from the Van
Jacobson TCP/IP header compression algorithm.
Michael Allen from Novell provided a lot of valuable feedback in the
design of this algorithm. David Piscitello from Bellcore and Marty
Del Vecchio at Shiva Corp. made several good suggestions. Bill
Simpson was very helpful in driving PPP, and specifically IPXCP, on
the standards course.
Chair's Address
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California 93117
EMail: fbaker@acc.com
Mathur & Lewis [Page 22]
RFC 1553 CIPX December 1993
Authors' Addresses
Saroop Mathur
Telebit Corp.
1315 Chesapeake Terrace
Sunnyvale, CA 94089-1100
EMail: mathur@telebit.com
Mark S. Lewis
Telebit Corp.
1315 Chesapeake Terrace
Sunnyvale, CA 94089-1100
EMail: Mark.S.Lewis@telebit.com
Mathur & Lewis [Page 23]
|