A Negative Acknowledgement Mechanism for Signaling Compression
RFC 4077
|
Document |
Type |
|
RFC - Proposed Standard
(May 2005; No errata)
|
|
Author |
|
Adam Roach
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 4077 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Allison Mankin
|
|
Send notices to |
|
cabo@tzi.org, lars-erik.jonsson@ericsson.com
|
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
Show full document text