头压缩协议(rfc4996)中文翻译.docx

RFC4996中文版
RObust Header Compression (ROHC):
A Profile for TCP/IP (ROHC-TCP)
摘要
本文档为TCP/IP报头指定了一个健壮的头压缩机制。该机制被称为ROHC-TCP，提供了有效且健壮的TCP头压缩，包括频繁使用的TCP选项，如SACK（选择性确认）和时戳。
ROHC-TCP在错误率高和RTT长的链路上表现良好，常有许多这样的链路带宽有限，必需要头压缩。

目录
1. 介绍
2. 术语
基础上下文
基础上下文是压缩器和解压器都已经证实的上下文。一个基础上下文可以被用来作为使用复制建立新上下文的参考

基础上下文标识符（基础CID）
基础CID是标识基础上下文的CID，从基础上下文中可以提取到上下文复制时需要的信息

基础报头
未压缩报文的最里层的IP和TCP报头的压缩形式

链接条目
一条链基于相似的特性组合条目。ROHC-TCP为静态、动态、可复制或不规则的条目定义条目链。链接是通过为每个报头添加条目来完成的，例如以条目在未压缩报文中出现顺序来添加给链。

上下文复制(CR)
上下文复制是一种基于另外一个存在的有效上下文（一个基础上下文）来建立和初始化一个新上下文的机制。引入这个机制是为了减少上下文建立流程的负载，特别适用于压缩多个短暂TCP连接，这些连接可能同时或近乎同时发生

ROHC-TCP报文类型
ROHC-TCP使用3种报文类型：初始和刷新（IR）报文类型，上下文修复（IR-CR）报文类型和压缩（CO）报文类型

短暂（Short-lived） TCP传输
是指用每个单个连接只传输少量报文的TCP连接
2.1缩写
2.2翻译术语
Profile 机制
Packet 报文
Header 报头、头
Fields 字段、域
formal notation 标注格式
3. 背景
3.1 现存TCP/IP头压缩机制
3.2 TCP/IP头字段分类
报文有可能压缩正是由于报文（尤其是连续的报文）的头字段之间有很大的冗余。 对于TCP/IP头压缩要利用这些特性，了解各种头部字段的变化模式就很重要。
所有TCP/IP报文的头字段都已在RFC4413中详细分类。主要结论是大多数头字段很容易被压缩，因为它们从不改变或很少改变。然而以下字段确实需要更复杂的机制:
- IPv4 Identification (16 bits) - IP-ID
- TCP Sequence Number (32 bits) - SN
- TCP Acknowledgment Number (32 bits)
- TCP Reserved ( 4 bits)
- TCP ECN flags ( 2 bits) - ECN
- TCP Window (16 bits)
- TCP Options
o Maximum Segment Size (32 bits) - MSS
o Window Scale (24 bits) - WSCALE
o SACK Permitted (16 bits)
o TCP SACK (80, 144, 208, or 272 bits) - SACK
o TCP Timestamp (80 bits) - TS
IP-ID值能有多种方式分配，通常是有序的、按序跳变或随机的其中之一，如4.1.3 [RFC4413]节所述。一些IPV4栈使用有序分配产生IP-ID值，但是不按照该值的网络字节序发送，而是将2个字节颠倒后发送。在这种情况下压缩器能在交换子节后压缩IP-ID字段。因此，解压器也在解压后交换IP-ID字节以再生出原始IP-ID。关于TCP压缩，[RFC4413]中分析显示在TCP字段中没有明显的备选来推导出IP-ID。
几个TCP字段（Sequence Number,Acknowledgment Number, Window等）的变化很难预测。理解序列号和确认号[RFC4413]对于TCP/IP头压缩机制特别重要。
特别地，TCP序列号能是TCP窗口范围内的任意值（即，可能在任何地方进行压缩）。丢包或重传能引起TCP序列号在窗口限制内波动。TCP窗口也限制了确认号跳变。
TCP/IP头的另外一个重要行为是序列号和确认号之间的依赖。关于数据业务TCP连接能要么是近乎对称，要么显示出强烈的不对称偏好。这意味着在转发路径（从服务器到客户端）上，对于大部分报文，只有确认号在变化，而序列号保持不变。TCP压缩机制应该有适用于两者情况的报文格式，即，报文格式要么能够携带单序列号比特、单确认号比特，要么两者皆可。
另外，TCP流能是短时传输。TCP短时传输会降低通过初始发送全头来建立上下文的头压缩机制的性能。多个同时或近乎同时的TCP连接可能在头子段值和上下文值之间显示出许多相似性，这个使得在初始化新的上下文时复用流之间的信息成为可能。为此，一种上下文复用机制，通过复用一个存在的上下文的一部分给一个新流，使得上下文建立更快更高效。RFC4413的总结是部分IP子上下文、一些TCP字段和一些上下文值能被复制，因为它们很少变化或者仅仅一个小的跳变。
ROHC-TCP也压缩如下报头：IPV6目的选项报头[RFC2460]、IPV6路由报头、IPV6逐跳选项报头[RFC2460]、鉴权报头（AH）[RFC4302]、空加密封装安全负载（ESP）报头[RFC4303]、通用路由封装（GRE）[RFC2784][RFC2890]和最小封装头（MINE）[RFC2004]。
本文档没有针对移动IP(IPV4或IPV6)的特殊处理，原因和RFC3095中的描述类似。
4. TCP/IP机制概述（信息的）
4.1 通用概念
ROHC-TCP使用RFC4995描述的头压缩协议。支持RFC4164种定义的上下文复制。上下文复制对短时TCP流[RFC4413]特别有用。
4.2 压缩器和解压器交互
4.2.1 压缩器操作
采用ROHC的头压缩在概念上可以表现为一个压缩器和解压器交互的状态机。压缩机的任务是，基于对有关解压器上下文状态的一定信心，发送需要成功解压报文的最少信息。
对于ROHC-TCP压缩，压缩器通常开始工作时初始假设解压器没有有用信息来处理新流，于是发送初始化和刷新（IR）报文。可选地，压缩器也可以支持上下文复制（CR），使用IR-CR报文[RFC4164]，来尝试复用和另外一个流相关的上下文信息。
之后，基于对解压器已经有必要信息来成功处理自己选择的压缩（CO）报文的信心，压缩器能调整压缩级别。换言之，压缩器的任务就是确保解压器工作在允许解压最有效的CO报文的状态，否则确保允许解压器尽可能转移到这样的状态。
4.3.2 解压器反馈
ROHC-TCP机制能在带或者不带从解压器到压缩器的反馈能力的环境中使用。但是，ROHC-TCP假设：如果一个ROHC反馈信道可用，并且如果对于一个指定的ROHC-TCP上下文这个信道至少一次被解压强使用，那么对于该上下文该信道将要在整个压缩操作被使用。如果反馈信道消失了，压缩必须要重启。
接收到确认（ACKs）或否定应答（NACKs），就为收到反馈的上下文建立来自解压器的反馈信道。一旦为指定上下文建立了反馈信道，压缩器应该使用该反馈来估计解压器当前的状态。这个通过提供压缩器达到必要的信心级别所需的信息，有助于增加压缩效率。
ROHC-TCP反馈机制的能力是被FEEDBACK-2格式（见8.3节）中使用的主序列号（MSN）（见6.1.1节）的位数（最低有效位（LSB）编码）限制的。
4.3 报文格式和编码方法
使用[RFC4997]标注形式定义ROHC-TCP使用的报文格式和编码方法。这个标注格式被用来提供报文格式的清晰表示以及编码方式的清楚定义。
4.3.1 压缩TCP选项
ROHC-TCP使用允许建立选项内容的列表压缩编码来压缩TCP选项，这样TCP选项能被加入到上下文，而不用必须发送所有未压缩的TCP选项。
4.3.2 压缩扩展头
ROHC-TCP压缩3.2节中列出的扩展头。这些扩展头和其他其它报头同样对待，因此具有静态链，动态链，不规则链和上下文复制链（见6.2）。
这意味着报头从正在压缩的流中出现或消失将会导致静态链变化。但是，使用这个设计策略，扩展头的变化模式注定不会影响压缩效率。
4.4ROHC-TCP期望的压缩率
下述表格描述了使用ROHC-TCP和IPHC[RFC2507]预期的典型压缩效率。
表格中的数字假设压缩上下文已经被很好地初始化。对于TS选项，时戳以小值变化。所有的TCP选项包含一个合适个无操作（NOP）选项[RFC0793]来填充和\或对齐。最后，以IPV4为例，具有有序的IP-ID行为。
Fig. typical compression ratios of ROHC-TCP and IPHC

1) 数据流的负载大小是常量
2) 报头中出现SACK选项，但是不在前面的报文中。假设有2个SACK块。
3) 报头中出现SACK选项，同时也在前面的报文中（具有不同的SACK块）。假设有2个SACK块。
下表描述了ROHC-TCP和IPHC的典型初始压缩率。例子中的数据流假设是IPV4+TCP，IP-ID具有有序行为。如下选项出现在SYN报文中：TS、MSS、WSCALE，以及一些合适个NOP选项。
Fig. typical initial compression ratios of ROHC-TCP and IPHC

表中的数字假设压缩器在压缩第二个报文前已经收到一个来自解压器的确认，当ROHC-TCP中使用反馈时能够期望收到确认。这是因为在大部分情况下，TCP ACKs期望使用相同的返回路径，并且因为TCP不能发送更多的报文直到TCP SYN报文被确认。
5. 压缩器和解压器逻辑（规范的）
5.1 上下文初始化
ROHC-TCP流的静态上下文能用以下两种方式之一进行初始化
ú 通过使用7.1节的IR报文，profile是0x06，并且静态链以TCP头的静态部分结束
ú 通过使用RFC4164定义的机制复制一个存在的上下文。这是用7.2节定义的IR-CR报文，profile是0x06。
5.2 压缩器操作
5.2.1 压缩逻辑
压缩器的任务是决定在压缩TCP/IP报文时发送什么数据，使得解压器基于当前状态能成功重构初始报文。选择压缩头类型来发依赖于需要因素，包括：
ú 报文流中的头子段变化行为，例如，在可用报文格式的限制范围内传送必要的信息
ú 压缩器对解压器状态的信心级别，例如，为多个连续的数据包或来从接收解压器反馈（ACK和\或NACKs）中，选择报头格式来更新同类型信息翻译地有点奇怪

ú 报文流需要的额外的健壮性，例如，当不期待解压器的反馈时，周期地使用IR和IR-DYN报文刷新静态和动态信息
这些因素对压缩器报文类型选择的影响在后面子章节中进行更为详细的描述。
在本节中，“更高压缩状态”意味着将在压缩报文中发送更少数据，即，使用更小的压缩头。同时更低压缩状态意味着更多数据将使用更大的压缩报文发送。
5.2.1.1 优化方法
优化方法是一种准则，据此准则压缩器为一些报文（连续或不连续）发送相同类型的信息，直到压缩器相当自信于解压器以及收到了这个信息。当ROHC-TCP用来在丢包链路中压缩报文时，优化方法对保证健壮性很有用。
因此，如果未压缩报文的字段X值发生了变化，压缩器必须使用一种报文类型，该类型包含字段X的编码直到压缩器有足够信心于解压器已经至少收到了包含X新值的一个报文。压缩器应该选择一个具有最小报头的能携带变化的压缩格式来满足使用的优化方法条件。
5.2.1.2 周期上下文刷新
当使用优化方法时，由于解压器没有收到正确解压的足够信息总有可能解压失败。
因此，压缩器应该周期移到更低的压缩状态并且发送IR\或IR-DYN报文，直到解压器建立一个反馈信道。这些刷新能基于超时，基于流中发送的压缩报文个数，或者任何其他特定于实现的策略。一旦建立了反馈信道，解压器可以停止周期刷新。
5.2.2 反馈逻辑
反馈消息、应答（ACKs）、否定应答(NACKs或STATIC-NACKs)的语义在5.2.4.1 [RFC4995]节定义。
5.2.2.1 可选的应答（ACKs）
压缩器可以使用应答反馈（ACKs）来移到更高的压缩状态。
接收到一个更新上下文的报文的ACK，压缩器获取足够的信心于解压器已经受到了被确认的报文并且解压器已经获得了报文流中被确认报文前的变化。
这个功能是可选的，因此压缩器不必期待得到这样的ACKs，即便有反馈信道可用并且已经为该报文流建立了反馈信道。
5.2.2.2否定应答(NACKs)
压缩器使用来自于解压器的反馈来移到更低的压缩状态（NACKs）。
接收到NACK反馈，压缩器应该
ú 假设解压器仅仅静态部分是有效的，并且
ú 下一次在压缩指示流的报文时，重发所有的动态信息（通过IR或IR-DYN报文）
除非猜测对应的场景是：在NACK报文之后，压缩器已经发送过包含所有动态信息的IR或IR-DYN报文
压缩器有信心于在正被确认的报文之后发送的信息已经为NACK反馈提供了合适的响应。另外， 压缩器可以使用携带7比特循环冗余检查（CRC）的CO报文，如果压缩器能有足够信息决策出什么信息会为NACK反馈提供合适的响应。
接收到STATIC-NACK反馈，压缩器应该
ú 假设解压器没有有效上下文，并且
ú 下一次在压缩指示流的报文时，重发所有的静态和动态信息（通过IR报文）
除非压缩器有信心于在正被确认的报文之后发送的信息已经为STATIC-NACK反馈提供了合适的响应。
5.2.3 上下文复制
压缩器可以通过实现RFC416中定义的额外压缩和反馈逻辑来支持上下文复制。
5.3 解压器操作
5.3.1解压器状态和逻辑
解压器的3个状态时无上下文（NC）、静态上下文（SC）和全上下文（FC）。解压器开始于最低压缩状态，NC状态。成功解压总会将解压器移到FC状态。解压器一旦进入该状态正常不会离开；只有重复解压失败会强制解压器向下转移到更低的状态。
下面是解压器的状态机。状态之间转移的细节和压缩器逻辑在图后面的子节给出。
解压器的状态机

5.3.1.1 重构和验证
当解压IR或IR-DYN报文，解压器必须验证接收到的使用CRC-8校验[RFC4995]的报文头的完整性。如果验证失败，报文不允许递给上层。
当收到一个IR-CR报文，解压器必须执行[RFC4164]中指定的行为。
当解压其它报文类型（例如，CO报文），解压器必须验证使用CRC校验[RFC4995]的解压缩尝试的结果。如果验证失败，解压器实现可以尝试矫正或修复报文的方法，并且任何尝试结果必须使用CRC校验验证；反之，报文不允许递给上层。
当收到报文的CRC-8校验或CRC校验成功，解压器应该用当前报头中收到的信息更新上下文；然后解压器将重构的报文传给系统的网络层。反之，解压器的上下文不允许被更新。
如果接收到的报文比当前参考报文更旧，例如，基于压缩报文中的主序列号（MSN），解压器可以避免使用当前报文信息更新上下文，即便报文的正确性已经被成功验证。
5.3.1.2 检测上下文损坏
所有报头格式携带CRC并且是上下文更新。一个CRC成功的报文或者显示地（从压缩报头携带的字段的信息中）或者隐式地（从其它字段中推到出来的字段）更新所有头字段的参考值。
解压器可以假设一些或整个上下文是无效的，在一个或多个故障之后使用CRC验证或验证报头。因为解压器不能知道CRC失败的准确原因或者什么字段引起的，因此上下文的有效性并不是指确切的上下文条目被认为是有效与否。
上下文的有效性相当于检测上下文中的问题。解压器首先假设最有可能引起失败的信息类型是每个报文正常变化的状态，即，上下文动态部分的上下文损坏。由于重复的失败和不成功的修复，解压器假设整个上下文，包括静态部分，需要被修复，即，静态上下文损坏。
上下文损坏检测
上下文损坏的假设意味着解压器将不会尝试解压一个携带3-bit CRC的CO报头，并且仅仅尝试解压IR、IR-DYN、IR-CR报头或被CRC-7保护的CO报头。
静态上下文损坏检测
静态上下文损坏的假设意味着解压器避免尝试解压除IR报头外的任何类型的报头。
怎么做出这些假设，即，上下文损坏如何被检测，对实现是开放的。It can be based on the residual error rate, where a low error rate makes the decompressor assume damage more often than on a high-rate link。
解压器通过选择其尝试解压的压缩报头类型来实现假设。换言之，上下文的有效性涉及到解压器尝试或者不尝试解压特定的报文类型。
5.3.1.3 无上下文（NC）状态
起初，工作在NC状态，解压器还没有成功解压一个报文。
允许的解压：
在NC状态，只有携带在静态字段的足够信息的报文（IR和IR-CR报文）能被解压缩；否则，报文不允许解压缩并且不允许提交给上层。
反馈逻辑：
在NC状态，如果收到除IR外的其它报文或者IR报文解压失败，解压器应该发送遵从反馈速率限制[见5.3.2节]的STATIC-NACK。
一旦报文已经被证实并且解压成功，解压器必须转移到FC状态。
5.3.1.4 静态上下文（SC）状态
当解压器是静态上下文（SC）状态，只有解压器上下文的静态部分是有效的。
如果检测到静态上下文损坏，解压器从SC状态移回NC状态。
允许的解压：
在SC状态，携带被8-bit CRC覆盖的动态字段的足够信息的报文（IR和IR-DYN报文）或者被7-bit CRC覆盖的CO报文能被解压缩；否则，报文不允许解压缩并且不允许提交给上层。
反馈逻辑：
在SC状态，如果IR/IR-DYN/IR-CR的CRC验证失败并且假设静态上下文损坏，解压器应该发送STATIC-NACK。以上两种情况都要遵从反馈速率限制[见5.3.2节]。
一旦报文已经被证实并且解压成功，解压器必须转移到FC状态。
5.3.1.5 全上下文（FC）状态
当解压器是静态上下文（FC）状态，解压器上下文的静态部分和动态部分都是有效的。如果检测到静态上下文损坏，解压器从FC状态移回SC状态。
允许的解压：
在FC状态，不管收到报文的类型，都尝试解压。
反馈逻辑：
在FC状态，如果任何报文类型解压失败并且假设静态上下文损坏，解压器应该发送NACK。以上两种情况都要遵从反馈速率限制[见5.3.2节]。
5.3.2反馈逻辑
解压器可能发送正反馈（ACKs）来为特殊流初始建立反馈信道。要么正反馈（ACKs）或负反馈（NACKs）建立这个信道。
一旦反馈信道被建立，只要上下文和相同的profile相关联（profile值为 0x0006），像5.3.1节为每个状态定义的每个逻辑一样，解压器需要继续发送NACKs或者STATIC-NACKs。
解压器可以基于任何一个报文类型的正确解压发送ACKs。特别是，携带重要上下文更新的报文被正确解压，解压器可以发送一个ACK。
解压器应该限制发送反馈（ACKs和NACKs/STATIC-NACKs）的速率，并且应该避免发送不必要的重复的相同类型的反馈消息，这些消息和相同的事件关联。
5.3.3 上下文复制
ROHC-TCP支持上下文复制。因此，压缩器必须实现RFC416中定义的额外解压缩和反馈逻辑。
6. ROHC-TCP编码（规范的）
6.1 ROHC-TCP中的控制域
ROHC-TCP用许多控制域来解释来自压缩器的报文格式。
一个控制域就是一个从压缩器传到解压器的字段，而不是未压缩报头的部分。控制域的值在压缩器和解压器的上下文中建立。一旦解压器建立，这些域应该一直保持不变直到被另外一个报文更新。
6.1.1 主序列号（MSN）
如RFC4413中解释的，TCP头中没有字段可以作为TCP压缩的主序列号。
为了解决这个问题，ROHC-TCP介绍一个叫主序列号（MSN）的字段。MSN字段在压缩器创建，而不是用未压缩报头中已经存在的一个字段。压缩器在发送每个报文时给MSN的值加一。
MSN字段有以下两个功能：
1. 发送反馈数据时区分报文
2. 推导递增字段的值，如IP-ID字段
压缩器发送的每个报文都存在MSN字段。在CO报文中MSN使用LSB编码，在IR/IR-DYN报文中发送全部的16比特MSN。解压器总是发送作为反馈信息部分的MSN，之后压缩器能使用这些MSN来推断解压器在确认哪些报文。
MSN应该初始化为一个随机数。压缩器只应该为IR或IR-CR报文（CID被关联到还没有被分配给该profile的上下文时发送）初始化一个新的MSN。换言之，如果压缩器复用相同的CID来一个接一个地压缩许多TCP流，MSN不被强制重新初始化而是继续单调增加。
对于上下文复制，当发送IR-CR报文时，压缩器不使用基上下文中的MSN，除非复制流程覆盖了基上下文（即，Base CID == CID）。如果MSN已经存在于和新流（CID）相关的ROHC-TCP上下文，压缩器使用该MSN值，否则MSN被初始化为一个新值。
6.1.2 IP-ID行为
IPv4报头的IP-ID字段能有不同的变化模式。概念上，压缩器检测IP-ID字段的变化来选择最匹配发现的变化模式的编码方法和报文格式。
为了灵活压缩该字段可能的行为，ROHC-TCP为IP-ID定义了不同种类的压缩技术：网络字节序顺序的（NBO），字节转换顺序的，随即的（RND），或者常数0。
压缩器检测一些报文的IP-ID字段值的变化，来识别出上面列出的哪一个压缩选择是最匹配发现的变化模式。然后压缩器能基于识别的字段行为选择报文格式和编码方法。
如果存在超过一层的IP报头，ROHC-TCP能只给最里层的IP报头分配一个顺序行为（NBO或者字节转换）。这是因为仅这个IP-ID（见6.1.1）有可能和MSN有一个足够近的关系来作为顺序变化字段来压缩它。因此，一个压缩器不允许分配顺序的（NBO）或字节转换顺序的行为给隧道报头。
IP-ID行为的控制字段决定了将要使用的包格式的集合。这些控制字段也被用来为每个IP头决定不规则链条目（见6.2节）的内容。
6.1.3 显示拥塞通知（ECN）
当ECN [RFC3168]在流中被使用一次，ECN比特位会经常变化。ROHC-TCP在上下文中维护一个控制域来指示ECN是否被使用。这个控制域在TCP报头的动态链中发送，使用特定的携带7-bit CRC的压缩报头来更新。
当这个控制域指示ECN正在被使用，不规则链中的所有IP和TCP报头包含ECN使用的比特位。为了保证字节对齐，所有TCP预留比特位被发送，并且外层IP报头的整个Type of Service/Traffic Class (TOS/TC)域被包含在无规则链中。当报文中只有一个IP报头时，这个压缩行为允许压缩器通过在压缩报头中加入一个单独的字节来处理ECN比特位的变化。
当控制域设置时在压缩报文中包含所有IP头的ECN比特位的原因是，该profile需要有效压缩包含使用“full-functionality选项”（见[RFC3168]的9.1节）的IP隧道的流。对于这些流，里层IP报头的ECN比特位变化会被传播到外部IP报头。当使用"limited-functionality"选项，压缩机将因此有时发送一个字节超过必要每隧道报头，但这一直被认为是该profile的一个合理的折衷设计。
76.2 压缩头链
一些报文使用一个或多个包含子头信息的链。一个链的功能是组织基于类似特征的字段，例如静态、动态、或不规则字段。从最外层报头的字段开始，按照条目在未压缩报文中出现的顺序，通过附加每个报头的一个条目到该链上来进行组链。
为所有ROHC-TCP压缩的报头定义链，如下列出。也列出了这些协议报头的编码方法名。
o TCP [RFC0793], 编码方法: "tcp"
o IPv4 [RFC0791], 编码方法: "ipv4"
o IPv6 [RFC2460], 编码方法: "ipv6"
o AH [RFC4302], 编码方法: "ah"
o GRE [RFC2784][RFC2890], 编码方法: "gre"
o MINE [RFC2004], 编码方法: "mine"
o NULL-encrypted ESP [RFC4303], 编码方法: "esp_null"
o IPv6 Destination Options header [RFC2460], 编码方法:"ip_dest_opt"
o IPv6 Hop-by-Hop Options header [RFC2460], 编码方法:"ip_hop_opt"
o IPv6 Routing header [RFC2460], 编码方法: "ip_rout_opt"
静态链
静态链由被压缩协议链的每个报头的一个条目构成，从最外层IP报头开始，以TCP报头结束。在报文格式的正式描述中，这个每个报头的静态链条目是一个后缀为_static的名字。静态链仅仅在IR报文中使用。
外层ipv4或者ipv6头静态部分，格式：ipv4_static ，ipv6_static
外层ipv4扩展头或者ipv6选项静态部分（按照存在的先后顺序），格式：dest_opt_static, hop_opt_static, rout_opt_static, gre_static, mine_static, ah_static, esp_static
……
最里层ipv4或者ipv6头静态部分，格式：ipv4_static ，ipv6_static
最里层ipv4扩展头或者ipv6选项静态部分（按照存在的先后顺序），格式：dest_opt_static, hop_opt_static, rout_opt_static, gre_static, mine_static, ah_static, esp_static
TCP头静态部分，格式： tcp_static

动态链
动态链由被压缩协议链的每个报头的一个条目构成，从最外层IP报头开始，以TCP报头结束。TCP报头的动态链条目也包含TCP选项（见6.3节）的压缩列表。在报文格式的正式描述中，这个每个报头的动态链条目是一个后缀为_dynamic的名字。静态链在IR和IR-DYN报文中使用。
外层ipv4或者ipv6头动态部分，格式：ipv4_dynamic ，ipv6_dynamic
外层ipv4扩展头或者ipv6选项动态部分（按照存在的先后顺序），格式：dest_opt_dynamic , hop_opt_dynamic, gre_dynamic , ah_static, esp_dynamic
……
最里层ipv4或者ipv6头动态部分，格式：ipv4_dynamic ，ipv6_dynamic
最里层ipv4扩展头或者ipv6选项动态部分（按照存在的先后顺序），格式：dest_opt_dynamic , hop_opt_dynamic, gre_dynamic , ah_static, esp_dynamic
TCP头动态部分，格式： tcp_dynamic
TCP选项压缩列表，格式见6.3.3，其中item部分格式：eol_list_item, mss_list_item, wscale_list_item, tsopt_list_item, sack1_list_item, sack2_list_item, sack3_list_item, sack4_list_item

复制链
复制链由被压缩协议链的每个报头的一个条目构成，从最外层IP报头开始，以TCP报头结束。TCP报头的复制链条目也包含TCP选项（见6.3节）的压缩列表。在报文格式的正式描述中，这个每个报头的复制链条目是一个后缀为_replicate的名字。不在复制链中的头字段从基础上下文中复制。复制链仅在IR-CR报文中使用。
不规则链
不规则链的结构和静态链的结构相似。对于每个压缩报文，不规则链被附加到7.3节定义的压缩报文的通用格式的指定位置。这个链也包括6.3.6节定义的TCP选项的不规则链条目，按照选项在未压缩报头出现的顺序，被直接放在TCP报头不规则链的后面。在报文格式的正式描述中，这个每个报头的不规则链条目是一个后缀为_irregular的名字。不规则链仅在CO报文中使用。
最里层的IP报头的不规则链的格式不同于外层IP报头的格式，因为这个报头是压缩基础报头的部分。
外层ipv4或者ipv6头不规则部分，格式：ipv4_outer_without_ttl_irregular，ipv4_outer_with_ttl_irregular，ipv6_outer_without_ttl_irregular，ipv6_outer_with_ttl_irregular
外层ipv4扩展头或者ipv6选项动态部分（按照存在的先后顺序），格式：dest_opt_irregular , gre_irregular , ah_irregular
……
最里层ipv4或者ipv6头不规则部分，格式：ipv4_innermost_irregular，ipv6_innermost_irregular
最里层ipv4扩展头或者ipv6选项动态不规则部分（按照存在的先后顺序），格式：dest_opt_irregular , gre_irregular , ah_irregular
TCP头不规则部分，格式： tcp_irregular
TCP选项不规则部分格式：tsopt_irregular, sack_unchanged_irregular, sack1_irregular, sack2_irregular, sack3_irregular, sack4_irregular，

6.3 用列表压缩法压缩TCP选项
本节从细节上描述怎样将列表压缩用于TCP选项。在ROHC-TCP的报文格式定义中，最频繁的TCP选项每个都有一个编码方法，如下表列出。

这些编码方法的每一个都有一个解压缩格式，后缀以"_list_item" 和"_irregular"。在这些情况下，单独的编码方法可以有多个"_list_item" 或"_irregular"格式，这些格式的内部绑定决定了使用什么格式。这将在后续章节中描述。
6.3.1 列表压缩
未压缩报文中的TCP选项能被构造成一个有序的列表，其顺序和出现常常是不变的。列表的通用格式如下
Fig. 列表的通用结构

为了压缩这个列表，ROHC-TCP使用一种列表压缩机制，其个别地压缩这些条目中每一个，并将它们结合成一个压缩列表。
列表压缩的基本原则如下：
1) 当上下文被初始化时，选项压缩列表的完整表述被发送。所有有内容的选项都在压缩器发送的条目压缩列表中出现。
然后，一旦上下文已经被初始化：
2) 当列表的结构和内容都不变时，没有列表相关信息需要在列表中发送
3) 当列表结构没有变化，且只有一个或多个选项的不规则格式中的内容变化时，没有列表相关信息需要在压缩基头中发送；不规则内容作为不规则链的部分发送，见6.3.6节描述
4) 当列表结构变化，一个压缩列表在压缩基头中发送，包括其结构和顺序的描述。假如这个条目内容不是压缩列表的一部分，在一个选项的不规则格式中定义的内容也要作为不规则链部分被发送（见6.3.6节描述）
6.3.2 基于表格的条目压缩
基于表格的条目压缩法压缩在压缩列表中发送的独立条目。压缩器分配一个唯一的标识符“Index”给列表的每个条目“Item”。
压缩逻辑
压缩器概念性地维护一个条目表格，包含所有条目，用“Index”索引。（Index, Item）对在压缩列表中一起发送，直到压缩器对解压器已经观察到条目及其索引间的映射有足够自信。通过接受来自解压器的确认来获得自信，或者使用优化方法发送（索引，条目）对来获得自信。一旦获得自信，索引被单独发送用来指示存在其对应的条目。
压缩器可以将一个已存在的索引重分配给一个新的条目，然后需要用上述的相同方式重建映射。
解压逻辑
解压器概念上维护一个包含它收到的所有（索引，条目）对的表格。无论何时收到（索引，条目）对并且CRC校验成功都更新这个表格。无论何时解压器收到一个没有条目伴随的索引，都从表格中检索其条目。
如果收到一个索引没有伴随着条目并且解压器没有该索引的任何上下文，报头必须被丢弃并且应该要发送NACK。
6.3.3 压缩列表编码
压缩列表中存在的每个条目被表示为：
ú 一个索引，指向表格的条目
ú 一个存在比特，指示一个条目的压缩形式是否存在于列表中
ú 一个条目（如果设置了存在比特）
如果存在比特没有设置并且解压器上下文中没有这个条目的登记，一个条目的解压将会失败。
TCP选项的压缩列表使用下面的编码

Reserved:必须被设置为0，否则，解压器必须丢弃这个报文
PS: 指示XI字段的大小
PS = 0 指示4-bit XI 字段
PS = 1 指示8-bit XI 字段
m: 压缩列表中XI条目的个数
XI_1, ..., XI_m: m个XI条目。每个XI代表一个未压缩报文中的TCP选项，按它们在未压缩报文中出现的相同顺序
XI条目格式如下

X: 指示列表中是否存在条目:
X = 1 指示和Index关联的条目在发送的item_1, ..., item_n中;
X = 0 指示和Index关联的条目没有发送而是包含在不规则链中
Reserved: 必须被设置为0，否则，解压器必须丢弃这个报文
Index: 指向条目表格的索引。见6.3.4节。
当4-bit XI条目被使用，该XI条目按字节以下面的方式放置:

Padding: 一个4-bit补充字段，当PS = 0 且m是奇数时存在。该字段发送时必须被设置为0，否则，解压器必须丢弃这个报文
Item 1, ..., item n: 每个条目对应到XI 1, ..., XI m中的一个XI。在条目列表中的记录的格式在6.2节描述。
6.3.4 条目表格映射
TCP选项列表压缩的条目表格被限制为16个不同的条目，因为任何报文包含大量唯一选项是不可能的。
TCP选项类型和表格索引的映射关系在下表中列出：

一些TCP选项比另一些使用的更频繁。为了简化它们的压缩，条目表格的一部分被保留给这些选项类型，如上表所示。当使用列表压缩时，压缩器和解压器必须使用这些条目和索引间的映射来压缩解压TCP选项。
期望保留索引的选项类型在条目表格中只出现一次。但是，如果一个选项类型在相同的选项列表中出现了两次并且如果两个选项内容不同，压缩器应该通过映射到通用压缩选项来压缩第二个出现的选项类型。而如果选项有相同的值，压缩器将为两者使用相同的表格索引。
NOP选项
NOP选项在列表中出现能超过一次。但是，因为它的值总是相同的，没有上下文信息需要被传输。这样多个NOP选项能被映射到相同的索引。因为NOP选项当被压缩为一个“_list_item”时没有任何内容，它将从不在条目列表中出现。为了一致性，压缩器应该仍然在列表中建立一个记录，设置“存在比特位”，就像为其它类型选项做的一样。
列表压缩总是保持每个条目在解压列表中原始顺序，不管在压缩的“_list_item”中是否存在条目，或者是否相同