File: rfc3321.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1067 lines) | stat: -rw-r--r-- 39,433 bytes parent folder | download | duplicates (5)
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






Network Working Group                                           H. Hannu
Request for Comments: 3321                            J. Christoffersson
Category: Informational                                         Ericsson
                                                             S. Forsgren
                                                             K.-C. Leung
                                                   Texas Tech University
                                                                  Z. Liu
                                                                   Nokia
                                                                R. Price
                                                      Siemens/Roke Manor
                                                            January 2003


         Signaling Compression (SigComp) - Extended Operations

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes how to implement certain mechanisms in
   Signaling Compression (SigComp), RFC 3320, which can significantly
   improve the compression efficiency compared to using simple per-
   message compression.

   SigComp uses a Universal Decompressor Virtual Machine (UDVM) for
   decompression, and the mechanisms described in this document are
   possible to implement using the UDVM instructions defined in RFC
   3320.















Hannu, et. al.               Informational                      [Page 1]

RFC 3321             SigComp - Extended Operations          January 2003


Table of Contents

   1.  Introduction..................................................2
   2.  Terminology...................................................3
   3.  Architectural View of Feedback................................4
   4.  State Reference Model.........................................5
   5.  Extended Mechanisms...........................................6
   6.  Implications on SigComp......................................13
   7.  Security Considerations......................................17
   8.  IANA Considerations..........................................17
   9.  Acknowledgements.............................................17
   10. Intellectual Property Right Considerations...................17
   11. References...................................................17
   12. Authors' Addresses...........................................18
   13. Full Copyright Statement.....................................19

1.  Introduction

   This document describes how to implement mechanisms with [SIGCOMP] to
   significantly improve the compression efficiency compared to per-
   message compression.

   One such mechanism is to use previously sent messages in the SigComp
   compression process, referred to as dynamic compression.  In order to
   utilize information from previously sent messages, it is necessary
   for a compressor to gain knowledge about the reception of these
   messages.  For a reliable transport, such as TCP, this is guaranteed.
   For an unreliable transport however, the SigComp protocol can be used
   to provide such a functionality itself.  That functionality is
   described in this document and is referred to as explicit
   acknowledgement.

   Another mechanism that will improve the compression efficiency of
   SigComp, especially when SigComp is applied to protocols that are of
   request/response type, is shared compression.  This involves using
   received messages in the SigComp compression process.  In particular
   the compression of the first few messages will gain from shared
   compression.  Shared compression is described in this document.

   For better understanding of this document the reader should be
   familiar with the concept of [SIGCOMP].










Hannu, et. al.               Informational                      [Page 2]

RFC 3321             SigComp - Extended Operations          January 2003


2.  Terminology

   The reader should consult [SIGCOMP] for definitions of terminology,
   since this document uses the same terminology.  Further terminology
   is defined below.

     Compressor

       Entity that encodes application messages using a certain
       compression algorithm and keeps track of state that can be used
       for compression.  The compressor is responsible for ensuring that
       the messages it generates can be decompressed by the remote UDVM.

     Decompressor

       The decompressor is responsible for converting a SigComp message
       into uncompressed data.  Decompression functionality is provided
       by the UDVM.

     Dynamic compression

       Compression relative to messages sent prior to the current
       compressed message.

     Explicit acknowledgement

       Acknowledgement for a state.  The acknowledgment is explicitly
       sent from a decompressor to its remote compressor.  The
       acknowledgement should be piggybacked onto a SigComp message in
       order not to create additional security risks.

     Shared compression

       Compression relative to messages received by the local endpoint
       prior to the current compressed message.

     Shared state

       A state used for shared compression consists only of an
       uncompressed message.  This makes the state independent of the
       compression algorithm.










Hannu, et. al.               Informational                      [Page 3]

RFC 3321             SigComp - Extended Operations          January 2003


     State identifier

       Reference used to access a previously created item of state.

       - shared_state_id

           State identifier of a shared state.

       - acked_state_id

           State identifier of a state that is acknowledged as
           successfully saved by the decompressor.

3.  Architectural View of Feedback

   SigComp has a request/response mechanism to provide feedback between
   endpoints, see Figure 1.  This particular functionality of SigComp is
   used in this document to provide support for the mechanisms described
   in this document.

      +--------------------+              +--------------------+
      |    Endpoint 1      |              |     Endpoint 2     |
      |  +--------------+  |              |  +--------------+  |
      |  | Compressor 1 |  |              |  |Decompressor 2|  |
      |  | [------------+--+--------------+--+--]   *       |  |
      |  +-|-------^----+  |              |  +--|---|-------+  |
      |    |       |       |              |     |   |          |
      |    |       |       |              |     |   |          |
      |    |       |       |              |     |   |          |
      |  +-|-------|----+  |              |  +--v---|-------+  |
      |  | *       [----+--+--------------+--+------]       |  |
      |  |Decompressor 1|  |              |  | Compressor 2 |  |
      |  +--------------+  |              |  +--------------+  |
      +--------------------+              +--------------------+

                       Figure 1.  Architectural view

   The feedback functionality of SigComp is used in this document to
   provide a mechanism for a SigComp endpoint to confirm which states
   have been established by its remote SigComp endpoint during the
   lifetime of a SigComp compartment.  The established state
   confirmations are referred to as acknowledgments.  Depending on the
   established states this particular type of feedback may or may not be
   used to increase the compression efficiency.







Hannu, et. al.               Informational                      [Page 4]

RFC 3321             SigComp - Extended Operations          January 2003


   The following sections describe how the SigComp functionality of
   providing feedback information is used to support the mechanisms
   described in this document.  Section 4 describes the state reference
   model of SigComp.  Section 5 continues with a general description of
   the mechanisms and Section 6 describes the implications of some of
   the mechanisms on basic SigComp.

4.  State Reference Model

   A UDVM may want to save the status of its memory, and this status is
   referred to as a state.  As explained in [SIGCOMP] a state save
   request may or may not be granted by the application.  For later
   reference to a saved state, e.g., if the UDVM is to be loaded with
   this state, a reference is needed to locate the specific state.  This
   reference is called a state identifier.

4.1.  Overview of State Reference with Dynamic Compression

   When compressor 1 compresses a message m it uses the information
   corresponding to a SigComp state that its remote decompressor 2 has
   established and acknowledged.  If compressor 1 wishes to use the new
   state for compression of later messages it must save the new state.
   The new state contains information from the former state and from m.
   When an acknowledgement is received for this new state, compressor 1
   can utilize the new state in the compression process.  Below is an
   overview of the model together with an example of a message flow.

   Saved state(s)

     A state which is expected to be used for compression/decompression
     of later messages.

   Acked state(s)

     An acked state is a saved state for which the compressor has
     received an acknowledgement, i.e., the state has been established
     at the remote decompressor.  The compressor must only use states
     that are established at the remote decompressor, otherwise a
     decompression failure will occur.  For this reason,
     acknowledgements are necessary, at least for unreliable transport.











Hannu, et. al.               Informational                      [Page 5]

RFC 3321             SigComp - Extended Operations          January 2003


            Compressor 1                    Decompressor 2
               +---+                            +---+
               | C |                            | D |
               +---+                            +---+

    Saved       Acked    |            |   Saved
   State(s)    State(s)  |            |  State(s)
  -----------------------+------------+------------------
  s0             s0      |            |    s0
  s1=s0+m1               | --m1(s0)-->|
                         | <--ack(s1) |  s0,s1
  s0,s1        s0,s1     |            |
                         |            |
  s0,s1        s0,s1     | --m2(s1)-->|   (m2 Lost)
  s2=s1+m1               |            |
                         |            |
  s0-s2        s0,s1     |            |
  s3=s1+m3               | --m3(s1)-->|   s0,s1
                         |            |
                         |            |
                         | <--ack(s3) |   s0,s1,s3=s1+m3
  s0-s3       s0,s1,s3   |            |

         Figure 2.  Example of message flow for dynamic compression

   Legend: Message 1 compressed making use of state s0 is denoted
   m1(s0).  The notation s1=s0+m1 means that state s1 is created using
   information from state s0 and message m1.  ack(s1) means that the
   creation of state s1 is acknowledged through piggybacking on a
   message traveling in the reverse direction (which is not shown in the
   figure).

5.  Extended Mechanisms

   The following subsections give a general description of the extended
   mechanisms.

5.1.  Explicit Acknowledgement Scheme

   For a compressor to be able to utilize a certain state it must know
   that the remote decompressor has access to this state.

   In the case where compressed messages can be lost or misordered on
   the path between compressor and decompressor, an acknowledgement
   scheme must be used to notify the remote compressor that a certain
   state has been established.





Hannu, et. al.               Informational                      [Page 6]

RFC 3321             SigComp - Extended Operations          January 2003


   Explicit acknowledgements can be initiated either by UDVM-code
   uploaded to the decompressor by the remote compressor or by the
   endpoint where the states have been established.  These two cases
   will be explained in more detail in the following two sections.

5.1.1.  Remote Compressor Initiated Acknowledgements

   This is the case when e.g., compressor 1 has uploaded UDVM bytecode
   to decompressor 2.  The UDVM bytecode will use the requested feedback
   field in the announcement information and the returned feedback field
   in the SigComp header to obtain knowledge about established states at
   endpoint 2.







































Hannu, et. al.               Informational                      [Page 7]

RFC 3321             SigComp - Extended Operations          January 2003


   Consider Figure 3.  An event flow for successful use of remote
   compressor initiated acknowledgements can be as follows:

   (1): Compressor 1 saves e.g., state(A).
   (2): The UDVM bytecode to initiate a state save for state(A) is
        either carried in the compressed message, or can be retrieved by
        decompressor 2 from a state already saved at endpoint 2.
   (3): As compressor 1 is the initiator of this acknowledgement it can
        use an arbitrary identifier to be returned to indicate that
        state(A) has been established.  The identifier needs to consist
        of enough bits to avoid acknowledgement of wrong state.
        To avoid padding of the feedback items and for simplicity a
        minimum of 1 octet should be used for the identifier.
        The identifier is placed at the location of the
        requested_feedback_item [SIGCOMP].
        The END-MESSAGE instruction is used to indicate the location of
        the requested_feedback_item to the state handler.
   (4): The requested feedback data is now called returned feedback data
        as it is placed into the SigComp message at compressor 2.
   (5): The returned feedback item is carried in the SigComp message
        according to Figure 4: see Section 6.1 and [SIGCOMP].
   (6): The returned feedback item is handled according to: Section 7
        of [SIGCOMP]

        +--------------+           (2)              +--------------+
        | Compressor 1 |--------------------------->|Decompressor 2|
        +------^-------+                            +-------^------+
               |    (1)                              (3)    |
           +---v---+                                    +---v---+
           |State  |                                    |State  |
           |handler|                                    |handler|
           +---^---+                                    +---^---+
               |    (6)                              (4)    |
        +------v-------+           (5)              +-------v------+
        |Decompressor 1|<---------------------------| Compressor 2 |
        +--------------+                            +--------------+

                  Figure 3.  Simplified SigComp endpoints













Hannu, et. al.               Informational                      [Page 8]

RFC 3321             SigComp - Extended Operations          January 2003


5.1.2.  Local Endpoint Initiated Acknowledgements

   When explicit acknowledgements are provided by an endpoint, the
   SigComp message will also carry acknowledgements, so-called
   acked_state_id: see Section 2.  Consider Figure 3, an event flow for
   successful use of explicit endpoint initiated acknowledgements can be
   as follows:

   (1): Compressor 1 saves e.g., state(A).
   (2): The UDVM bytecode to initiate a state save for state(A) is
        either carried in the compressed message, or can be retrieved by
        decompressor 2 from a state already saved at endpoint 2.
   (3): A save state request for state(A) is passed to the state handler
        using the END-MESSAGE instruction.  The application may then
        grant the state handler permission to save state(A): see
        [SIGCOMP].
   (4): Endpoint 2 decides to acknowledge state(A) to endpoint 1.  The
        state identifier (acked_state_id) for state(A) is placed in
        the SigComp message sent from compressor 2 to decompressor 1.
   (5): The UDVM bytecode to initiate (pass) the explicit
        acknowledgement to endpoint 1 is either carried in the
        compressed message, or can be retrieved by decompressor 1 from a
        state already saved at endpoint 1.
   (6): The acked_state_id for state(A) is passed to the state handler
        by placing the acked_state_id at the location of the
        "returned SigComp parameters" [SIGCOMP], whose location is given
        to the state handler using the END-MESSAGE instruction.

   Note: When the requested feedback length is non-zero endpoint
   initiated acknowledgements should not be used, due to possible waste
   of bandwidth.  When deciding to implement this mechanism one should
   consider whether this is worth the effort as all SigComp
   implementations will support the feedback mechanism and thus have the
   possibility to implement the mechanism of Section 5.1.1.

5.2.  Shared Compression

   To make use of shared compression a compressing endpoint saves the
   uncompressed version of the compressed message as a state (shared
   state).  As described in Section 2 the reference to a shared state is
   referred to as shared_state_id.  The shared state's parameters
   state_address and state_instruction must be set to zero.  The
   state_retention_priority must be set to 65535, and the other state
   parameters are set according to [SIGCOMP].  This is because different
   compression algorithms may be used to compress application messages
   traveling in different directions.  The shared state is also created
   on a per-compartment basis, i.e., the shared state is stored in the
   same memory as the states created by the particular remote



Hannu, et. al.               Informational                      [Page 9]

RFC 3321             SigComp - Extended Operations          January 2003


   compressor.  The choice of how to divide the state memory between
   "ordinary" states and shared states is an implementation decision at
   the compressor.  Note that new shared state items must not be created
   unless the compressor has made enough state memory available (as
   decompression failure could occur if the shared state pushed existing
   state out of the state memory buffer).

   A compressing endpoint must also indicate to the remote compressor
   that the shared state is available, but only if the local
   decompressor can retrieve the shared state.  The retrieval of the
   shared state is done according to the state retrieval instruction of
   the UDVM.

   Consider Figure 3.  An event flow for successful use of shared
   compression can be as follows:

   (1): Compressor 1 saves e.g., state(M), which is the uncompressed
        version of the current application message to be compressed and
        sent.
   (2): The UDVM bytecode to indicate the presence of state(M) at
        endpoint 1 is either carried in the compressed message, or can
        be retrieved by decompressor 2 from a state already saved at
        endpoint 2.
   (3): The SHA-1 instruction is used at endpoint 2 to calculate the
        shared_state_id for state(M).  The indication is passed to the
        state handler, by placing the shared identifier at the location
        of the "returned SigComp parameters" [SIGCOMP].  The location of
        the "returned SigComp parameters" is given to the state handler
        using the END-MESSAGE instruction.
   (4): If endpoint 2 uses shared compression, it compares the state
        identifier values in the "returned SigComp parameters"
        information with the value it has calculated for the current
        decompressed message received from endpoint 1.  If there is a
        match then endpoint 2 uses the shared state together with the
        state it would normally use if shared compression is not
        supported to compress the next message.
   (5): The UDVM bytecode that will use the shared state (state(M)) in
        the decompression process at decompressor 1 is either carried
        in the compressed message, or can be retrieved by decompressor 1
        from a state already saved at endpoint 1.

5.3.  Maintaining State Data Across Application Sessions

   Usually, signaling protocols (e.g., SIP) employ the concept of
   sessions.  However, from the compression point of view, the messages
   sent by the same source contain redundancies beyond the session
   boundary.  Consequently, it is natural to maintain the state data
   from the same source across sessions so that high performance can be



Hannu, et. al.               Informational                     [Page 10]

RFC 3321             SigComp - Extended Operations          January 2003


   achieved and maintained, with the overhead amortized over a much
   longer period of time than one application session.

   Maintaining states across application sessions can be achieved simply
   by making the lifetime of a compartment longer than the time duration
   of a single application session.  Note that the states here are
   referring to those stored on a per-compartment basis, not the locally
   available states that are stored on a global basis (i.e., not
   compartment specific).

5.4.  Use of User-Specific Dictionary

   The concept of the user-specific dictionary is based on the
   observation that for protocols such as SIP, a given user/device
   combination will produce some messages containing fields that are
   always populated with the same data.

   Take SIP as an example.  Capabilities of the SIP endpoints are
   communicated during session initiation, and tend not to change unless
   the capabilities of the device change.  Similarly, user-specific
   information such as the user's URL, name, and e-mail address will
   likely not change on a frequent basis, and will appear regularly in
   SIP signaling exchanges involving a specific user.

   Therefore, a SigComp compressor could include the user-specific
   dictionary as part of the initial messages to the decompressor, even
   before any time critical signaling messages are generated from a
   particular application.  This enables an increase in compression
   efficiency once the messages start to flow.

   Obviously, the user-specific dictionary is a state item that would be
   good to have as a cross-session state: see Section 5.3.

5.5.  Checkpoint State

   The following mechanism can be used to avoid decompression failure
   due to reference to a non-existent state.  This may occur in three
   cases: a) a state is not established at the remote SigComp endpoint
   due to the loss of a SigComp message; b) a state is not established
   due to insufficient memory; c) a state has been established but was
   deleted later due to insufficient memory.

   When a compressor sends a SigComp message that will create a new
   state on the decompressor side, it can indicate that the newly
   created state will be a checkpoint state by setting
   state_retention_priority [SIGCOMP] to the highest value sent by the
   same compressor.  In addition, a checkpoint state must be explicitly
   acknowledged by the receiving decompressor to the sending compressor.



Hannu, et. al.               Informational                     [Page 11]

RFC 3321             SigComp - Extended Operations          January 2003


   Consider Figure 3.  An event flow for this kind of state management
   can be as follows:

   (1): Compressor 1 saves e.g., state(A), which it would like to have
        as a checkpoint state at decompressor 2.
   (2): The UDVM bytecode to indicate the state priority ([SIGCOMP]
        state_retention_priority) of state(A) and initiate a state save
        for state(A) is either carried in the compressed message, or can
        be retrieved by decompressor 2 from a state already saved at
        endpoint 2.
   (3): A save state request for state(A) is passed to the state handler
        using the END-MESSAGE instruction, including the indication of
        the state priority.  The application grants the saving of
        state(A): see [SIGCOMP].
   (4): An acknowledgement for state(A) (the checkpoint state) is
        returned to endpoint 2 using one of the mechanisms described in
        Section 5.1.

   Note: To avoid using a state that has been deleted due to
   insufficient memory a compressor must keep track of the memory
   available for saving states at the remote endpoint.  The SigComp
   parameter state_memory_size which is announced by the SigComp
   feedback mechanism can be used to infer if a previous checkpoint
   state has been deleted (by a later checkpoint state creation request)
   due to lack of memory.

5.6.  Implicit Deletion for Dictionary Update

   Usually a state consists of two parts: UDVM bytecode and dictionary.
   When dynamic compression is applied, new content needs to be added to
   the dictionary.  To keep an upper bound of the memory consumption
   such as in the case for a low end mobile terminal, existing content
   of the dictionary must be deleted to make room for the new content.

   Instead of explicitly signaling which parts of the dictionary need to
   be deleted on a per message basis, an implicit deletion approach may
   be applied.  Specifically, some parts of the dictionary are chosen to
   be deleted according to a well-defined algorithm that is known and
   applied in the same way at both compressor and decompressor.  For
   instance, the algorithm can be part of the predefined UDVM bytecode
   that is agreed between the two SigComp endpoints.  As input to the
   algorithm, one provides the total number of bytes to be deleted.  The
   algorithm then specifies which parts of the dictionary are to be
   deleted.  Since the same algorithm is applied at both SigComp
   endpoints, there is no need for explicit signaling on a per message
   basis.  This may lead to higher compression efficiency due to the
   avoidance of




Hannu, et. al.               Informational                     [Page 12]

RFC 3321             SigComp - Extended Operations          January 2003


   signaling overhead.  It also means more robustness as there are no
   signaling bits on the wire that are subject to possible transmission
   errors/losses.

6.  Implications on SigComp

   The extended features will have implications on the SigComp messages
   sent between the compressor and its remote decompressor, and on how
   to interpret e.g., returned SigComp parameters [SIGCOMP].  However,
   except for the mandatory bytes of the SigComp messages [SIGCOMP], the
   final message formats used are implementation issues.  Note that an
   implementation that does not make use of explicit acknowledgements
   and/or shared compression is not affected, even if it receives this
   kind of feedback.

6.1.  Implications on SigComp Messages

   To support the extended features, SigComp messages must carry the
   indications and information addressed in Section 5.  For example to
   support shared compression and explicit acknowledgements the SigComp
   messages need to convey the following information:

   - The acked_state_id as described in Sections 2 and 5.1.
   - The shared_state_id as described in Sections 2 and 5.2.



























Hannu, et. al.               Informational                     [Page 13]

RFC 3321             SigComp - Extended Operations          January 2003


   Figure 4 depicts the format of a SigComp message according to
   [SIGCOMP]:

     0   1   2   3   4   5   6   7       0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1 | T |  len  |   | 1   1   1   1   1 | T |   0   |
   +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
   |                               |   |                               |
   :    returned feedback item     :   :    returned feedback item     :
   |                               |   |                               |
   +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
   |                               |   |           code_len            |
   :   partial state identifier    :   +---+---+---+---+---+---+---+---+
   |                               |   |   code_len    |  destination  |
   +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
   |                               |   |                               |
   :   remaining SigComp message   :   :    uploaded UDVM bytecode     :
   |                               |   |                               |
   +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
                                       |                               |
                                       :   remaining SigComp message   :
                                       |                               |
                                       +---+---+---+---+---+---+---+---+

                  Figure 4.  Format of a SigComp message

   The format of the field "remaining SigComp message" is an
   implementation decision by the compressor which supplies the UDVM
   bytecode.  Therefore there is no need to specify a message format to
   carry the information necessary for the extended features described
   in this document.




















Hannu, et. al.               Informational                     [Page 14]

RFC 3321             SigComp - Extended Operations          January 2003


   Figure 5 depicts an example of what the "remaining SigComp message"
   with support for shared compression and explicit acknowledgements,
   could look like.  Note that this is only an example; the format is an
   implementation decision.

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | Format according to Figure 4  |
   :   except for the field called :
   |   "remaining SigComp message" |   "remaining SigComp message" field
   +---+---+---+---+---+---+---+---+             --------
   | s | a | r |    Reserved       |                |
   +---+---+---+---+---+---+---+---+                |
   |                               |                |
   :       shared_state_id*        : Present if 's' is set
   |                               |                |
   +---+---+---+---+---+---+---+---+                |
   |                               |                |
   :       acked_state_id*         : Present if 'a' is set
   |                               |                |
   +---+---+---+---+---+---+---+---+                |
   |                               |                |
   :  Rest of the SigComp message  :                |
   |                               |                v
   +---+---+---+---+---+---+---+---+          --------------

   Figure 5. Example of SigComp message for some of the extended
             features.

   'r' : If set, then a state corresponding to the decompressed
         version of this compressed message (shared state) was saved at
         the compressor.
    *  : The length of the shared_state_id and acked_state_id fields
         are of the same length as the partial state identifier.

6.2.  Extended SigComp Announcement/Feedback Format

   This section describes how the "returned_SigComp_parameters"
   [SIGCOMP] information is interpreted to provide feedback according to
   Section 5.1 and 5.2.

   The partial_state_identifiers correspond to the hash_value for states
   that have been established at the remote endpoint after the reception
   of SigComp messages, i.e., these are acknowledgements for established
   states and may be used for compression.  The
   partial_state_identifiers may also announce "global state" that is
   not mapped to any particular compartment and is not established upon
   the receipt of a SigComp message.



Hannu, et. al.               Informational                     [Page 15]

RFC 3321             SigComp - Extended Operations          January 2003


   It is up to the implementation to deduce what kind of state each
   partial_state_identifier refers to, e.g., an acknowledged state or a
   shared state.  In case a SigComp message that includes state
   identifiers for shared states and/or acknowledged states is received
   by a basic SigComp implementation, these identifiers will be ignored.

   The I-bit of the requested feedback format is provided to switch off
   the list of locally available state items.  An endpoint that wishes
   to receive shared_state_id must not set the I-bit to 1.  The endpoint
   storing shared states and sending the list of locally available
   states to its remote endpoint must be careful when taking the
   decision whether to exclude or include different types of the locally
   available states (i.e., shared states or states of e.g., well-known
   algorithms) from/to the list.

6.3.  Acknowledgement Optimization

   If shared compression is used between two endpoints (see Figure 1)
   then there exists an optimization, which, if implemented, makes an
   acked_state_id in the SigComp message unnecessary:

   Compressor 1 saves a shared state(M), which is the uncompressed
   version of the current compressed message (message m) to be sent.
   Compressor 1 also sets bit 'r' (see Figure 5), to signal that
   state(M) can be used by endpoint 2 in the compression process.  The
   acked_state_id for state(S), which was created at endpoint 2 upon the
   decompression of message m, may not have to be explicitly placed in
   the compressed messages from compressor 2 if the shared state(M) is
   used in the compression process.

   When endpoint 1 notices that shared state(M) is requested by
   decompressor 1, it implicitly knows that state(S) was created at
   endpoint 2.  This follows since:

   * Compressor 1 has instructed decompressor 2 to save state(S).
   * The indication of shared state(M) would never have been received by
     compressor 2 if state(S) had not been successfully saved, because
     if a state save request is denied then the corresponding
     announcement information is discarded by the state handler.

   Note: Endpoint 1's state handler must maintain a mapping between
   state(M) and state(S) for this optimization to work.

   Note: The only state that is acknowledged by this feature is the
   state that was created by combining the state used for compression of
   the message and the message itself.  For any other case the
   acked_state_id has to be used.




Hannu, et. al.               Informational                     [Page 16]

RFC 3321             SigComp - Extended Operations          January 2003


   Note: There is a possibility that state(S) is discarded due to lack
   of state memory even though the announcement information is
   successfully forwarded.  This possibility must be taken into account
   (otherwise a decompression failure may occur); this can be done by
   using the SigComp parameter state_memory_size which is announced by
   the SigComp feedback mechanism.  The endpoint can use this parameter
   to infer if a state creation request has failed due to lack of
   memory.

7.  Security Considerations

   The features in this document are believed not to add any security
   risks to the ones mentioned in [SIGCOMP].

8.  IANA Considerations

   This document does not require any IANA involvement.

9.  Acknowledgements

   Thanks to Carsten Bormann, Christopher Clanton, Miguel Garcia, Lars-
   Erik Jonsson, Khiem Le, Mats Nordberg, Jonathan Rosenberg and Krister
   Svanbro for valuable input.

10.  Intellectual Property Right Considerations

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

11.  References

   [SIP]       Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
               A., Peterson, J., Sparks, R., Handley, M. and E.
               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
               June 2002.

   [SIGCOMP]   Price R., Bormann, C., Christoffersson, J., Hannu, H.,
               Liu, Z. and J. Rosenberg, "Signaling Compression
               (SigComp)", RFC 3320, January 2003.










Hannu, et. al.               Informational                     [Page 17]

RFC 3321             SigComp - Extended Operations          January 2003


12.  Authors' Addresses

   Hans Hannu
   Box 920
   Ericsson AB
   SE-971 28 Lulea, Sweden

   Phone: +46 920 20 21 84
   EMail: hans.hannu@epl.ericsson.se

   Jan Christoffersson
   Box 920
   Ericsson AB
   SE-971 28 Lulea, Sweden

   Phone: +46 920 20 28 40
   EMail: jan.christoffersson@epl.ericsson.se

   Stefan Forsgren

   EMail: StefanForsgren@alvishagglunds.se

   Ka-Cheong Leung
   Department of Computer Science
   Texas Tech University
   Lubbock, TX 79409-3104
   United States of America

   Phone: +1 806 742-3527
   EMail: kcleung@cs.ttu.edu

   Zhigang Liu
   Nokia Research Center
   6000 Connection Drive
   Irving, TX 75039, USA

   Phone: +1 972 894-5935
   EMail: zhigang.c.liu@nokia.com

   Richard Price
   Roke Manor Research Ltd
   Romsey, Hants, SO51 0ZN, United Kingdom

   Phone: +44 1794 833681
   EMail: richard.price@roke.co.uk






Hannu, et. al.               Informational                     [Page 18]

RFC 3321             SigComp - Extended Operations          January 2003


13.  Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Hannu, et. al.               Informational                     [Page 19]