Network Working Group L-E. Jonsson
Request for Comments: 3759 Ericsson
Updates: 3095 April 2004
Category: Informational
Network Working Group L-E. Jonsson
Request for Comments: 3759 Ericsson
Updates: 3095 April 2004
Category: Informational
RObust Header Compression (ROHC): Terminology and Channel Mapping Examples
健壮的报头压缩（ROHC）：术语和通道映射示例
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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document aims to clarify terms and concepts presented in RFC 3095. RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues.
本文件旨在澄清RFC 3095中提出的术语和概念。RFC3095定义了一个提议的标准框架，其中包含用于健壮报头压缩（ROHC）的概要文件。该标准引入了各种可能难以理解的概念，尤其是与可能使用报头压缩的周围环境正确相关的概念。本文件旨在澄清ROHC的这些方面，讨论ROHC实例、ROHC通道、ROHC反馈和ROHC上下文等术语，以及这些术语与其他术语（如网络元件和IP接口）的关系，例如，在解决MIB问题时常用。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ROHC External Terminology. . . . . . . . . . . . . . . . . . . 6
3.1. Network Elements and IP Interfaces . . . . . . . . . . . 6
3.2. Channels . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. A Unidirectional Point-to-Point Link Example . . . . . . 8
3.4. A Bi-directional Point-to-Point Link Example . . . . . . 8
3.5. A Bi-directional Multipoint Link Example . . . . . . . . 9
3.6. A Multi-Channel Point-to-Point Link Example. . . . . . . 9
4. ROHC Instances . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. ROHC Compressors . . . . . . . . . . . . . . . . . . . . 11
4.2. ROHC Decompressors . . . . . . . . . . . . . . . . . . . 12
5. ROHC Channels. . . . . . . . . . . . . . . . . . . . . . . . . 13
6. ROHC Feedback Channels . . . . . . . . . . . . . . . . . . . . 14
6.1. Single-Channel Dedicated ROHC FB Channel Example . . . . 14
6.2. Piggybacked/Interspersed ROHC FB Channel Example . . . . 15
6.3. Dual-Channel Dedicated ROHC FB Channel Example . . . . . 16
7. ROHC Contexts. . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Implementation Implications. . . . . . . . . . . . . . . . . . 18
10. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12. Informative References . . . . . . . . . . . . . . . . . . . . 19
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ROHC External Terminology. . . . . . . . . . . . . . . . . . . 6
3.1. Network Elements and IP Interfaces . . . . . . . . . . . 6
3.2. Channels . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. A Unidirectional Point-to-Point Link Example . . . . . . 8
3.4. A Bi-directional Point-to-Point Link Example . . . . . . 8
3.5. A Bi-directional Multipoint Link Example . . . . . . . . 9
3.6. A Multi-Channel Point-to-Point Link Example. . . . . . . 9
4. ROHC Instances . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. ROHC Compressors . . . . . . . . . . . . . . . . . . . . 11
4.2. ROHC Decompressors . . . . . . . . . . . . . . . . . . . 12
5. ROHC Channels. . . . . . . . . . . . . . . . . . . . . . . . . 13
6. ROHC Feedback Channels . . . . . . . . . . . . . . . . . . . . 14
6.1. Single-Channel Dedicated ROHC FB Channel Example . . . . 14
6.2. Piggybacked/Interspersed ROHC FB Channel Example . . . . 15
6.3. Dual-Channel Dedicated ROHC FB Channel Example . . . . . 16
7. ROHC Contexts. . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Implementation Implications. . . . . . . . . . . . . . . . . . 18
10. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12. Informative References . . . . . . . . . . . . . . . . . . . . 19
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
In RFC 3095, the RObust Header Compression (ROHC) standard framework is defined, along with 4 compression profiles [RFC-3095]. Various concepts are introduced within the standard that are not all very extensively defined and described, which can easily be an obstacle when trying to understand the standard. This can especially be the case when one considers how the various parts of ROHC relate to the surrounding environments where header compression may be used.
在RFC 3095中，定义了鲁棒头压缩（ROHC）标准框架，以及4个压缩配置文件[RFC-3095]。标准中引入了各种概念，但这些概念的定义和描述并不十分广泛，这很容易成为理解标准的障碍。当考虑ROHC的各个部分如何与可能使用头压缩的周围环境相关时，情况尤其如此。
The purpose of this document is to clarify these aspects of ROHC through examples and additional terminology, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts. This especially means to clarify how these terms relate to other terms, such as network elements and IP interfaces, which are commonly used for example when addressing MIB issues. One explicit goal of this document is to support and simplify the ROHC MIB development work.
本文件的目的是通过示例和附加术语阐明ROHC的这些方面，讨论ROHC实例、ROHC渠道、ROHC反馈和ROHC上下文等术语。这尤其意味着澄清这些术语与其他术语的关系，如网元和IP接口，它们通常用于解决MIB问题。本文档的一个明确目标是支持和简化ROHC MIB开发工作。
The main part of this document, sections 3 to 8, focuses on clarifying the conceptual aspects, entity relationships, and terminology of ROHC [RFC-3095]. Section 9 explains some implementation implications that arise from these conceptual aspects.
本文件的主要部分，即第3节至第8节，侧重于澄清ROHC[RFC-3095]的概念方面、实体关系和术语。第9节解释了这些概念方面产生的一些实施影响。
ROHC instance
ROHC实例
A logical entity that performs header compression or decompression according to one or several ROHC profiles can be referred to as a ROHC instance. A ROHC instance is either a ROHC compressor instance or a ROHC decompressor instance. See section 4.
根据一个或多个ROHC配置文件执行头压缩或解压缩的逻辑实体可以称为ROHC实例。ROHC实例是ROHC压缩器实例或ROHC解压缩器实例。见第4节。
ROHC compressor instance
ROHC压缩机实例
A ROHC compressor instance is a logical entity that performs header compression according to one or several ROHC profiles. There is a one-to-one relation between a ROHC compressor instance and a ROHC channel, where the ROHC compressor is located at the input end of the ROHC channel. See section 4.1.
ROHC压缩器实例是根据一个或多个ROHC配置文件执行头压缩的逻辑实体。ROHC压缩器实例与ROHC通道之间存在一对一关系，其中ROHC压缩器位于ROHC通道的输入端。见第4.1节。
ROHC decompressor instance
ROHC解压器实例
A ROHC decompressor instance is a logical entity that performs header decompression according to one or several ROHC profiles. There is a one-to-one relation between a ROHC decompressor instance and a ROHC channel, where the ROHC decompressor is located at the output end of the ROHC channel. See section 4.2.
ROHC解压缩器实例是根据一个或多个ROHC配置文件执行头解压缩的逻辑实体。ROHC解压器实例与ROHC通道之间存在一对一关系，其中ROHC解压器位于ROHC通道的输出端。见第4.2节。
Corresponding decompressor
相应的减压器
When talking about a compressor's corresponding decompressor, this refers to the peer decompressor located at the other end of the ROHC channel to which the compressor sends compressed header packets, i.e., the decompressor that decompresses the headers compressed by the compressor.
当谈到压缩器的相应解压缩器时，这是指位于ROHC信道另一端的对等解压缩器，压缩器向其发送压缩的报头分组，即解压缩由压缩器压缩的报头的解压缩器。
Corresponding compressor
相应的压缩机
When talking about a decompressor's corresponding compressor, this refers to the peer compressor located at the other end of the ROHC channel from which the decompressor receives compressed header packets, i.e., the compressor that compresses the headers the decompressor decompresses.
当谈到解压器的对应压缩器时，这是指位于ROHC信道另一端的对等压缩器，解压器从中接收压缩的报头分组，即，压缩解压器解压缩的报头的压缩器。
ROHC peers
ROHC同行
A ROHC compressor and its corresponding ROHC decompressor are referred to as ROHC peers.
ROHC压缩机及其相应的ROHC减压器称为ROHC对等机。
Link
链接
A communication path between two network entities is, in this document, generally referred to as a link.
在本文中，两个网络实体之间的通信路径通常称为链路。
Bi-directional compression
双向压缩
If there are means to send feedback information from a decompressor to its corresponding compressor, the compression performance can be improved. This way of operating, utilizing the feedback possibility for improved compression performance, is referred to as bi-directional compression.
如果存在将反馈信息从减压器发送到其相应压缩机的方法，则可以提高压缩性能。这种利用反馈可能性提高压缩性能的操作方式称为双向压缩。
Unidirectional compression
单向压缩
If there are no means to send feedback information from a decompressor to its corresponding compressor, the compression performance might not be as good as if feedback could be utilized. This way of operating, without making use of feedback for improved compression performance, is referred to as unidirectional compression.
如果无法将反馈信息从解压器发送到相应的压缩机，则压缩性能可能不如可以利用反馈那样好。这种不使用反馈来提高压缩性能的操作方式称为单向压缩。
ROHC channel
ROHC频道
When a ROHC compressor has transformed original packets into ROHC packets with compressed headers, these ROHC packets are sent to the corresponding decompressor through a logical point-to-point connection dedicated to that traffic. Such a logical channel, which only has to carry data in this single direction from compressor to decompressor, is referred to as a ROHC channel. See section 5.
当ROHC压缩器将原始数据包转换为带有压缩头的ROHC数据包时，这些ROHC数据包通过专用于该流量的逻辑点对点连接发送到相应的解压缩器。这样一个逻辑通道被称为ROHC通道，它只需在从压缩机到解压器的单一方向上传输数据。见第5节。
ROHC feedback channel
ROHC反馈通道
To allow bi-directional compression operation, a logical point-to-point connection must be provided for feedback data from the decompressor to its corresponding compressor. Such a logical channel, which only has to carry data in the single direction from decompressor to compressor, is referred to as a ROHC feedback channel. See section 6.
为了允许双向压缩操作，必须提供逻辑点对点连接，以便将数据从解压缩器反馈到相应的压缩机。这样一个逻辑通道，只需在从解压器到压缩器的单一方向上传输数据，称为ROHC反馈通道。见第6节。
Co-located compressor/decompressor
同一位置的压缩机/减压器
A minimal ROHC instance is only a compressor or a decompressor, communicating with a corresponding decompressor or compressor peer at the other end of a ROHC channel, thus handling packet streams sent in one direction over the link. However, in many cases, the link will carry packet streams in both directions, and it would then be desirable to also perform header compression in both directions. That would require both a ROHC compressor and a ROHC decompressor at each end of the link, each referred to as a co-located compressor/decompressor pair.
最小ROHC实例只是压缩器或解压缩器，与ROHC信道另一端的相应解压缩器或压缩器对等方通信，从而处理通过链路向一个方向发送的分组流。然而，在许多情况下，链路将在两个方向上携带分组流，并且随后还希望在两个方向上执行报头压缩。这将需要在链路的每一端都安装一个ROHC压缩机和一个ROHC减压器，每一个都被称为同一位置的压缩机/减压器对。
Associated compressor/decompressor
相关压缩机/减压器
If there is a co-located ROHC compressor/decompressor pair at each end of a link, feedback messages can be transmitted from a ROHC decompressor to its corresponding compressor by creating a virtual ROHC feedback channel among the compressed header packets sent from the co-located ROHC compressor to the decompressor co-located with the compressor at the other end. When a co-located ROHC compressor/decompressor pair is connected for this purpose, they are said to be associated with each other.
如果在链路的每一端都有一对位于同一位置的ROHC压缩机/减压器，通过在从位于同一位置的ROHC压缩机发送到另一端与压缩机位于同一位置的解压缩器的压缩报头包之间创建虚拟ROHC反馈信道，可以将反馈消息从ROHC解压缩器发送到其相应的压缩机。当出于此目的连接位于同一位置的ROHC压缩机/减压器对时，它们被称为相互关联。
Interspersed feedback
分散反馈
Feedback from a ROHC decompressor to a ROHC compressor can either be sent on a separate ROHC feedback channel dedicated to feedback packets, or sent among compressed header packets going in the opposite direction from a co-located (associated) compressor to a similarly co-located decompressor at the other end of the link. If feedback packets are transmitted in the latter way and sent as stand-alone packets, this is referred to as interspersed feedback. See section 6.2 for an example.
从ROHC解压缩器到ROHC压缩器的反馈可以在专用于反馈分组的单独ROHC反馈信道上发送，或者在从同一位置（相关联的）压缩器到链路另一端的类似同一位置的解压缩器的相反方向的压缩报头分组之间发送。如果反馈数据包以后一种方式传输并作为独立数据包发送，则称为分散反馈。有关示例，请参见第6.2节。
Piggybacked feedback
背负反馈
Feedback from a ROHC decompressor to a ROHC compressor can either be sent on a separate ROHC feedback channel dedicated to feedback packets, or sent among compressed header packets going in the opposite direction from a co-located (associated) compressor to a similarly co-located decompressor at the other end of the link. If feedback packets are transmitted in the latter way and sent encapsulated within compressed header packets going in the other direction, this is referred to as piggybacked feedback. See section 6.2 for an example.
从ROHC解压缩器到ROHC压缩器的反馈可以在专用于反馈分组的单独ROHC反馈信道上发送，或者在从同一位置（相关联的）压缩器到链路另一端的类似同一位置的解压缩器的相反方向的压缩报头分组之间发送。如果以后一种方式发送反馈数据包，并将其封装在压缩头数据包中发送到另一个方向，则这称为背载反馈。有关示例，请参见第6.2节。
Dedicated feedback channel
专用反馈通道
A dedicated feedback channel is a logical layer two channel from a ROHC decompressor to a ROHC compressor, used only to transmit feedback packets. See sections 6.1 and 6.3 for examples.
专用反馈通道是从ROHC解压器到ROHC压缩器的逻辑层二通道，仅用于传输反馈数据包。示例见第6.1节和第6.3节。
When considering aspects of ROHC that relate to the surrounding networking environment where header compression may be applied, unnecessary confusion is easily created because a common, well understood, and well defined, terminology is missing. One major goal with this document is to define the preferred terminology to use when discussing header compression network integration issues.
在考虑ROHC与可能应用头压缩的周围网络环境相关的方面时，很容易产生不必要的混淆，因为缺少一个通用、易于理解和定义良好的术语。本文档的一个主要目标是定义讨论报头压缩网络集成问题时使用的首选术语。
Header compression is applied over certain links, between two communicating entities in a network. Such entities may be referred to as "nodes", "network devices", or "network elements", all terms usually having the same meaning. However, practice within the area of network management favors using the term "network element", which is therefore consistently used throughout the rest of this document.
报头压缩应用于网络中两个通信实体之间的特定链路。此类实体可被称为“节点”、“网络设备”或“网络元件”，所有术语通常具有相同的含义。但是，网络管理领域的实践倾向于使用术语“网元”，因此在本文件其余部分中始终使用该术语。
A network element communicates through one or several network interfaces, which are often subject to network management, as defined by MIB specifications. In all IP internetworking, each such interface has its own IP identity, providing a common network interface abstraction, independent of the link technology hidden below the interface. Throughout the rest of this document, such interfaces will be referred to as "IP interfaces".
网元通过一个或多个网络接口进行通信，根据MIB规范的定义，这些接口通常受网络管理的约束。在所有IP互联网络中，每个这样的接口都有自己的IP标识，提供了一个通用的网络接口抽象，独立于隐藏在接口下面的链路技术。在本文件其余部分中，此类接口将被称为“IP接口”。
Thus, to visualize the above terms, the top level hierarchy of a network element is as follows, with one or several IP interfaces:
因此，为了可视化上述术语，网元的顶层层次结构如下所示，具有一个或多个IP接口：
+-----------------------------------------------------+
| Network Element |
+---------------+--+---------------+------------------+
| IP | | IP |
| Interface | | Interface |
+---------------+ +---------------+ ...
+-----------------------------------------------------+
| Network Element |
+---------------+--+---------------+------------------+
| IP | | IP |
| Interface | | Interface |
+---------------+ +---------------+ ...
The next section builds on this top level hierarchy by looking at what is below an IP interface.
下一节通过查看IP接口下面的内容来构建这个顶级层次结构。
As mentioned in the previous section, an IP interface can be implemented on top of almost any link technology, although different link technologies have different characteristics, and provide communication by different means. However, all link technologies provide the common capability to send and/or receive data to/from the IP interface. A generic way of visualizing the common ability to communicate is to envision it as one or several logical communication channels provided by the link, where each channel can be either bi-directional or unidirectional. Such logical point-to-point connections will, throughout the rest of this document, be referred to as "channels", either bi-directional or unidirectional. Note that this definition of "channels" is less restrictive than the definition of "ROHC channels", as given in section 5.
如前一节所述，IP接口几乎可以在任何链路技术之上实现，尽管不同的链路技术具有不同的特性，并通过不同的方式提供通信。但是，所有链路技术都提供了向IP接口发送和/或从IP接口接收数据的通用功能。将公共通信能力可视化的一般方法是将其设想为链路提供的一个或多个逻辑通信信道，其中每个信道可以是双向的，也可以是单向的。在本文件的其余部分，此类逻辑点对点连接将被称为“通道”，可以是双向的，也可以是单向的。请注意，“通道”的定义比第5节中给出的“ROHC通道”的定义限制性更小。
Extending the above network element hierarchy with the concept of channels would then lead to the following:
使用信道概念扩展上述网元层次结构将导致以下结果：
+-----------------------------------------------------+
| Network Element |
+---------------+--+---------------+------------------+
| IP | | IP |
| Interface | | Interface |
++ +-+ +-+ +----+ ++ +-+ +-+ +----+ ...
|C| |C| |C| |C| |C| |C|
|h| |h| |h| |h| |h| |h|
|a| |a| |a| |a| |a| |a|
|n| |n| |n| ... |n| |n| |n| ...
|n| |n| |n| |n| |n| |n|
|e| |e| |e| |e| |e| |e|
|l| |l| |l| |l| |l| |l|
: : : : : : : : : : : :
+-----------------------------------------------------+
| Network Element |
+---------------+--+---------------+------------------+
| IP | | IP |
| Interface | | Interface |
++ +-+ +-+ +----+ ++ +-+ +-+ +----+ ...
|C| |C| |C| |C| |C| |C|
|h| |h| |h| |h| |h| |h|
|a| |a| |a| |a| |a| |a|
|n| |n| |n| ... |n| |n| |n| ...
|n| |n| |n| |n| |n| |n|
|e| |e| |e| |e| |e| |e|
|l| |l| |l| |l| |l| |l|
: : : : : : : : : : : :
Whether there is more than one channel, and whether the channel(s) is/are bi-directional or unidirectional (or a mix of both) is link technology dependent, as is the way in which channels are logically created.
是否存在多个信道，以及信道是双向的还是单向的（或两者的混合）取决于链路技术，信道的逻辑创建方式也是如此。
The following subsections, 3.3-3.6, give a number of different link examples, and relate these to the general descriptions above. Further, each section discusses how header compression might be applied in that particular case. The core questions for header compression are:
以下第3.3-3.6小节给出了许多不同的链接示例，并将其与上述一般说明联系起来。此外，每个部分都讨论了在特定情况下如何应用头压缩。标题压缩的核心问题是：
- Are channels bi- or unidirectional? - Is the link point-to-point? If not, a lower layer addressing scheme is needed to create logical point-to-point channels.
- 通道是双向的还是单向的链接是点对点的吗？如果不是，则需要较低层的寻址方案来创建逻辑点到点通道。
Note that these subsections talk about header compression in general, while later sections will address the case of ROHC in more detail. Further, one should remember that in the later sections, the general channel definition is slightly enhanced for header compression by the definition of the ROHC channel (section 5) and the ROHC feedback channel (section 6), while here the basic channel concept is used, as defined above.
请注意，这些小节通常讨论头压缩，而后面的小节将更详细地讨论ROHC的情况。此外，应记住，在后面的章节中，ROHC信道（第5节）和ROHC反馈信道（第6节）的定义略微增强了一般信道定义，以进行报头压缩，而这里使用了基本信道概念，如上所述。
The simplest possible link example one can derive from the general overview above is the case with one single unidirectional channel between two communicating network elements.
从上述概述中可以得出的最简单的链路示例是两个通信网络元件之间有一个单向信道的情况。
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+------+ +------+ +------+ +------+
| | | |
| +--------------------------------+ |
| -> Unidirectional channel -> |
+----------------------------------------+
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+------+ +------+ +------+ +------+
| | | |
| +--------------------------------+ |
| -> Unidirectional channel -> |
+----------------------------------------+
A typical example of a point-to-point link with one unidirectional channel like this is a satellite link. Since there is no return path present, only unidirectional header compression can be applied here.
卫星链路是具有一个单向信道的点到点链路的典型示例。由于不存在返回路径，因此此处只能应用单向报头压缩。
Taking the above example one step further, the natural extension would be an example with one single bi-directional channel between two communicating network elements. In this example, there are still only two endpoints and one single channel, but the channel is simply enhanced to allow bi-directional communication.
将上述示例进一步考虑，自然扩展将是在两个通信网元之间具有单个双向信道的示例。在这个例子中，仍然只有两个端点和一个通道，但是通道只是被增强以允许双向通信。
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+------+ +------+ +------+ +------+
| | | |
| +--------------------------------+ |
| <-> Bi-directional channel <-> |
+----------------------------------------+
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+------+ +------+ +------+ +------+
| | | |
| +--------------------------------+ |
| <-> Bi-directional channel <-> |
+----------------------------------------+
A typical example of a point-to-point link with such a bi-directional channel is a PPP modem connection over a regular telephone line. Header compression can easily be applied here as well, as is usually done over e.g., PPP, and the compression scheme can make use of the return path to improve compression performance.
具有这种双向信道的点对点链路的典型示例是通过常规电话线的PPP调制解调器连接。这里也可以很容易地应用报头压缩，这通常是通过例如PPP进行的，并且压缩方案可以利用返回路径来提高压缩性能。
Leaving the simple point-to-point link examples, this section addresses the case of a bi-directional link connecting more than two communicating network elements. To simplify the example, the case with three endpoints is considered.
离开简单的点到点链路示例，本节将讨论连接两个以上通信网络元件的双向链路的情况。为了简化示例，考虑了具有三个端点的情况。
+-----------------+ +-----------------+ +-----------------+
| Network Element | | Network Element | | Network Element |
+-----------------+ +-----------------+ +-----------------+
| IP | | IP | | IP |
| Interface | | Interface | | Interface |
+------+ +------+ +------+ +------+ +------+ +------+
| | | | | |
| | | | | |
| +-----------------+ +-----------------+ |
| <-> Bi-directional "shared channel" <-> |
+-----------------------------------------------+
+-----------------+ +-----------------+ +-----------------+
| Network Element | | Network Element | | Network Element |
+-----------------+ +-----------------+ +-----------------+
| IP | | IP | | IP |
| Interface | | Interface | | Interface |
+------+ +------+ +------+ +------+ +------+ +------+
| | | | | |
| | | | | |
| +-----------------+ +-----------------+ |
| <-> Bi-directional "shared channel" <-> |
+-----------------------------------------------+
A typical example of a multipoint link with such a bi-directional "shared channel" is an Ethernet. Since the channel is shared, applying header compression would require a lower layer addressing scheme to provide logical point-to-point channels, according to the definition of "channels".
具有这种双向“共享通道”的多点链路的典型示例是以太网。由于信道是共享的，根据“信道”的定义，应用报头压缩将需要较低层的寻址方案来提供逻辑点到点信道。
As an aside, it should be noted that a case of unidirectional multipoint links is basically the same as a number of unidirectional point-to-point links. In such a case, each receiver only sees one single sender, and the sender's behavior is independent of the number of receivers and is unaffected by their behavior.
另一方面，应当注意的是，单向多点链路的情况基本上与许多单向点到点链路相同。在这种情况下，每个接收者只看到一个发送者，发送者的行为与接收者的数量无关，并且不受其行为的影响。
This final example addresses a scenario which is expected to be typical in many environments where ROHC will be applied. The key point of the example is the multi-channel property, which is common in, for example, cellular environments. Data through the same IP interface might here be transmitted on different channels, depending on its characteristics. In the following example, there are three channels present, one bi-directional, and one unidirectional in each direction, but the channel configuration could of course be arbitrary.
最后一个示例介绍了一个场景，该场景预计在许多应用ROHC的环境中都是典型的。该示例的关键点是多信道特性，这在例如蜂窝环境中很常见。通过同一IP接口的数据可能在不同的信道上传输，这取决于其特性。在下面的示例中，存在三个通道，一个双向，每个方向一个单向，但是通道配置当然可以是任意的。
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+-+ +---+ +---+ +-+ +-+ +---+ +---+ +-+
| | | | | | | | | | | |
| | | | | +--------------------------+ | | | | |
| | | | | <- Unidirectional channel <- | | | | |
| | | | +------------------------------+ | | | |
| | | | | | | |
| | | | | | | |
| | | +--------------------------------------+ | | |
| | | <-> Bi-directional channel <-> | | |
| | +------------------------------------------+ | |
| | | |
| | | |
| +--------------------------------------------------+ |
| -> Unidirectional channel -> |
+------------------------------------------------------+
+-----------------+ +-----------------+
| Network Element | | Network Element |
+-----------------+ +-----------------+
| IP | | IP |
| Interface | | Interface |
+-+ +---+ +---+ +-+ +-+ +---+ +---+ +-+
| | | | | | | | | | | |
| | | | | +--------------------------+ | | | | |
| | | | | <- Unidirectional channel <- | | | | |
| | | | +------------------------------+ | | | |
| | | | | | | |
| | | | | | | |
| | | +--------------------------------------+ | | |
| | | <-> Bi-directional channel <-> | | |
| | +------------------------------------------+ | |
| | | |
| | | |
| +--------------------------------------------------+ |
| -> Unidirectional channel -> |
+------------------------------------------------------+
As mentioned above, a typical example of a multi-channel link is a cellular wireless link. In this example, header compression would be applicable on a per-channel basis, for each channel operating either in a bi-directional or unidirectional manner, depending on the channel properties.
如上所述，多信道链路的典型示例是蜂窝无线链路。在此示例中，报头压缩将基于每个信道适用于以双向或单向方式操作的每个信道，具体取决于信道属性。
For various purposes, such as network management on an IP interface implementing ROHC, it is necessary to identify the various ROHC entities that might be present on an interface. Such a minimal ROHC entity will, from now on, be referred to as a "ROHC instance". A ROHC instance can be one of two different types, either a "ROHC compressor" or a "ROHC decompressor" instance, and an IP interface can have N ROHC compressors and M ROHC decompressors, where N and M are arbitrary numbers. It should be noted that although a compressor is often co-located with a decompressor, a ROHC instance can never include both a compressor and a decompressor; where both are present, they will be referred to as two ROHC instances.
出于各种目的，例如实现ROHC的IP接口上的网络管理，有必要识别接口上可能存在的各种ROHC实体。从现在起，这样一个最小的ROHC实体将被称为“ROHC实例”。ROHC实例可以是两种不同类型的实例之一，“ROHC压缩器”或“ROHC解压缩器”实例，IP接口可以有N个ROHC压缩器和M个ROHC解压缩器，其中N和M是任意数字。应该注意的是，尽管压缩机通常与减压器位于同一位置，但ROHC实例永远不能同时包括压缩机和减压器；如果两者都存在，它们将被称为两个ROHC实例。
The following two subsections describe the two kinds of ROHC instances and their external interfaces, while sections 5 and 6 address how communication over these interfaces is realized through "ROHC channels" and "ROHC feedback channels". Section 7 builds on top of the instance, channel and feedback channel concepts, and clarifies how ROHC contexts map to this.
以下两小节描述了两种ROHC实例及其外部接口，第5节和第6节介绍了如何通过“ROHC通道”和“ROHC反馈通道”实现这些接口上的通信。第7节建立在实例、通道和反馈通道概念之上，并阐明ROHC上下文如何映射到这一点。
It should be noted that all figures in sections 4-6 have been rotated 90 degrees to simplify drawing, i.e., they do not show a "stack view".
应注意的是，第4-6节中的所有图形均已旋转90度以简化绘图，即它们未显示“堆栈视图”。
A ROHC compressor instance supports header compression according to one or several ROHC profiles. Apart from potential configuration or control interfaces, a compressor instance receives and sends data through 3 inputs and 1 output, as illustrated by the figure below:
ROHC压缩器实例支持根据一个或多个ROHC配置文件进行头压缩。除了潜在的配置或控制接口外，压缩机实例通过3个输入和1个输出接收和发送数据，如下图所示：
+--------------+
-> UI -> | | -> CO ->
| ROHC |
| Compressor |
-> PI -> | | <- FI <-
+--------------+
+--------------+
-> UI -> | | -> CO ->
| ROHC |
| Compressor |
-> PI -> | | <- FI <-
+--------------+
Uncompressed Input (UI): Uncompressed packets are delivered from higher layers to the compressor through the UI.
未压缩输入（UI）：未压缩的数据包通过UI从更高层传送到压缩器。
Compressed Output (CO): Compressed packets are sent from the compressor through the CO, which is always connected to the input end of a ROHC channel (see section 5).
压缩输出（CO）：压缩数据包通过CO从压缩机发送，CO始终连接到ROHC通道的输入端（见第5节）。
Feedback Input (FI): Feedback from the corresponding [optional] decompressor is received by the compressor through the FI, which (if present) is connected to the output end of a ROHC feedback channel of some kind (see section 6). When there are no means to transmit feedback from decompressor to compressor, FI is not used, and bi-directional compression will not be possible.
反馈输入（FI）：压缩机通过FI接收来自相应[可选]减压器的反馈，FI（如果存在）连接到某种ROHC反馈通道的输出端（见第6节）。当无法将反馈从减压器传输到压缩机时，不使用FI，并且不可能进行双向压缩。
Piggyback Input (PI): If the compressor is associated with a [optional] co-located decompressor, for which the compressor delivers feedback to the other end of the link, feedback data for piggybacking is delivered to the compressor through the PI. If this input is used, it is connected to the FO of the co-located decompressor (see section 4.2).
背驮输入（PI）：如果压缩机与[可选]同地减压器关联，压缩机将反馈发送至链路的另一端，则背驮的反馈数据通过PI发送至压缩机。如果使用该输入，则将其连接至同一位置的减压器的FO（见第4.2节）。
A ROHC decompressor instance supports header decompression according to one or several ROHC profiles. Apart from potential configuration or control interfaces, a decompressor instance receives and sends data through 1 input and 3 outputs, as illustrated by the figure below:
ROHC解压缩器实例支持根据一个或多个ROHC配置文件进行头解压缩。除潜在的配置或控制接口外，解压器实例通过1个输入和3个输出接收和发送数据，如下图所示：
+--------------+
-> CI -> | | -> DO ->
| ROHC |
| Decompressor |
<- FO <- | | -> PO ->
+--------------+
+--------------+
-> CI -> | | -> DO ->
| ROHC |
| Decompressor |
<- FO <- | | -> PO ->
+--------------+
Compressed Input (CI): Compressed packets are received by the decompressor through the CI, which is always connected to the output end of a ROHC channel (see section 5).
压缩输入（CI）：解压器通过CI接收压缩数据包，CI始终连接到ROHC通道的输出端（见第5节）。
Decompressed Output (DO): Decompressed packets are delivered from the decompressor to higher layers through the DO.
解压输出（DO）：解压后的数据包通过DO从解压器传送到更高层。
Feedback Output (FO): Feedback to the corresponding compressor [optional] is sent from the compressor through the FO, which (if present) is connected to the input end of a ROHC feedback channel of some kind (see section 6). When there are no means to transmit feedback from decompressor to compressor, FO is not used, and bi-directional compression will not be possible.
反馈输出（FO）：通过FO从压缩机发送到相应压缩机的反馈[可选]，FO（如果存在）连接到某种ROHC反馈通道的输入端（见第6节）。当无法将来自减压器的反馈传输到压缩机时，不使用FO，并且不可能进行双向压缩。
Piggyback Output (PO): If the decompressor is associated with [optional] a co-located compressor to which the decompressor delivers feedback it receives piggybacked from the other end of the link, the received feedback data is delivered from the decompressor through the PO. If this output is used, it is connected to the FI of the co-located compressor (see section 4.1).
背驮输出（PO）：如果减压器与[可选]一个位于同一位置的压缩机相关联，减压器将从链路另一端背驮接收到的反馈发送到该压缩机，则接收到的反馈数据将通过PO从减压器发送。如果使用该输出，则将其连接至同一位置压缩机的FI（见第4.1节）。
In section 3, a general concept of channels was introduced. According to that definition, a channel is basically a logical point-to-point connection between the IP interfaces of two communicating network elements. By that definition, a channel represents the kind of logical connection needed to make header compression generally applicable, and then the channel properties control whether compression can operate in a unidirectional or bi-directional manner.
第3节介绍了通道的一般概念。根据该定义，信道基本上是两个通信网元的IP接口之间的逻辑点对点连接。根据该定义，通道表示使报头压缩普遍适用所需的逻辑连接类型，然后通道属性控制压缩是以单向方式还是双向方式运行。
The channel concept thus facilitates general header compression discussions, but since it groups unidirectional and bi-directional connections together, it does not provide the means for describing details of how ROHC logically works. Therefore, for the case of ROHC, the channel concept is enhanced and a more restricted concept of "ROHC channels" is defined.
因此，信道概念有助于一般的报头压缩讨论，但由于它将单向和双向连接分组在一起，因此它不提供描述ROHC逻辑工作方式细节的方法。因此，就ROHC而言，渠道概念得到了强化，并定义了一个更受限制的“ROHC渠道”概念。
A ROHC channel has the same properties as a channel, with the difference that a ROHC channel is always unidirectional. A ROHC channel therefore has one single input endpoint, connected to the CO of one single ROHC compressor instance, and one single output endpoint, connected to the CI of one single ROHC decompressor instance. A ROHC channel must thus in this way be logically dedicated to one ROHC compressor and one ROHC decompressor, hereafter referred to as ROHC peers, creating a one-to-one mapping between a ROHC channel and two ROHC compressor/decompressor peers.
ROHC通道与通道具有相同的属性，不同之处在于ROHC通道始终是单向的。因此，ROHC通道具有一个连接到单个ROHC压缩器实例的CO的单个输入端点，以及一个连接到单个ROHC解压缩器实例的CI的单个输出端点。因此，ROHC通道必须以这种方式在逻辑上专用于一个ROHC压缩器和一个ROHC解压缩器，以下称为ROHC对等点，从而在ROHC通道和两个ROHC压缩器/解压缩器对等点之间创建一对一映射。
+--------------+ --->-->-->-->--- +--------------+
| | -> CO -> ROHC Channel -> CI -> | |
| ROHC | --->-->-->-->--- | ROHC |
| Compressor | | Decompressor |
| | | |
+--------------+ +--------------+
+--------------+ --->-->-->-->--- +--------------+
| | -> CO -> ROHC Channel -> CI -> | |
| ROHC | --->-->-->-->--- | ROHC |
| Compressor | | Decompressor |
| | | |
+--------------+ +--------------+
In many cases the lower layer channel is by nature bi-directional, but for ROHC communication over that channel, a ROHC channel would only represent one communication direction of that channel. For bi-directional channels, a common case would be to logically allocate one ROHC channel in each direction, allowing ROHC compression to be performed in both directions. The reason for defining ROHC channels as unidirectional is basically to separate and generalize the concept of feedback, as described and exemplified in section 6.
在许多情况下，较低层信道本质上是双向的，但对于该信道上的ROHC通信，ROHC信道将仅代表该信道的一个通信方向。对于双向信道，常见情况是在每个方向上逻辑分配一个ROHC信道，允许在两个方向上执行ROHC压缩。将ROHC信道定义为单向信道的原因基本上是为了分离和概括反馈的概念，如第6节所述和举例说明。
Since ROHC can be implemented over various kinds of links, unidirectional or bi-directional one-channel links, as well as multi-channel links, the logical transmission of feedback from decompressor to compressor has been separated out from the transport of actual ROHC packets through the definition of ROHC channels as always being unidirectional from compressor to decompressor. This means that an additional channel concept must be defined for feedback, which is what will hereafter be referred to as "ROHC feedback channels".
由于ROHC可以在各种链路、单向或双向单通道链路以及多通道链路上实现，通过定义ROHC通道，从压缩机到压缩机的反馈逻辑传输与实际ROHC数据包的传输分离，因为从压缩机到解压缩器的反馈始终是单向的。这意味着必须为反馈定义一个额外的通道概念，即下文所称的“ROHC反馈通道”。
In the same way as a ROHC channel is a logically dedicated unidirectional channel from a ROHC compressor to its corresponding ROHC peer decompressor, a ROHC feedback channel is a logically dedicated unidirectional channel from a ROHC decompressor to its corresponding ROHC peer compressor. A ROHC feedback channel thus has one single input endpoint, connected to the FO of one single ROHC decompressor instance, and one single output endpoint, connected to the FI of one single ROHC compressor instance.
与ROHC信道是从ROHC压缩器到其对应的ROHC对等解压缩器的逻辑专用单向信道相同，ROHC反馈信道是从ROHC解压缩器到其对应的ROHC对等解压缩器的逻辑专用单向信道。因此，ROHC反馈通道具有一个连接到单个ROHC解压器实例的FO的单个输入端点，以及一个连接到单个ROHC压缩器实例的FI的单个输出端点。
+--------------+ +--------------+
| | | |
| ROHC | | ROHC |
| Compressor | --<--<--<--<--<-- | Decompressor |
| | <- FI <- ROHC FB Channel <- FO <- | |
+--------------+ --<--<--<--<--<-- +--------------+
+--------------+ +--------------+
| | | |
| ROHC | | ROHC |
| Compressor | --<--<--<--<--<-- | Decompressor |
| | <- FI <- ROHC FB Channel <- FO <- | |
+--------------+ --<--<--<--<--<-- +--------------+
The reason for making this simplification and logically separating ROHC channels from ROHC feedback channels is generality for handling of feedback. ROHC has been designed with the assumption of logical separation, which creates flexibility in realizing feedback transport, as discussed in [RFC-3095, section 5.2.1]. There are no restrictions on how to implement a ROHC feedback channel, other than that it must be made available and be logically dedicated to the ROHC peers if bi-directional compression operation is to be allowed.
进行这种简化并从逻辑上将ROHC通道与ROHC反馈通道分离的原因是反馈处理的一般性。ROHC的设计假设为逻辑分离，这为实现反馈传输创造了灵活性，如[RFC-3095，第5.2.1节]所述。对于如何实现ROHC反馈通道没有任何限制，除了如果允许双向压缩操作，则必须使其可用并在逻辑上专用于ROHC对等方。
The following subsections provide some, not at all exhaustive, examples of how a ROHC feedback channel might possibly be realized.
以下小节提供了一些（并非完全详尽）可能实现ROHC反馈通道的示例。
This section illustrates a one-way compression example where one bi-directional channel has been configured to represent a ROHC channel in one direction and a dedicated ROHC feedback channel in the other direction.
本节说明了单向压缩示例，其中一个双向信道已配置为在一个方向上表示ROHC信道，在另一个方向上表示专用ROHC反馈信道。
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
--> |UI CO| --> : ROHC Channel : --> |CI DO| -->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| | : --<--<--<--<-- : | |
o |PI FI| <-- : FB Channel : <-- |FO PO| o
+--------------+ : --<--<--<--<-- : +--------------+
:................:
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
--> |UI CO| --> : ROHC Channel : --> |CI DO| -->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| | : --<--<--<--<-- : | |
o |PI FI| <-- : FB Channel : <-- |FO PO| o
+--------------+ : --<--<--<--<-- : +--------------+
:................:
In this example, feedback is sent on its own dedicated channel, as discussed in e.g., feedback realization example 1-3 of ROHC [RFC-3095, page 44]. This means that the piggybacking/interspersing mechanism of ROHC is not used, and the PI/PO connections are thus left open (marked with a "o"). To facilitate communication with ROHC compression in a two-way manner using this approach, an identical configuration must be provided for the other direction, i.e., making use of four logical unidirectional channels.
在本例中，反馈在其自己的专用信道上发送，如ROHC[RFC-3095，第44页]的反馈实现示例1-3所述。这意味着不使用ROHC的背驮/穿插机制，因此PI/PO连接保持打开状态（标有“o”）。为了便于使用该方法以双向方式与ROHC压缩通信，必须为另一个方向提供相同的配置，即使用四个逻辑单向通道。
This section illustrates how a bi-directional channel has been configured to represent one ROHC channel in each direction, while still allowing feedback to be transmitted through ROHC piggybacking and interspersing.
本节说明了如何将双向信道配置为在每个方向上表示一个ROHC信道，同时仍然允许通过ROHC搭载和穿插传输反馈。
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
--> |UI CO| --> : ROHC Channel A : --> |CI DO| -->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| A | : : | A |
+-> |PI FI| <-+ : : +-- |PO FO| --+
| +--------------+ | : : | +--------------+ |
| | : : | |
| | : : | |
| +--------------+ | : : | +--------------+ |
+-- |FO PO| --+ : : +-> |FI PI| <-+
| ROHC | : : | ROHC |
| Decompressor | : : | Compressor |
| B | : --<--<--<--<-- : | B |
<-- |DO CI| <-- : ROHC Channel B : <-- |CO UI| <--
+--------------+ : --<--<--<--<-- : +--------------+
:................:
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
--> |UI CO| --> : ROHC Channel A : --> |CI DO| -->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| A | : : | A |
+-> |PI FI| <-+ : : +-- |PO FO| --+
| +--------------+ | : : | +--------------+ |
| | : : | |
| | : : | |
| +--------------+ | : : | +--------------+ |
+-- |FO PO| --+ : : +-> |FI PI| <-+
| ROHC | : : | ROHC |
| Decompressor | : : | Compressor |
| B | : --<--<--<--<-- : | B |
<-- |DO CI| <-- : ROHC Channel B : <-- |CO UI| <--
+--------------+ : --<--<--<--<-- : +--------------+
:................:
In this example, feedback is transmitted piggybacked or interspersed among compressed header packets in the ROHC channels, as discussed in e.g., feedback realization example 4-6 of ROHC [RFC-3095, page 44]. Feedback from decompressor A to compressor A is here sent through FO(A)->PI(B), piggybacked on a compressed packet over ROHC channel B, and delivered to compressor A through PO(B)->FI(A). A logical ROHC feedback channel is thus provided from the PI input at compressor B to the PO output at decompressor B. It should be noted that in this picture, PO and FO at the decompressors have been swapped to simplify drawing.
在该示例中，反馈是在ROHC信道中的压缩报头分组之间以背驮或散布的方式传输的，如ROHC的反馈实现示例4-6[RFC-3095，第44页]中所述。这里，从减压器A到压缩机A的反馈通过FO（A）->PI（B）发送，通过ROHC通道B搭载在压缩包上，并通过PO（B）->FI（A）发送到压缩机A。因此，从压缩机B处的PI输入到解压器B处的PO输出提供了逻辑ROHC反馈通道。应注意，在本图中，解压器处的PO和FO已交换，以简化绘图。
This section illustrates how two bi-directional channels have been configured to represent two ROHC channels and two dedicated ROHC feedback channels, respectively.
本节说明了如何将两个双向通道配置为分别表示两个ROHC通道和两个专用ROHC反馈通道。
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
->|UI CO| --> : ROHC Channel A : --> |CI DO|->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| A | : : | A |
| | : : | |
+-> |FI PI| o : : o |PO FO| --+
| +--------------+ : --<--<--<--<-- : +--------------+ |
| +- : ROHC Channel B :<-+ |
| | : --<--<--<--<-- : | |
| +--------------+ | :................: | +--------------+ |
| <-|DO CI|<-+ +- |CO UI|<- |
| | ROHC | | ROHC | |
| | Decompressor | Bi-directional channel | Compressor | |
| | B | .................. | B | |
| | | : -->-->-->-->-- : | | |
| o|PO FO| --> : FB Channel B : --> |FI PI|o |
| +--------------+ : -->-->-->-->-- : +--------------+ |
| : : |
| : --<--<--<--<-- : |
+----------------------- : FB Channel A : <----------------------+
: --<--<--<--<-- :
:................:
Bi-directional channel
..................
+--------------+ : -->-->-->-->-- : +--------------+
->|UI CO| --> : ROHC Channel A : --> |CI DO|->
| ROHC | : -->-->-->-->-- : | ROHC |
| Compressor | : : | Decompressor |
| A | : : | A |
| | : : | |
+-> |FI PI| o : : o |PO FO| --+
| +--------------+ : --<--<--<--<-- : +--------------+ |
| +- : ROHC Channel B :<-+ |
| | : --<--<--<--<-- : | |
| +--------------+ | :................: | +--------------+ |
| <-|DO CI|<-+ +- |CO UI|<- |
| | ROHC | | ROHC | |
| | Decompressor | Bi-directional channel | Compressor | |
| | B | .................. | B | |
| | | : -->-->-->-->-- : | | |
| o|PO FO| --> : FB Channel B : --> |FI PI|o |
| +--------------+ : -->-->-->-->-- : +--------------+ |
| : : |
| : --<--<--<--<-- : |
+----------------------- : FB Channel A : <----------------------+
: --<--<--<--<-- :
:................:
In this example, feedback is, in both directions, sent on its own dedicated channel, as discussed in e.g., feedback realization example 1-3 of ROHC [RFC-3095, page 44]. With this configuration, the piggybacking/interspersing mechanism of ROHC is not used, and the PI/PO connections are thus left open (marked with a "o"). It should
在本例中，反馈在两个方向上通过其自身的专用信道发送，如ROHC[RFC-3095，第44页]的反馈实现示例1-3所述。在这种配置下，不使用ROHC的背驮/穿插机制，因此PI/PO连接保持打开状态（标有“o”）。它应该
be noted that in this picture FI/PI and PO/FO at the A-instances have been swapped to simplify drawing, while the B-instances have been horizontally mirrored.
请注意，在这张图片中，A实例处的FI/PI和PO/FO已交换以简化绘图，而B实例已水平镜像。
In previous sections, it has been clarified that one network element may have multiple IP interfaces, one IP interface may have multiple ROHC instances running (not necessarily both compressors and decompressors), and for each ROHC instance, there is exactly one ROHC channel and optionally one ROHC feedback channel. How ROHC channels and ROHC feedback channels are realized will differ from case to case, depending on the actual layer two technology used.
在前面的章节中，已经澄清，一个网元可能有多个IP接口，一个IP接口可能有多个ROHC实例在运行（不一定同时运行压缩器和解压缩器），并且对于每个ROHC实例，正好有一个ROHC通道和可选的一个ROHC反馈通道。ROHC通道和ROHC反馈通道的实现方式因情况而异，具体取决于实际使用的第二层技术。
Each compressor/decompressor can further compress/decompress an arbitrary (but limited) number of concurrent packet streams sent over the ROHC channel connected to that compressor/decompressor. Each packet stream relates to one particular context in the compressor/decompressor. When sent over the ROHC channel, compressed packets are labeled with a context identifier (CID), indicating to which context the compressed packet corresponds. There is thus a one-to-one mapping between the number of contexts that can be present in a compressor/decompressor and the context identifier (CID) space used in compressed packets over that ROHC channel. This is illustrated by the following figure:
每个压缩器/解压缩器可以进一步压缩/解压缩通过连接到该压缩器/解压缩器的ROHC信道发送的任意（但有限）数量的并发分组流。每个分组流与压缩器/解压缩器中的一个特定上下文相关。当通过ROHC信道发送时，压缩数据包标有上下文标识符（CID），指示压缩数据包对应的上下文。因此，在可存在于压缩器/解压缩器中的上下文的数量与在该ROHC信道上的压缩分组中使用的上下文标识符（CID）空间之间存在一对一映射。如下图所示：
+------------------------------------------------------------------+
| IP Interface |
+---------------+----+---------------+----+---------------+--------+
| ROHC | | ROHC | | ROHC |
| Compressor | | Compressor | | Decompressor |
| Context 0...N | | Context 0...M | | Context 0...K | ...
+--+---------+--+ +--+---------+--+ +--+---------+--+
^ | ^ | : ^
: CID | : CID | : CID |
: 0...N | : 0...M | : 0...K |
: v : v v |
ROHC ROHC ROHC ROHC ROHC ROHC
Feedback Channel Feedback Channel Feedback Channel
Channel Channel Channel
+------------------------------------------------------------------+
| IP Interface |
+---------------+----+---------------+----+---------------+--------+
| ROHC | | ROHC | | ROHC |
| Compressor | | Compressor | | Decompressor |
| Context 0...N | | Context 0...M | | Context 0...K | ...
+--+---------+--+ +--+---------+--+ +--+---------+--+
^ | ^ | : ^
: CID | : CID | : CID |
: 0...N | : 0...M | : 0...K |
: v : v v |
ROHC ROHC ROHC ROHC ROHC ROHC
Feedback Channel Feedback Channel Feedback Channel
Channel Channel Channel
It should be noted that each ROHC instance at an IP interface therefore has its own context and CID space, and it must be ensured that the CID size of the corresponding decompressor at the other end of the ROHC channel is not smaller than the CID space of the compressor.
需要注意的是，IP接口上的每个ROHC实例都有自己的上下文和CID空间，必须确保ROHC通道另一端对应的解压器的CID大小不小于压缩器的CID空间。
This document has introduced and defined a number of concepts and terms for use in ROHC network integration, and explained how the various pieces relate to each other. In the following bullet list, the most important relationship conclusions are repeated:
本文件介绍并定义了ROHC网络集成中使用的一些概念和术语，并解释了各部分之间的相互关系。在以下项目列表中，重复了最重要的关系结论：
- A network element may have one or several IP interfaces.
- 一个网元可以有一个或多个IP接口。
- Each IP interface is connected to one or several logical layer two channels.
- 每个IP接口连接到一个或多个逻辑层两个通道。
- Each IP interface may have one or several ROHC instances, either compressors, decompressors, or an arbitrary mix of both.
- 每个IP接口可以有一个或多个ROHC实例，可以是压缩器、解压缩器，也可以是两者的任意组合。
- For each ROHC instance, there is exactly one ROHC channel, and optionally exactly one ROHC feedback channel.
- 对于每个ROHC实例，只有一个ROHC通道，也可以选择只有一个ROHC反馈通道。
- How ROHC channels and ROHC feedback channels are realized through the available logical layer two channels will vary, and there is therefore no general relation between ROHC instances and logical layer two channels. ROHC instances map only to ROHC channels and ROHC feedback channels.
- ROHC通道和ROHC反馈通道如何通过可用的逻辑层两个通道实现将有所不同，因此ROHC实例和逻辑层两个通道之间没有一般关系。ROHC实例仅映射到ROHC通道和ROHC反馈通道。
- Each compressor owns its own context identifier (CID) space, which is the multiplexing mechanism it uses when sending compressed header packets to its corresponding decompressor. That CID space thus defines how many compressed packet streams can be concurrently sent over the ROHC channel allocated to the compressor/decompressor peers.
- 每个压缩器都拥有自己的上下文标识符（CID）空间，这是将压缩的头数据包发送到相应的解压缩器时使用的多路复用机制。因此，该CID空间定义了可以通过分配给压缩器/解压缩器对等方的ROHC信道并发发送多少压缩分组流。
This section will address how the conceptual aspects discussed above affect implementations of ROHC.
本节将讨论上述概念方面如何影响ROHC的实施。
ROHC is defined as a general header compression framework on top of which compression profiles can be defined for each specific set of headers to compress. Although the framework holds a number of important mechanisms, the separation between framework and profiles is mainly a separation from a standardization point of view, to indicate what must be common to all profiles, what must be defined by all profiles, and what are profile-specific details. To implement the framework as a separate module is thus not an obvious choice, especially if one wants to use profile implementations from different vendors. However, optimized implementations will probably separate the common parts and implement those in a ROHC framework module, and add profile modules to that.
ROHC被定义为一个通用的报头压缩框架，在这个框架之上，可以为要压缩的每个特定的报头集定义压缩配置文件。尽管框架拥有许多重要的机制，但框架和概要文件之间的分离主要是从标准化的角度分离，以指示所有概要文件必须共有的内容、所有概要文件必须定义的内容以及特定于概要文件的细节。因此，将框架作为一个单独的模块来实现并不是一个明显的选择，特别是如果希望使用来自不同供应商的概要文件实现的话。然而，优化的实现可能会分离公共部分，并在ROHC框架模块中实现这些部分，并向其中添加概要文件模块。
A ROHC instance might thus consist of various pieces of implementation modules, profiles, and potentially also a common ROHC module, possibly from different vendors. If vendor and implementation version information is made available for network management purposes, this should thus be done on a per-profile basis, and potentially also for the instance as a whole.
因此，ROHC实例可能由不同的实现模块、配置文件以及可能来自不同供应商的通用ROHC模块组成。如果出于网络管理目的提供了供应商和实施版本信息，则应在每个概要文件的基础上进行此操作，并可能对整个实例进行此操作。
The clear understanding of ROHC channels and their relations to IP interfaces and the physical medium, plays a critical role in ensuring secure usage of ROHC. This document is therefore a valuable adjunct to the Security Considerations found in RFC 3095 and other ROHC specifications. However, as it just reviews information and definitions, it does not add new security issues to the ROHC protocol specifications.
清楚了解ROHC通道及其与IP接口和物理介质的关系，对于确保ROHC的安全使用至关重要。因此，本文件是RFC 3095和其他ROHC规范中安全注意事项的重要补充。然而，由于它只是审查信息和定义，因此没有在ROHC协议规范中添加新的安全问题。
Thanks to Juergen Quittek, Hans Hannu, Carsten Bormann, and Ghyslain Pelletier for fruitful discussions, improvement suggestions, and review. Thanks also to Peter Eriksson for doing a language review.
感谢Juergen Quitek、Hans Hannu、Carsten Bormann和Ghyslain Pelletier的富有成效的讨论、改进建议和审查。还要感谢Peter Eriksson做了一次语言复习。
[RFC-3095] 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.
[RFC-3095]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月。
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
Lars Erik Jonsson Ericsson AB信箱920 SE-971 28瑞典卢利亚
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
EMail: lars-erik.jonsson@ericsson.com
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
EMail: lars-erik.jonsson@ericsson.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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编辑功能的资金目前由互联网协会提供。