Network Working Group G. Pelletier
Request for Comments: 4164 Ericsson
Category: Standards Track August 2005
Network Working Group G. Pelletier
Request for Comments: 4164 Ericsson
Category: Standards Track August 2005
RObust Header Compression (ROHC): Context Replication for ROHC Profiles
健壮的头压缩（ROHC）：ROHC配置文件的上下文复制
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document defines context replication, a complement to the context initialization procedure found in Robust Header Compression (ROHC), as specified in RFC 3095. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure. It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows.
本文档定义了上下文复制，这是对RFC 3095中指定的健壮头压缩（ROHC）中上下文初始化过程的补充。定义对上下文复制的支持的概要文件可以使用本文描述的机制来基于另一个已经存在的上下文建立新上下文。引入上下文复制以减少上下文建立过程的开销。它对于压缩可能同时或几乎同时发生的多个短期流（例如短期TCP流）可能特别有用。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Context Replication for ROHC Profiles ...........................5
3.1. Robustness Considerations ..................................5
3.2. Replication of Control Fields ..............................5
3.3. Compressor States and Logic ................................6
3.3.1. Context Replication (CR) State ......................6
3.3.2. State Machine with Context Replication ..............7
3.3.3. State Transition Logic ..............................7
3.3.3.1. Selection of Base Context, Upward
Transition .................................8
3.3.3.2. Optimistic Approach, Upward Transition .....9
3.3.3.3. Optional Acknowledgements (ACKs),
Upward Transition ..........................9
3.3.3.4. Negative ACKs (NACKs), Downward
Transition .................................9
3.4. Decompressor Logic ........................................10
3.4.1. Replication and Context Initialization .............10
3.4.2. Reconstruction and Verification ....................10
3.4.3. Actions upon Failure ...............................11
3.4.4. Feedback Logic .....................................11
3.5. Packet Formats ............................................11
3.5.1. CRCs in the IR-CR Packet ...........................12
3.5.1.1. 7-bit CRC .................................13
3.5.1.2. 8-bit CRC .................................13
3.5.2. General Format of the IR-CR Packet .................13
3.5.3. Properties of the Base Context Identifier (BCID) ...15
4. Security Considerations ........................................15
5. Acknowledgements ...............................................15
6. References .....................................................16
6.1. Normative References ......................................16
6.2. Informative References ....................................16
Appendix A: General Format of the IR-CR Packet (Informative).......17
A.1. General Structure (Informative) ..........................17
A.2. Profile-Specific Replication Information (Informative) ...17
Appendix B: Inter-Profile Context Replication (Informative)........18
B.1. Defining Support for Inter-Profile Context Replication ...18
B.2. Compatibility between Different Profiles (Informative) ...19
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Context Replication for ROHC Profiles ...........................5
3.1. Robustness Considerations ..................................5
3.2. Replication of Control Fields ..............................5
3.3. Compressor States and Logic ................................6
3.3.1. Context Replication (CR) State ......................6
3.3.2. State Machine with Context Replication ..............7
3.3.3. State Transition Logic ..............................7
3.3.3.1. Selection of Base Context, Upward
Transition .................................8
3.3.3.2. Optimistic Approach, Upward Transition .....9
3.3.3.3. Optional Acknowledgements (ACKs),
Upward Transition ..........................9
3.3.3.4. Negative ACKs (NACKs), Downward
Transition .................................9
3.4. Decompressor Logic ........................................10
3.4.1. Replication and Context Initialization .............10
3.4.2. Reconstruction and Verification ....................10
3.4.3. Actions upon Failure ...............................11
3.4.4. Feedback Logic .....................................11
3.5. Packet Formats ............................................11
3.5.1. CRCs in the IR-CR Packet ...........................12
3.5.1.1. 7-bit CRC .................................13
3.5.1.2. 8-bit CRC .................................13
3.5.2. General Format of the IR-CR Packet .................13
3.5.3. Properties of the Base Context Identifier (BCID) ...15
4. Security Considerations ........................................15
5. Acknowledgements ...............................................15
6. References .....................................................16
6.1. Normative References ......................................16
6.2. Informative References ....................................16
Appendix A: General Format of the IR-CR Packet (Informative).......17
A.1. General Structure (Informative) ..........................17
A.2. Profile-Specific Replication Information (Informative) ...17
Appendix B: Inter-Profile Context Replication (Informative)........18
B.1. Defining Support for Inter-Profile Context Replication ...18
B.2. Compatibility between Different Profiles (Informative) ...19
There is often some redundancy between header fields of different flows that pass through the same compressor-decompressor pair. This means that some of the information needed to initialize the context for decompressing the headers of a new flow may already be present at the decompressor. It may be desirable to reuse this information and remove some of the overhead normally required for the initialization of a new header compression context at both the compressor and decompressor.
通过同一压缩机-减压器对的不同流的标题字段之间通常存在一些冗余。这意味着初始化上下文以解压缩新流的头所需的一些信息可能已经存在于解压器中。可能需要重用该信息，并消除在压缩器和解压缩器处初始化新的报头压缩上下文通常需要的一些开销。
Reducing the overhead of the context establishment procedure is particularly useful when multiple short-lived connections (or flows) occur simultaneously, or near-simultaneously, between the same compressor-decompressor pair. Because each new packet stream requires most of the header information to be sent during the initialization phase before smaller compressed headers can be used, a multitude of short-lived connections may significantly reduce the overall gain from header compression.
当同一压缩器-解压缩器对之间同时或几乎同时发生多个短期连接（或流）时，减少上下文建立过程的开销特别有用。由于每个新的分组流都需要在初始化阶段发送大部分报头信息，然后才能使用较小的压缩报头，因此大量短期连接可能会显著降低报头压缩的总体收益。
Context replication allows some header fields, such as the IP source and/or destination addresses (16 octets each for IPv6), to be omitted within the special Initiation and Refresh (IR) packet type specifically defined for replication. It also allows other fields, such as source and/or destination ports, to be either omitted or sent in a compressed form from the very first packet of the header compressed flow.
上下文复制允许在专门为复制定义的特殊启动和刷新（IR）数据包类型中省略某些头字段，例如IP源地址和/或目标地址（IPv6各16个八位字节）。它还允许从报头压缩流的第一个数据包中省略或以压缩形式发送其他字段，例如源和/或目标端口。
Context replication is herein defined as a general ROHC mechanism. The benefits of context replication are not limited to any particular protocol and its support may be defined for any ROHC profile.
本文将上下文复制定义为一种通用ROHC机制。上下文复制的好处不限于任何特定的协议，它的支持可以定义为任何ROHC配置文件。
In particular, context replication is applicable to TCP compression because many TCP transfers are short-lived; a behavior analysis of TCP/IP header fields among multiple short-lived connections may be found in [5]. In addition, [4] introduces considerations and requirements for the ROHC-TCP profile [3] to efficiently compress such short-lived TCP transfers.
特别是，上下文复制适用于TCP压缩，因为许多TCP传输都是短期的；在[5]中可以找到多个短期连接中TCP/IP头字段的行为分析。此外，[4]还介绍了ROHC-TCP配置文件[3]的注意事项和要求，以有效压缩此类短期TCP传输。
For profiles supporting this mechanism, the compressor performs context replication by reusing or creating a copy of an existing context, i.e., a base context, to create the replicated context. The replicated context is then updated to match the header fields of the new flow. The compressor then sends to the decompressor a packet that contains a reference to the selected base context, along with some data for the fields that need to be updated when creating the
对于支持此机制的概要文件，压缩器通过重用或创建现有上下文（即基本上下文）的副本来执行上下文复制，以创建复制的上下文。然后更新复制的上下文以匹配新流的头字段。然后，压缩器向解压缩器发送一个数据包，该数据包包含对所选基本上下文的引用，以及在创建基础上下文时需要更新的字段的一些数据
replicated context. Finally, the decompressor creates the replicated context based on the reference to the base context along with the uncompressed and compressed data from the received packet.
复制上下文。最后，解压器基于对基本上下文的引用以及来自所接收数据包的未压缩和压缩数据创建复制上下文。
This document specifies the context replication procedure for ROHC profiles. It defines the general compressor and decompressor logic used during context replication, as well as the general format of the special IR packet required for this procedure. Profiles defining support for context replication must further specify the specific format(s) of this packet.
本文件规定了ROHC配置文件的上下文复制程序。它定义了上下文复制期间使用的通用压缩器和解压缩器逻辑，以及此过程所需的特殊IR数据包的通用格式。定义上下文复制支持的配置文件必须进一步指定此数据包的特定格式。
The fundamentals of the ROHC framework may be found in [2]. It is assumed throughout this document that these are understood.
ROHC框架的基本原理见[2]。在本文件中，假设理解了这些内容。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
This document reuses some of the terminology found in [2]. In addition, this document defines the following terms:
本文档重用了[2]中的一些术语。此外，本文件定义了以下术语：
Base context
基本上下文
A base context is a context that has been validated by both the compressor and the decompressor. The compressor can use a base context as the reference when building a new context using replication.
基本上下文是由压缩器和解压缩器验证的上下文。在使用复制构建新上下文时，压缩器可以使用基本上下文作为引用。
Base CID (BCID)
基本CID（BCID）
The Base Context Identifier is the CID used to identify the base context, from which information needed for context replication can be extracted.
基本上下文标识符是用于标识基本上下文的CID，可以从中提取上下文复制所需的信息。
Context replication
上下文复制
Context replication is the mechanism that initializes a new context based on another already existing context (a base context).
上下文复制是一种基于另一个现有上下文（基本上下文）初始化新上下文的机制。
For profiles defining its support, context replication may be used as an alternative to the context initialization procedure found in [2]. Note that for such profiles, only the decompressor is mandated to support context replication; the use of the IR-CR packet is optional for the compressor.
对于定义其支持的概要文件，可以使用上下文复制作为[2]中上下文初始化过程的替代方法。注意，对于这样的配置文件，只有解压器被强制支持上下文复制；对于压缩机，可选择使用IR-CR数据包。
This section describes the compressor and decompressor logic as well as the general format of the IR packet used with context replication.
本节介绍压缩器和解压缩器逻辑以及用于上下文复制的IR数据包的一般格式。
Context replication deviates from the initialization procedure defined in [2] in that it is able to achieve a certain level of compression from the first packet used to initialize the context for a new flow. Therefore, it is of particular importance that the context replication procedure be robust. This requires that a base context suitable for replication be used, that the integrity of the initialization packet be guaranteed, and finally that the outcome of the replication process be verified.
上下文复制与[2]中定义的初始化过程不同，因为它能够从用于初始化新流上下文的第一个数据包实现一定程度的压缩。因此，上下文复制过程的健壮性尤为重要。这要求使用适合复制的基本上下文，保证初始化数据包的完整性，最后验证复制过程的结果。
The primary mechanisms used to achieve robustness of the context replication procedure are the selection of the base context (based on prior feedback from the decompressor) and the use of checksums. Specifically, the compressor must obtain enough confidence that the base context selected for replication is valid and available at the decompressor before initiating the replication procedure. Thus, the most reliable way to select the base context is to choose a context for which at least the static part to be replicated has previously been acknowledged by the decompressor.
用于实现上下文复制过程健壮性的主要机制是选择基本上下文（基于解压器的先前反馈）和使用校验和。具体地说，压缩器必须在启动复制过程之前获得足够的信心，以确保为复制选择的基本上下文在解压缩程序中有效且可用。因此，选择基本上下文的最可靠的方法是选择一个上下文，其中至少要复制的静态部分先前已被解压缩程序确认。
In addition, the presence of a CRC covering the information that initializes the context ensures the integrity of the IR header used for replication. Finally, an additional CRC calculated over the original uncompressed header allows the decompressor to validate the reconstructed header and the outcome of the replication process.
此外，包含初始化上下文信息的CRC的存在确保了用于复制的IR报头的完整性。最后，在原始未压缩报头上计算的附加CRC允许解压缩器验证重建的报头和复制过程的结果。
Control fields are fields that are either transmitted from a ROHC compressor to a ROHC decompressor or inferred based on the behavior of other fields, but are not part of the uncompressed header itself.
控制字段是从ROHC压缩器传输到ROHC解压缩器或根据其他字段的行为推断的字段，但不是未压缩标头本身的一部分。
They can be used to control compression and decompression behavior, in particular, the set of packet formats to be used. Control fields are profile-specific. Examples of such fields include the NBO and RND flags [2], which indicate whether the IP-ID field is in Network
它们可用于控制压缩和解压缩行为，特别是要使用的数据包格式集。控制字段是特定于配置文件的。此类字段的示例包括NBO和RND标志[2]，它们指示IP-ID字段是否在网络中
Byte Order and the type of behavior of the field, respectively. Another example is the parameter indicating the mode of operation [2].
字节顺序和字段的行为类型。另一个示例是指示操作模式的参数[2]。
The IR-CR differs from the IR packet [2] in that its purpose is to entirely specify what part of the base context is replicated, and to convey the complementary information needed to create a new context. Because of this, a profile supporting the use of the IR-CR packet SHOULD define for each control field if the value of the field is replicated from the base context to the new context, or if its value is reinitialized.
IR-CR与IR包[2]的不同之处在于，其目的是完全指定复制基础上下文的哪一部分，并传递创建新上下文所需的补充信息。因此，如果字段的值从基本上下文复制到新上下文，或者如果其值被重新初始化，则支持使用IR-CR数据包的概要文件应该为每个控制字段定义。
In addition, a compressor MUST NOT initiate context replication while a control field that is not reinitialized by replication is being updated, e.g., during the handshake for a mode transition [2].
此外，在更新未通过复制重新初始化的控制字段时（例如，在模式转换的握手期间），压缩器不得启动上下文复制[2]。
Compression with ROHC normally starts in the IR state, where IR packets must be sent to initialize a new context at the decompressor. IR packets include all static and non-static fields of the original header in uncompressed form plus some additional information. The compressor stays in the IR state until it obtains confidence that the decompressor has received the information.
ROHC压缩通常在IR状态下开始，在该状态下，必须发送IR数据包以在解压缩程序中初始化新上下文。IR数据包以未压缩的形式包括原始报头的所有静态和非静态字段以及一些附加信息。压缩机保持在IR状态，直到其确信减压器已收到信息。
Context replication provides an optional mechanism to complement the ROHC initialization procedure. It defines a packet type, the IR packet for Context Replication (IR-CR), which can be used to initialize a new context. Consequently, the Context Replication (CR) state is introduced to the compressor state machine to encompass the additional logic required for the use of the IR-CR packet.
上下文复制提供了一种可选机制来补充ROHC初始化过程。它定义了一种数据包类型，即用于上下文复制的IR数据包（IR-CR），可用于初始化新上下文。因此，上下文复制（CR）状态被引入到压缩器状态机以包含使用IR-CR分组所需的附加逻辑。
For profiles defining support for context replication, the compressor may thus transit directly from the IR state to the CR state if an already existing context can be selected as a base context for replication. This effectively replaces any IR/IR-DYN packets sent during the context establishment procedure with an IR-CR packet.
对于定义上下文复制支持的概要文件，如果可以选择已经存在的上下文作为复制的基本上下文，则压缩器可以直接从IR状态过渡到CR状态。这有效地将上下文建立过程中发送的任何IR/IR-DYN数据包替换为IR-CR数据包。
The purpose of the CR state is to initialize a new context by reusing an already existing context. In this state, the compressor sends a combination of uncompressed and compressed information, along with a reference to a base context plus some additional information. Therefore, header information pertaining to fields that are being replicated is not sent.
CR状态的目的是通过重用已经存在的上下文来初始化新上下文。在此状态下，压缩器发送未压缩和压缩信息的组合，以及对基本上下文的引用和一些附加信息。因此，不会发送与正在复制的字段相关的标头信息。
The compressor stays in the CR state until it is confident that the decompressor has received the replication information correctly.
压缩器将保持在CR状态，直到确信解压缩器已正确接收复制信息。
The compressor always starts in the lower compression state (IR), and transits to the context replication state (CR) under the constraint that the compressor can select a base context that is suitable for the flow being compressed (see also Section 3.3.3.1).
压缩机始终在较低压缩状态（IR）下启动，并在压缩机可以选择适合被压缩流的基本上下文的约束下过渡到上下文复制状态（CR）（另请参见第3.3.3.1节）。
The transition from the CR state to a higher compression state (e.g., the CO state for [3]) is based on the optimistic approach principle or feedback received from the decompressor.
从CR状态到更高压缩状态（例如，[3]的CO状态）的转换基于乐观方法原理或从解压缩器接收到的反馈。
The figure below shows the additional state for the compressor. The details of the state transitions and compression logic are given in sub-sections following the figure.
下图显示了压缩机的附加状态。状态转换和压缩逻辑的详细信息在下图的小节中给出。
BCID selection Optimistic approach / ACK
+----->----->------+ +----->----->----->-----+
| | | |
| v | v
+---------+ +---------+ +-------------+
| IR | | CR | | Higher |
| state | | state | | order state |
+---------+ +---------+ +-------------+
^ |
| NACK / STATIC-NACK |
+---<-----<-----<----+
BCID selection Optimistic approach / ACK
+----->----->------+ +----->----->----->-----+
| | | |
| v | v
+---------+ +---------+ +-------------+
| IR | | CR | | Higher |
| state | | state | | order state |
+---------+ +---------+ +-------------+
^ |
| NACK / STATIC-NACK |
+---<-----<-----<----+
Note that context replication is a complement to the normal initialization procedure for ROHC profiles that support it. Therefore, the compressor transition to the CR state is an optional addition to the state machine, and does not affect already existing transitions between the IR state and higher order state(s).
请注意，上下文复制是对支持它的ROHC配置文件的正常初始化过程的补充。因此，压缩机到CR状态的转换是状态机的可选添加，并且不会影响IR状态和高阶状态之间已经存在的转换。
Decisions about transition to and from the CR state are taken by the compressor on the basis of:
压缩机根据以下条件决定CR状态的转换：
- availability of a base context - positive feedback from the decompressor (Acknowledgements -- ACKs) - negative feedback from the decompressor (Negative ACKs -- NACKs) - confidence level regarding error-free decompression of a packet
- 基本上下文的可用性-来自解压器的正反馈（确认--确认）-来自解压器的负反馈（负确认--nack）-关于数据包无错误解压的置信水平
Context replication is designed to operate over links where a feedback channel is available. This is necessary to ensure that the information used to create a new context is synchronized between the compressor and the decompressor. In addition, context replication may also make use of feedback from decompressor to compressor for transition back to the IR state and for OPTIONAL improved forward transition towards a state with a higher compression ratio.
上下文复制设计用于在反馈通道可用的链路上运行。这对于确保用于创建新上下文的信息在压缩器和解压缩器之间同步是必要的。此外，上下文复制还可以利用从解压器到压缩器的反馈，用于转换回IR状态，并用于可选地改进向具有更高压缩比的状态的前向转换。
The format that must be used by all profiles for the feedback field within the general ROHC format is specified in Section 5.2.2 of [2]; the feedback information is structured using two possible formats: FEEDBACK-1 and FEEDBACK-2. In particular, FEEDBACK-2 can carry one of three possible types of feedback information: ACK, NACK, or STATIC-NACK.
[2]的第5.2.2节规定了通用ROHC格式中反馈字段的所有配置文件必须使用的格式；反馈信息采用两种可能的格式：feedback-1和feedback-2。特别地，反馈-2可以携带三种可能类型的反馈信息中的一种：ACK、NACK或STATIC-NACK。
The compressor may initiate a transition from the IR state to the CR state when a suitable base context can be identified. To perform this transition, the compressor selects a context that has previously been acknowledged by the decompressor as the base context. The selected context MUST have been acknowledged by the decompressor using the CRC option (see also [2], Section 5.7.6.3) in the feedback message. The static part of the base context to be replicated MUST have been acknowledged by the decompressor and the base context MUST be valid at replication time.
当可以识别合适的基本上下文时，压缩器可以启动从IR状态到CR状态的转换。要执行此转换，压缩器将选择先前已由解压缩器确认的上下文作为基本上下文。解压缩程序必须在反馈消息中使用CRC选项（另见[2]，第5.7.6.3节）确认所选上下文。要复制的基本上下文的静态部分必须已被解压缩程序确认，并且基本上下文在复制时必须有效。
This also implies that a compressor is not allowed to use the context replication mechanism if a feedback channel is not present. However, note that the presence of the feedback channel cannot provide the guarantee that a base context selected for replication has not been corrupted after it has been acknowledged, or that it is still part of the state managed by the decompressor when the IR-CR will be received.
这还意味着，如果反馈通道不存在，则不允许压缩器使用上下文复制机制。然而，请注意，反馈通道的存在不能保证为复制选择的基本上下文在被确认后没有被破坏，或者在接收IR-CR时它仍然是由解压器管理的状态的一部分。
More specifically, RFC 3095 [2] defines the context identifier (CID) as a reference to the state information (i.e., the context) used for compression and decompression. Multiple packet streams, each having its own context, may thus share a channel; and the CID space along with its representation within packet formats may be negotiated as part of the channel state. However, because RFC 3095 [2] does not explicitly define context state management between compressor and decompressor, in particular for connection-oriented flows (e.g., TCP), no more than a high degree of confidence can be achieved when selecting a base context.
更具体地说，RFC 3095[2]将上下文标识符（CID）定义为对用于压缩和解压缩的状态信息（即上下文）的引用。因此，多个分组流（每个分组流具有其自己的上下文）可以共享一个信道；并且CID空间及其在分组格式内的表示可以作为信道状态的一部分进行协商。然而，由于RFC 3095[2]没有明确定义压缩器和解压器之间的上下文状态管理，特别是对于面向连接的流（例如TCP），因此在选择基本上下文时只能实现高度的置信度。
In the case where feedback is not used by the decompressor, the compressor may have to periodically transit back to the IR state. In such a case, the same logic applies for the transition back to the higher order state via the CR state: a base context, previously acknowledged and suitable for replication, must be re-selected.
在减压器不使用反馈的情况下，压缩机可能必须周期性地转换回IR状态。在这种情况下，同样的逻辑适用于通过CR状态转换回高阶状态：必须重新选择先前已确认且适合复制的基本上下文。
The criteria for whether an existing context is a suitable base context for replication for a new flow are left to implementations.
现有上下文是否是新流复制的合适基础上下文的标准留给实现。
Whenever the sequencing information from the last acknowledgement received is available, the compressor MAY use it to determine what fields can be replicated to avoid replicating any fields that have changed significantly from the state corresponding to the acknowledged packet.
每当来自最后接收到的确认的序列信息可用时，压缩器可以使用它来确定哪些字段可以被复制，以避免复制与所确认的分组相对应的状态发生显著变化的任何字段。
Transition to a higher order state can be carried out according to the optimistic approach principle. This means that the compressor may perform an upward state transition when it is fairly confident that the decompressor has received enough information to correctly decompress packets sent according to the higher compression state.
根据乐观逼近原理，可以实现向高阶状态的过渡。这意味着，当相当确信解压缩器已经接收到足够的信息以正确解压缩根据更高压缩状态发送的分组时，压缩器可以执行向上状态转换。
In general, there are many approaches where the compressor can obtain such information. The compressor may obtain its confidence by sending several IR-CR packets with the same information.
一般来说，压缩机可以通过多种方法获得此类信息。压缩器可通过发送具有相同信息的多个IR-CR分组来获得其置信度。
An ACK may be sent by the decompressor to indicate that a context has been successfully initialized during context replication.
解压器可以发送ACK，以指示上下文在上下文复制期间已成功初始化。
Upon reception of an ACK, the compressor may assume that the context replication procedure was successful and transit from its initial state (e.g., IR state) to a higher compression state.
在接收到ACK时，压缩器可以假设上下文复制过程是成功的，并且从其初始状态（例如，IR状态）过渡到更高的压缩状态。
A STATIC-NACK sent by the decompressor may indicate that the decompressor could not initialize a valid context during context replication, and that the corresponding context has been invalidated.
解压器发送的静态NACK可能表示解压器无法在上下文复制期间初始化有效上下文，并且相应的上下文已无效。
Upon reception of a STATIC-NACK, the compressor MUST transit back to its initial no context state. The compressor SHOULD also refrain from sending IR-CR packets using the same base context, at least until an acknowledgement subsequent to the reception of the
接收到静态NACK后，压缩器必须转换回其初始无上下文状态。压缩器还应避免使用相同的基本上下文发送IR-CR分组，至少在接收到消息之后的确认之前
STATIC-NACK makes this context suitable for replication (Section 3.3.3.1). The compressor SHOULD re-initialize the decompressor context using an IR packet.
静态NACK使该上下文适合于复制（第3.3.3.1节）。压缩器应使用IR数据包重新初始化解压缩器上下文。
A NACK sent by the decompressor may indicate that a valid context has been successfully initialized but that the decompression of one or more subsequent packets has failed.
解压器发送的NACK可指示有效上下文已成功初始化，但一个或多个后续分组的解压已失败。
Upon reception of a NACK, the compressor MAY assume that the static part of the decompressor context is valid, but that the dynamic part is invalid; the compressor may take actions accordingly.
在接收到NACK时，压缩器可以假设解压缩器上下文的静态部分有效，但动态部分无效；压缩机可采取相应的措施。
Upon reception of an IR-CR packet, the decompressor first determines its content ([2], Section 5.2.6). The profile indicated in the IR-CR packet determines how it is to be processed. If the CRC (8-bit CRC) fails to verify the packet, the packet MUST be discarded.
在接收到IR-CR数据包后，解压缩器首先确定其内容（[2]，第5.2.6节）。IR-CR数据包中指示的配置文件确定如何处理该数据包。如果CRC（8位CRC）无法验证数据包，则必须丢弃该数据包。
If the profile as indicated in the IR-CR packet defines the use of the Base CID, and if its corresponding field is present within the packet format, this field is used to identify the base context; otherwise, the CID is used.
如果IR-CR数据包中指示的配置文件定义了基本CID的使用，并且如果其对应字段存在于数据包格式中，则该字段用于标识基本上下文；否则，将使用CID。
The decompressor creates a new context using the information present in the IR-CR packet together with the identified base context, and decompresses the original header.
解压器使用IR-CR数据包中存在的信息以及识别的基本上下文创建新上下文，并解压原始头。
The CRC calculated over the original uncompressed header and carried within the profile-specific part of the IR-CR headers (7-bit CRC) MUST be used to verify decompression.
必须使用在原始未压缩标头上计算并在IR-CR标头（7位CRC）的配置文件特定部分中携带的CRC来验证解压缩。
When the decompression is verified and successful, the decompressor initializes or updates the context with the information received in the current header. The decompressor SHOULD send an ACK when it successfully validates the context as a result of the decompression of one or more IR-CR packets.
当解压被验证并成功时，解压器使用当前头中接收到的信息初始化或更新上下文。解压器在成功验证一个或多个IR-CR数据包解压后的上下文时，应发送ACK。
Otherwise, if the reconstructed header fails the CRC check, changes (either initialization or update) to the context MUST NOT be performed. When the decompressor fails to validate the header, actions as specified in Section 3.4.3 are taken.
否则，如果重建的报头未通过CRC检查，则不得执行上下文更改（初始化或更新）。当解压器无法验证标头时，将采取第3.4.3节中规定的措施。
For profiles supporting context replication, the feedback logic of a decompressor is similar to the logic used for context initialization, as described in [2].
对于支持上下文复制的概要文件，解压缩器的反馈逻辑类似于用于上下文初始化的逻辑，如[2]所述。
Specifically, when the decompressor fails to validate the context following the decompression of one or more initial IR-CR packets, it MUST invalidate the context and remain in its initial state. In addition, the decompressor SHOULD send a STATIC-NACK. In particular, a decompressor implementation performing strict memory management, such as deleting context state information when a connection-oriented flow (e.g., TCP) is known to have terminated, SHOULD send STATIC-NACK in this case. Otherwise, there is a risk that the compressor will maintain a specific CID as a potential candidate for a later replication attempt, while actually there is insufficient state left in the decompressor for this CID to act as a Base CID.
具体地说，当解压器在一个或多个初始IR-CR数据包解压后未能验证上下文时，它必须使上下文无效并保持其初始状态。此外，解压器应发送静态NACK。具体而言，在这种情况下，执行严格内存管理（例如，当已知面向连接的流（例如TCP）已终止时删除上下文状态信息）的解压缩器实现应发送STATIC-NACK。否则，压缩器可能会保留一个特定的CID作为以后复制尝试的潜在候选，而实际上解压器中没有足够的状态使该CID充当基本CID。
If the context has been successfully validated from the decompression of one or more initial IR-CR packets, the decompressor SHOULD send a NACK when it fails to verify the context following the decompression of one or more subsequent IR-CR packets.
如果已通过一个或多个初始IR-CR数据包的解压缩成功验证了上下文，则当解压缩器在一个或多个后续IR-CR数据包解压缩后未能验证上下文时，应发送NACK。
The decompressor SHOULD use the CRC option (see [2], Section 5.7.6.3) when sending feedback corresponding to an IR or an IR-CR packet.
当发送与IR或IR-CR数据包对应的反馈时，解压器应使用CRC选项（见[2]，第5.7.6.3节）。
The format of the IR-CR packet has been designed under the following constraints:
IR-CR数据包的格式是在以下约束条件下设计的：
a) it must be possible to either overwrite a CID during context
replication, or to use a different CID than the Base CID for the
replicated context;
b) it must be possible to selectively include or exclude from the
packet format some fields that may be replicable;
c) it must be possible for some fields that may be replicable to be
represented within the packet format using either a compressed or
an uncompressed form;
d) it must be possible for the decompressor to verify the success of
the replication procedure;
e) it is anticipated that profiles, other than ROHC-TCP [3], will
also define support for context replication. Therefore it is
desirable that the packet format be profile independent.
a) it must be possible to either overwrite a CID during context
replication, or to use a different CID than the Base CID for the
replicated context;
b) it must be possible to selectively include or exclude from the
packet format some fields that may be replicable;
c) it must be possible for some fields that may be replicable to be
represented within the packet format using either a compressed or
an uncompressed form;
d) it must be possible for the decompressor to verify the success of
the replication procedure;
e) it is anticipated that profiles, other than ROHC-TCP [3], will
also define support for context replication. Therefore it is
desirable that the packet format be profile independent.
The IR packet, as defined in [2], is used to communicate static and/or dynamic parts of a context, and typically initialize the context. For example, the static and dynamic chains of IR packets may contain an uncompressed representation of the original header.
[2]中定义的IR数据包用于通信上下文的静态和/或动态部分，并且通常初始化上下文。例如，IR分组的静态和动态链可以包含原始报头的未压缩表示。
The IR packet format includes an 8-bit CRC, calculated over the initial part of the IR packet. This CRC is meant to protect any information that initializes the context. In particular, its coverage always includes any CID information as well as the profile used to interpret the remainder of the IR packet.
IR分组格式包括在IR分组的初始部分上计算的8位CRC。此CRC旨在保护初始化上下文的任何信息。特别是，其覆盖范围始终包括任何CID信息以及用于解释IR数据包其余部分的概要文件。
The purpose of the 8-bit CRC is to ensure the integrity of the IR header itself. Profiles may extend the coverage of this CRC to include the entire IR header, thus allowing the verification of the integrity of the entire uncompressed header. However, because the format of the IR packet is common to all ROHC profiles and verified as part of the initial processing of a ROHC decompressor (see [2], Section 5.2.6.), profiles may not redefine this CRC beyond the extent of its coverage.
8位CRC的目的是确保IR报头本身的完整性。配置文件可以扩展该CRC的覆盖范围以包括整个IR报头，从而允许验证整个未压缩报头的完整性。然而，由于IR数据包的格式对于所有ROHC配置文件都是通用的，并且作为ROHC解压器初始处理的一部分进行验证（见[2]，第5.2.6节），因此配置文件可能不会在其覆盖范围之外重新定义此CRC。
RFC 3095 [2] also defines a 3-bit CRC and a 7-bit CRC for compressed headers, used to verify proper decompression and validate the context. This type of CRC is calculated over the original uncompressed header, as it is not sufficient to protect only the compressed data being exchanged between compressor and decompressor for the purpose of ensuring a robust reconstruction of the original header.
RFC 3095[2]还为压缩头定义了3位CRC和7位CRC，用于验证正确的解压缩和验证上下文。这种类型的CRC是在原始未压缩报头上计算的，因为仅保护压缩机和解压器之间交换的压缩数据不足以确保原始报头的稳健重建。
Thus, there is a clear distinction in purpose between the 8-bit CRC found in the IR packet and the 3-bit or 7-bit CRC found in compressed headers. With context replication, where the IR-CR packet may contain both compressed as well as uncompressed information and omit entirely replicable fields, this distinction in no longer present.
因此，在IR分组中发现的8位CRC和在压缩报头中发现的3位或7位CRC之间存在目的上的明确区别。在上下文复制中，IR-CR数据包可能同时包含压缩和未压缩的信息，并且省略完全可复制的字段，这种区别不再存在。
Profiles supporting context replication MUST define a CRC over the original uncompressed header as part of the profile-specific information in the IR-CR packet. This is necessary to allow a decompressor to verify that the replication process has succeeded.
支持上下文复制的配置文件必须在原始未压缩头上定义CRC，作为IR-CR数据包中配置文件特定信息的一部分。这是允许解压缩程序验证复制过程是否成功所必需的。
The 7-bit CRC in the IR-CR packet is calculated over all octets of the entire original header, before replication, in the same manner as described in Section 5.9.2 of [2].
在复制之前，IR-CR数据包中的7位CRC在整个原始报头的所有八位字节上进行计算，计算方式与[2]第5.9.2节所述相同。
The initial content of the CRC register is to be preset to all 1's. The CRC polynomial used for the 7-bit CRC in the IR-CR is:
CRC寄存器的初始内容将预设为所有1。IR-CR中用于7位CRC的CRC多项式为：
C(x) = 1 + x + x^2 + x^3 + x^6 + x^7
C(x) = 1 + x + x^2 + x^3 + x^6 + x^7
The coverage of the 8-bit CRC in the IR-CR packet is not profile dependent, as opposed to the ROHC IR(-DYN) packet (see [2], Sections 5.2.3 and 5.2.4). It MUST cover the entire packet, excluding the payload. In particular, this includes the CID or any add-CID octet as well as the Base CID field, if present. For profiles that define the usage of the Base CID within the packet format of the IR-CR as optional, this CRC MUST also cover the information used to indicate the presence of this field within the packet.
与ROHC IR（-DYN）数据包相反，IR-CR数据包中8位CRC的覆盖范围不依赖于配置文件（见[2]，第5.2.3和5.2.4节）。它必须覆盖整个数据包，不包括有效负载。特别是，这包括CID或任何添加CID八位字节以及基本CID字段（如果存在）。对于将IR-CR数据包格式内基本CID的使用定义为可选的配置文件，该CRC还必须包括用于指示数据包内存在该字段的信息。
The initial content of the CRC register is to be preset to all 1's. The CRC polynomial used for the 8-bit CRC in the IR-CR is:
CRC寄存器的初始内容将预设为所有1。IR-CR中用于8位CRC的CRC多项式为：
C(x) = 1 + x + x^2 + x^8
C(x) = 1 + x + x^2 + x^8
The context replication mechanism requires a dedicated IR packet format that uniquely identifies the IR-CR packet. This packet communicates the static and the dynamic parts of the replicated context. It may also communicate a reference to a base context.
上下文复制机制需要专用的IR数据包格式，该格式唯一标识IR-CR数据包。此数据包通信复制上下文的静态和动态部分。它还可以传递对基本上下文的引用。
With consideration to the extensibility of the IR packet type defined in [2], support for replication can be added using the profile-specific part of the IR packet. Note that there is one bit, (x), left in the IR header for "Profile specific information". The definition of this bit is profile specific. Thus, profiles supporting context replication MAY use this bit as a flag indicating whether the packet is an IR packet or an IR-CR packet. Note also that profiles may define an alternative method to identify the IR-CR packet within the profile-specific information, instead of using this bit.
考虑到[2]中定义的IR数据包类型的可扩展性，可以使用IR数据包的配置文件特定部分添加对复制的支持。请注意，IR标题中有一位（x）用于“配置文件特定信息”。此位的定义是特定于配置文件的。因此，支持上下文复制的概要文件可以使用该位作为指示分组是IR分组还是IR-CR分组的标志。还注意，简档可以定义替代方法来识别简档特定信息内的IR-CR分组，而不是使用该比特。
The IR-CR header associates a CID with a profile, and initializes the context using the context replication mechanism. It is not recommended to use this packet to repair a damaged context.
IR-CR标头将CID与配置文件关联，并使用上下文复制机制初始化上下文。不建议使用此数据包修复损坏的上下文。
The IR-CR has the following general format:
IR-CR具有以下通用格式：
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Profile-specific information / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Profile-specific information / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
x: Profile-specific information. Interpreted according to the profile indicated in the Profile field.
x：配置文件特定信息。根据配置文件字段中指示的配置文件进行解释。
Profile: The profile to be associated with the CID. In the IR-CR packet, the profile identifier is abbreviated to the 8 least significant bits (LSBs). It selects the highest-number profile in the channel state parameter PROFILES that matches the 8 LSBs given (see also [2]).
配置文件：要与CID关联的配置文件。在IR-CR分组中，简档标识符缩写为8个最低有效位（lsb）。它在信道状态参数配置文件中选择与给定的8个LSB匹配的最大数量配置文件（另请参见[2]）。
CRC: 8-bit CRC computed using the polynomial of Section 3.5.1.2.
CRC：使用第3.5.1.2节中的多项式计算的8位CRC。
Profile-specific information: The contents of this part of the IR-CR packet are defined by the individual profiles. This information is interpreted according to the profile indicated in the Profile field. It MUST include a 7-bit CRC over the original uncompressed header using the polynomial of Section 3.5.1.1. It also includes the static and dynamic subheader information used for replication; thus, which header fields are replicated and their respective encoding methods are outside the scope of this document.
配置文件特定信息：IR-CR数据包的这部分内容由各个配置文件定义。该信息根据profile字段中指示的profile进行解释。必须使用第3.5.1.1节中的多项式在原始未压缩报头上包含7位CRC。它还包括用于复制的静态和动态子标题信息；因此，复制哪些标头字段及其各自的编码方法超出了本文档的范围。
Payload: The payload of the corresponding original packet, if any.
有效载荷：对应原始数据包的有效载荷（如果有）。
The Base CID within the packet format of the IR-CR may be assigned a different value than the context identifier associated with the new flow (i.e., BCID != CID); otherwise, the base context is overwritten with the new context by the replication process.
IR-CR的分组格式内的基本CID可以被分配与与新流相关联的上下文标识符不同的值（即，BCID！=CID）；否则，复制过程将用新上下文覆盖基本上下文。
When the channel uses small CIDs, a four-bit field within the packet format of the IR-CR minimally represents the BCID with a value from 0 to 15. In particular, the four bits of Add-CID used with small CIDs [2] are not needed for the BCID, as this information is already provided by the CID of the IR-CR packet itself. When large CIDs are used, the BCID is represented in the IR-CR with one or two octets, and it is coded in the same way as a large CID [2].
当信道使用小cid时，IR-CR的分组格式内的四位字段最小地表示具有0到15的值的BCID。特别地，对于BCID不需要与小CID一起使用的Add CID的四位[2]，因为该信息已经由IR-CR分组本身的CID提供。当使用大的CID时，BCID在IR-CR中用一个或两个八位字节表示，并以与大的CID相同的方式进行编码[2]。
This document adds an alternative mechanism for ROHC profiles to increase the compression efficiency when initializing a new context, by reusing information already existing at the decompressor. This is achieved by introducing new state transition logic, new feedback logic, and a new packet type -- all based on logic and packet formats already defined in RFC 3095 [2].
本文档为ROHC概要文件添加了一种替代机制，通过重用解压器中已有的信息，在初始化新上下文时提高压缩效率。这是通过引入新的状态转换逻辑、新的反馈逻辑和新的数据包类型实现的——所有这些都基于RFC3095[2]中已经定义的逻辑和数据包格式。
In this respect, this document is not believed to bring any additional weakness to potential attacks to those already listed in [2]. However, it does increase the potential impacts of these attacks by creating dependencies between multiple contexts. Specifically, corruption of one context can fail compressor attempts to initialize another context at the decompressor, or to propagate to another context, if the compressor uses a corrupted context as a base for replication.
在这方面，本文件不会给[2]中已经列出的潜在攻击带来任何额外的弱点。但是，它通过在多个上下文之间创建依赖关系，增加了这些攻击的潜在影响。具体地说，如果压缩器使用损坏的上下文作为复制的基础，则一个上下文的损坏可能会导致压缩器尝试在解压缩器处初始化另一个上下文或传播到另一个上下文失败。
The author would like to thank Richard Price, Kristofer Sandlund, Fredrik Lindstroem, Zhigang Liu, and HongBin Liao for valuable input, as well as Mark West and Lars-Erik Jonsson who also served as committed working group document reviewers.
作者要感谢Richard Price、Kristofer Sandlund、Fredrik Lindstroem、Liu Zhigang和Liao HongBin的宝贵意见，以及Mark West和Lars Erik Jonsson，他们也是工作组文件审查员。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[2] Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP和未压缩”，RFC 3095，2001年7月。
[3] Pelletier, G., Jonsson, L-E., Sandlund, K., and M. West, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", Work in Progress, July 2005.
[3] Pelletier，G.，Jonsson，L-E.，Sandlund，K.，和M.West，“鲁棒头压缩（ROHC）：TCP/IP配置文件（ROHC-TCP）”，正在进行的工作，2005年7月。
[4] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression", RFC 4163, August 2005.
[4] Jonsson，L-E.“鲁棒头压缩（ROHC）：TCP/IP头压缩的要求”，RFC 41632005年8月。
[5] West, M. and S. McCann, "TCP/IP Field Behavior", Work in Progress, October 2004.
[5] West，M.和S.McCann，“TCP/IP现场行为”，正在进行的工作，2004年10月。
[6] Finking, R. and G. Pelletier, "Formal Notation for Robust Header Compression (ROHC-FN)", Work in Progress, June 2005.
[6] Finking，R.和G.Pelletier，“鲁棒头压缩的形式表示法（ROHC-FN）”，正在进行的工作，2005年6月。
Appendix A: General Format of the IR-CR Packet (Informative)
附录A：IR-CR数据包的通用格式（资料性）
This section provides an example of the format of the profile-specific information within the general format of the IR-CR.
本节提供了IR-CR通用格式中配置文件特定信息的格式示例。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| |
/ replication base information / variable length
| |
+---+---+---+---+---+---+---+---+
| |
/ replication information / variable length
| |
- - - - - - - - - - - - - - - -
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| |
/ replication base information / variable length
| |
+---+---+---+---+---+---+---+---+
| |
/ replication information / variable length
| |
- - - - - - - - - - - - - - - -
Replication base information: The contents of this part of the IR-CR packet are defined by the individual profiles. This information is interpreted according to the profile indicated in the Profile field. It MUST include a 7-bit CRC over the original uncompressed header using the polynomial of Section 3.4.1.1. See Appendix A.2.
复制基础信息：IR-CR数据包这一部分的内容由各个配置文件定义。该信息根据profile字段中指示的profile进行解释。必须使用第3.4.1.1节中的多项式在原始未压缩报头上包含7位CRC。见附录A.2。
Replication information: The contents of this part of the IR-CR packet are also defined by the individual profiles. This part contains the static and dynamic subheader information used for replication. How this information is structured is profile specific; profiles may define the contents of this field using a chain structure (static and dynamic replication chains) or by defining header formats for replication (e.g., ROHC-TCP [3]).
复制信息：IR-CR数据包这一部分的内容也由各个配置文件定义。此部分包含用于复制的静态和动态子标题信息。这些信息的结构是特定于个人资料的；配置文件可以使用链结构（静态和动态复制链）或通过定义复制头格式（例如ROHC-TCP[3]）来定义此字段的内容。
This section provides a more detailed example of the possible format of the replication information field described in Appendix A.1:
本节提供了附录a.1中描述的复制信息字段可能格式的更详细示例：
+---+---+---+---+---+---+---+---+
| B | CRC7 | 1 octet
+---+---+---+---+---+---+---+---+
| | present if B = 1,
/ Base CID / 1 octet if for small CIDs, or
| | 1-2 octets if for large CIDs
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| B | CRC7 | 1 octet
+---+---+---+---+---+---+---+---+
| | present if B = 1,
/ Base CID / 1 octet if for small CIDs, or
| | 1-2 octets if for large CIDs
+---+---+---+---+---+---+---+---+
B: B = 1 indicates that the Base CID field is present.
B:B=1表示存在基本CID字段。
CRC7: The CRC over the original, uncompressed, header. This 7-bit CRC is computed according to Section 3.4.1.1.
CRC7：原始未压缩标头上的CRC。根据第3.4.1.1节计算该7位CRC。
Base CID: The CID identifying the base context used for replication.
基本CID：标识用于复制的基本上下文的CID。
Appendix B: Inter-Profile Context Replication (Informative)
附录B：配置文件间上下文复制（资料性）
Context replication as defined in this document does not explicitly support the concept of context replication between profiles. However, it might be of interest when developing new compression profiles.
本文档中定义的上下文复制不明确支持配置文件之间的上下文复制概念。然而，在开发新的压缩配置文件时，它可能会引起人们的兴趣。
Inter-profile context replication would require that the decompressor have access to data structures from the base context, which belongs to a profile different than the profile using replication. This information would have to be made available in a format consistent with the data structures and encoding method(s) in use for all header fields that are being replicated.
配置文件间上下文复制要求解压缩程序能够从基本上下文访问数据结构，基本上下文属于与使用复制的配置文件不同的配置文件。这些信息必须以与正在复制的所有标题字段使用的数据结构和编码方法一致的格式提供。
A ROHC profile describes how to compress a specific protocol stack, and includes one or more sets of packet formats. The packet formats will typically compress the protocol headers relative to a context of field values from previous headers in a flow. This context may also contain some control data. Thus, the packet formats specify a mapping between the uncompressed and compressed version of a protocol field.
ROHC配置文件描述了如何压缩特定协议栈，并包括一组或多组数据包格式。数据包格式通常会相对于来自流中先前报头的字段值的上下文压缩协议报头。此上下文还可能包含一些控制数据。因此，数据包格式指定协议字段的未压缩版本和压缩版本之间的映射。
This mapping is achieved through the use of one or more encoding methods, which are simply functions applied to compress or decompress a field. An encoding method is in turn defined using a name, a set of function parameters, and a formal expression (i.e., using the ROHC-FN [6]) or a textual description (i.e., a la RFC 3095 [2]) of its behaviour.
这种映射是通过使用一个或多个编码方法实现的，这些编码方法只是用于压缩或解压缩字段的函数。编码方法依次使用名称、一组函数参数和形式表达式（即使用ROHC-FN[6]）或其行为的文本描述（即la RFC 3095[2]）来定义。
To compress one or more fields of a specific protocol stack, different profiles may define their packet formats using different encoding methods, or using a variant of a similar technique. A typical example of the latter is list compression, such as used for IP extension headers. This implies that context entries for a field belonging to a specific protocol stack may differ in their content, representation, and structure from one profile to another.
为了压缩特定协议栈的一个或多个字段，不同的配置文件可以使用不同的编码方法或使用类似技术的变体来定义其数据包格式。后者的一个典型示例是列表压缩，例如用于IP扩展头的列表压缩。这意味着属于特定协议栈的字段的上下文条目在内容、表示和结构上可能因配置文件而异。
As a consequence of the above, a profile that supports context replication can only use a base context from another profile explicitly supporting the concept of a base context. That is, existing profiles not supporting this concept must be updated first to ensure that they can export the necessary context data entries that use a meaningful representation during replication.
因此，支持上下文复制的概要文件只能使用来自明确支持基本上下文概念的另一个概要文件的基本上下文。也就是说，必须首先更新不支持此概念的现有概要文件，以确保它们可以导出必要的上下文数据项，这些数据项在复制期间使用有意义的表示。
Specifically, inter-profile context replication would require that decompressor implementations (including existing ones) of other profiles be updated when adding support for a profile that uses context replication. Therefore, inter-profile context replication cannot be seen as an implementation-specific issue.
具体来说，配置文件间上下文复制需要在添加对使用上下文复制的配置文件的支持时更新其他配置文件的解压缩器实现（包括现有的）。因此，配置文件间上下文复制不能视为特定于实现的问题。
The compressor must know if the decompressor supports inter-profile context replication before initiating the procedure. The compressor must also know which contexts (belonging to which profile) may be used as a base context. Therefore, a compressor cannot initiate context replication using a base context belonging to a different profile, unless that profile explicitly provides the proper mapping for its context entries or that profile is defined formally using ROHC-FN [6] in a manner that makes both profiles compatible. The set of profiles negotiated for the channel (see also RFC 3095 [2]) can then be used to determine if a context for a specific profile can be used as a base context.
在启动该过程之前，压缩器必须知道解压器是否支持配置文件间上下文复制。压缩器还必须知道哪些上下文（属于哪个概要文件）可以用作基本上下文。因此，压缩器无法使用属于不同概要文件的基本上下文启动上下文复制，除非该概要文件明确为其上下文条目提供了正确的映射，或者该概要文件是使用ROHC-FN[6]以使两个概要文件兼容的方式正式定义的。然后可以使用为通道协商的配置文件集（另请参见RFC 3095[2]）来确定特定配置文件的上下文是否可以用作基本上下文。
Compatibility between profiles, when replicating a field for a particular protocol stack, can be expressed as follow: a field that is compressed by different profiles is compatible for inter-profile replication if it is defined in the set of packet formats using the same mapping function between its uncompressed and compressed version.
当为特定协议栈复制字段时，配置文件之间的兼容性可以表示为：如果由不同配置文件压缩的字段在数据包格式集中使用其未压缩版本和压缩版本之间的相同映射函数定义，则该字段与配置文件间复制兼容。
For example, the IP Destination Address field which, based on the packet formats and compression strategies defined in RFC 3095 [2], is implicitly compressed using an encoding method equivalent to the static() method defined in ROHC-FN [6].
例如，基于RFC 3095[2]中定义的数据包格式和压缩策略，使用与ROHC-FN[6]中定义的static（）方法等效的编码方法隐式压缩IP目的地地址字段。
In particular, for profiles that define their packet formats using a formal notation such as ROHC-FN [6], two different encoding methods may not have the same name. Thus, a field from a protocol stack is said to be compatible for replication between two different profiles if it has an equivalent definition within respective packet formats.
特别是，对于使用正式符号（如ROHC-FN[6]）定义其数据包格式的配置文件，两种不同的编码方法可能不具有相同的名称。因此，如果协议栈中的字段在各自的数据包格式中具有等效的定义，则称该字段与两个不同的配置文件之间的复制兼容。
Author's Address
作者地址
Ghyslain Pelletier Box 920 Ericsson AB SE-971 28 Lulea, Sweden
Ghyslain Pelletier信箱920爱立信AB SE-971 28，瑞典卢利亚
Phone: +46 8 404 29 43
Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Phone: +46 8 404 29 43
Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。