A Negative Acknowledgement Mechanism for Signaling Compression
RFC 4077

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                         A.B. Roach
Request for Comments: 4077                              Estacado Systems
Category: Standards Track                                       May 2005

     A Negative Acknowledgement Mechanism for Signaling Compression

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.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a mechanism that allows Signaling Compression
   (SigComp) implementations to report precise error information upon
   receipt of a message which cannot be decompressed.  This negative
   feedback can be used by the recipient to make fine-grained
   adjustments to the compressed message before retransmitting it,
   allowing for rapid and efficient recovery from error situations.

Roach                       Standards Track                     [Page 1]
RFC 4077                      SigComp NACK                      May 2005

Table of Contents

   1. Introduction ....................................................2
      1.1. The Problem ................................................2
           1.1.1. Compartment Disposal ................................3
           1.1.2. Client Restart ......................................3
           1.1.3. Server Failover .....................................3
      1.2. The Solution ...............................................4
   2. Node Behavior ...................................................4
      2.1. Normal SigComp Message Transmission ........................4
      2.2. Receiving a "Bad" SigComp Message ..........................5
      2.3. Receiving a SigComp NACK ...................................6
           2.3.1. Unreliable Transport ................................6
           2.3.2. Reliable Transport ..................................6
      2.4. Detecting Support for NACK .................................7
   3. Message Format ..................................................7
      3.1. Message Fields .............................................8
      3.2. Reason Codes ...............................................9
   4. Security Considerations ........................................13
      4.1. Reflector Attacks .........................................13
      4.2. NACK Spoofing .............................................13
   5. IANA Considerations ............................................14
   6. Acknowledgements ...............................................14
   7. References .....................................................14
      7.1. Normative References ......................................14
      7.2. Informative References ....................................14

1.  Introduction

   Signaling Compression [1], often called "SigComp", defines a protocol
   for transportation of compressed messages between two network
   elements.  One of the key features of SigComp is the ability of the
   sending node to request that the receiving node store state objects
   for later retrieval.

1.1.  The Problem

   While the "SigComp - Extended Operations" document [2] defines a
   mechanism that allows for confirmation of state creation, operational
   experience with the SigComp protocol has demonstrated that there are
   still several circumstances in which a sender's view of the shared
   state differs from the receiver's view.  A non-exhaustive list
   detailing the circumstances in which such failures may occur is
   below.

Roach                       Standards Track                     [Page 2]
RFC 4077                      SigComp NACK                      May 2005

1.1.1.  Compartment Disposal

   In SigComp, stored states are associated with compartments.
   Conceptually, the compartments represent one instance of a remote
   application.  These compartments are used to limit the amount of
   state that each remote application is allowed to store.  Compartments
   are created upon receipt of a valid SigComp message from a remote
   application.  In the current protocol, applications are expected to
   signal when they are finished with a compartment so that it can be
   deleted (by using the S-bit in requested feedback data).

   Unfortunately, expecting the applications to be well-behaved is not
   sufficient to prevent state from piling up.  Unexpected client
   failures, reboots, and loss of connectivity can cause compartments to
   become "stuck" and never removed.  To prevent this situation, it
   becomes necessary to implement a scheme by which compartments that
   appear disused may eventually be discarded.

   While the preceding facts make such a practice necessary, discarding