Internet Engineering Task Force (IETF) C. Dearlove
Request for Comments: 7466 BAE Systems ATC
Updates: 6130, 7181 T. Clausen
Category: Standards Track LIX, Ecole Polytechnique
ISSN: 2070-1721 March 2015
Internet Engineering Task Force (IETF) C. Dearlove
Request for Comments: 7466 BAE Systems ATC
Updates: 6130, 7181 T. Clausen
Category: Standards Track LIX, Ecole Polytechnique
ISSN: 2070-1721 March 2015
An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
移动自组网（MANET）邻域发现协议（NHDP）的优化
Abstract
摘要
The link quality mechanism of the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold while still retaining the corresponding link information as acquired from the HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently.
移动自组织网络（MANET）邻域发现协议（NHDP）的链路质量机制允许“忽略”一些1跳邻居，前提是来自该1跳邻居的测量链路质量低于可接受阈值，同时仍然保留从HELLO消息交换获取的相应链路信息。如果链路质量后来得到充分改善，这允许立即恢复1跳邻居。
NHDP also collects information about symmetric 2-hop neighbors. However, it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" (as described above), then corresponding symmetric 2-hop neighbors are removed. This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment.
NHDP还收集关于对称2跳邻居的信息。但是，它指定如果来自对称1跳邻居的链路停止对称，包括“忽略”（如上所述），则删除相应的对称2跳邻居。如果对称1-hop邻居的链路质量下降到可接受的阈值以下（即使只是暂时），这可能会导致对称2-hop邻居信息被永久删除（直到接收到进一步的HELLO消息）。
This specification updates RFC 6130 "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)" and RFC 7181 "The Optimized Link State Routing Protocol Version 2 (OLSRv2)" to permit, as an option, retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more "robust".
本规范更新了RFC 6130“移动自组织网络（MANET）邻域发现协议（NHDP）”和RFC 7181“优化链路状态路由协议版本2（OLSRv2）”，允许保留但忽略，当来自相应1跳邻居的链路质量下降到可接受阈值以下时，对称2跳信息。这允许立即恢复对称2-hop邻居，如果随后链路质量得到充分改善，从而使对称2-hop邻居更“健壮”。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7466.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7466.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Applicability Statement .........................................4
4. Changes to NHDP .................................................4
4.1. Interface Information Bases ................................5
4.2. HELLO Message Processing ...................................5
4.3. Information Base Changes ...................................5
4.4. Constraints ................................................6
5. Changes to OLSRv2 ...............................................6
6. Security Considerations .........................................8
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................8
Acknowledgements ...................................................9
Authors' Addresses .................................................9
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Applicability Statement .........................................4
4. Changes to NHDP .................................................4
4.1. Interface Information Bases ................................5
4.2. HELLO Message Processing ...................................5
4.3. Information Base Changes ...................................5
4.4. Constraints ................................................6
5. Changes to OLSRv2 ...............................................6
6. Security Considerations .........................................8
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................8
Acknowledgements ...................................................9
Authors' Addresses .................................................9
Section 14 of the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] contains a link admission mechanism known as "link quality" that allows a router using that protocol to "take considerations other than message exchange into account for determining when a link is and is not a candidate for being considered as HEARD or SYMMETRIC." Specifically, [RFC6130] permits a router to disallow consideration of some of its 1-hop neighbors for as long as the quality of the link from that 1-hop neighbor is below an acceptable link quality threshold.
MANET邻域发现协议（NHDP）[RFC6130]的第14节包含一种称为“链路质量”的链路接纳机制，该机制允许使用该协议的路由器“考虑消息交换以外的其他因素，以确定链路何时被认为是或不是被认为是侦听或对称的候选链路。”具体地说，[RFC6130]允许路由器在来自该1跳邻居的链路质量低于可接受的链路质量阈值的情况下，不允许考虑其一些1跳邻居。
A feature of this mechanism is that while the link quality remains too low, the link information, established by the exchange of HELLO messages, is retained. Thus, if the link quality later goes above the required threshold (note that a hysteresis mechanism means that two thresholds are used), then the link is immediately established and will be immediately available for use.
该机制的一个特点是，虽然链接质量仍然过低，但通过HELLO消息交换建立的链接信息仍然保留。因此，如果链路质量随后超过所需的阈值（注意，滞后机制意味着使用两个阈值），则链路将立即建立并立即可供使用。
[RFC6130] collects not only 1-hop neighbor information, but also information about symmetric 2-hop neighbors. However, [RFC6130] specifies that if a 1-hop neighbor was, but no longer is, considered symmetric, then the corresponding 2-Hop Tuples that may have been recorded for that 2-hop neighbor are to be removed without a retention mechanism for a (possibly temporary) loss due to link quality.
[RFC6130]不仅收集1跳邻居信息，还收集对称2跳邻居的信息。但是，[RFC6130]指定，如果一个1跳邻居被认为是对称的，但不再是对称的，那么可能已经为该2跳邻居记录的对应2跳元组将被删除，而不需要保留机制，以避免由于链路质量而导致的（可能是暂时的）丢失。
This means that if there is a short period in which link quality is too low, then when the link quality is re-established all 1-hop neighbor information is immediately available for use again. However, the corresponding symmetric 2-hop neighbor information has been removed and is not available for use until restored by receipt of the next corresponding HELLO message.
这意味着，如果在短时间内链路质量过低，则当重新建立链路质量时，所有1跳邻居信息立即可供再次使用。但是，相应的对称2跳邻居信息已被删除，在收到下一条对应的HELLO消息后恢复之前，该信息不可用。
This specification describes how [RFC6130] can be modified to avoid this situation by retaining (but not using) 2-hop information, similar to what is done with 1-hop information. This modification is strictly optional, and routers that do and do not implement it can interwork entirely successfully (as they also can with different link quality specifications). In addition, by a suitable interpretation (that ignored 2-Hop Tuples are not externally advertised), this change can be invisible to any other protocols using [RFC6130], in particular [RFC7181]. However, the impact on [RFC7181] when 2-Hop Tuples are not so handled is also described (owing to the existence of implementations of that protocol that are not modularly separated from [RFC6130]).
本规范描述了如何修改[RFC6130]，通过保留（但不使用）2跳信息来避免这种情况，类似于1跳信息。这种修改是严格可选的，执行和不执行该修改的路由器可以完全成功地互通（因为它们也可以使用不同的链路质量规范）。此外，通过适当的解释（忽略的2-Hop元组不会在外部公布），使用[RFC6130]，特别是[RFC7181]的任何其他协议都无法看到此更改。然而，还描述了当不这样处理2跳元组时对[RFC7181]的影响（由于存在与[RFC6130]没有模块化分离的该协议的实现）。
This specification therefore updates [RFC6130] and [RFC7181].
因此，本规范更新了[RFC6130]和[RFC7181]。
This update to [RFC6130] does not change the definition of a symmetric 2-hop neighbor but adds new state information to each 2-Hop Tuple of [RFC6130]. This is to retain some 2-hop neighbor information while recording it as currently not to be used. The new state information and retained 2-Hop Tuples are reflected in the corresponding tables of the updated NHDP-MIB module [NHDP-MIB].
对[RFC6130]的此更新不会更改对称2跳邻居的定义，但会向[RFC6130]的每个2跳元组添加新的状态信息。这是为了保留一些2跳邻居信息，同时将其记录为当前不使用的信息。新的状态信息和保留的2跳元组反映在更新的NHDP-MIB模块[NHDP-MIB]的相应表中。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Additionally, this document uses the terminology of [RFC6130] and [RFC7181].
此外，本文件使用了[RFC6130]和[RFC7181]的术语。
This specification updates [RFC6130]. The optimization presented in this specification is simply permissive, as it allows retaining information that otherwise would have been removed but does not use that information except when it could have been used by [RFC6130].
本规范更新了[RFC6130]。本规范中提出的优化是完全允许的，因为它允许保留否则将被删除的信息，但不使用该信息，除非[RFC6130]可以使用该信息。
This can, in some cases, ensure that the symmetric 2-hop neighborhood is more robust against temporary link quality changes and consequently yields a more stable network. The only other consequence of this optimization is that state for some otherwise expired 2-Hop Tuples may be maintained for longer.
在某些情况下，这可以确保对称2-hop邻域对临时链路质量变化更具鲁棒性，从而产生更稳定的网络。此优化的唯一其他结果是，某些过期的2-Hop元组的状态可能会保持更长时间。
This specification also updates [RFC7181]. This could have been avoided had instead [RFC6130] been updated so as to make the changes to it invisible to any other protocol using it. However, as it is known that some implementations of [RFC7181] are not independent of the implementation of [RFC6130] that they use, it is useful to indicate the direct impact on [RFC7181].
本规范还更新了[RFC7181]。如果对[RFC6130]进行更新，使其更改对使用它的任何其他协议都不可见，则可以避免这种情况。然而，众所周知，[RFC7181]的一些实现并不独立于它们使用的[RFC6130]的实现，因此指出对[RFC7181]的直接影响是有用的。
A router that implements the optimization described in this specification will interoperate successfully with routers that implement [RFC6130] but do not implement this optimization.
实现本规范中所述优化的路由器将与实现[RFC6130]但未实现此优化的路由器成功互操作。
The following changes are made to [RFC6130] if using this specification. Note that while this specification is OPTIONAL, if any of these changes are made, then all of these changes MUST be made.
如果使用本规范，则对[RFC6130]进行以下更改。请注意，虽然本规范是可选的，但如果进行了任何更改，则必须进行所有这些更改。
The 2-Hop Set is modified by adding this additional element to each 2-Hop Tuple:
通过向每个2-Hop元组添加此附加元素来修改2-Hop集：
N2_lost is a boolean flag, which indicates the state of the corresponding Link Tuple. If L_status = SYMMETRIC (and thus L_lost = false), then N2_lost = false. If L_SYM_time has not expired, and L_lost = true (and hence L_status = LOST), then N2_lost = true.
N2_lost是一个布尔标志，指示相应链接元组的状态。如果L_状态=对称（因此L_丢失=错误），则N2_丢失=错误。如果L_SYM_time未过期，且L_lost=true（因此L_status=lost），则N2_lost=true。
In all other cases, including other cases with L_status = LOST, there will be no such 2-Hop Tuples.
在所有其他情况下，包括L_status=LOST的其他情况下，将不会有这样的两跳元组。
In Section 12.6 of [RFC6130], make the following changes:
在[RFC6130]第12.6节中，进行以下更改：
o In point 2, change "L_status = SYMMETRIC" to "L_SYM_time not expired".
o 在第2点中，将“L_status=SYMMETRIC”更改为“L_SYM_time not expired”。
o In point 2, point 1, point 1, under "then create a 2-Hop Tuple with:", add a second bullet point "N2_lost: = L_lost". (Note that "2-Hop Neighbor Tuple" has been corrected here to "2-Hop Tuple" per [Err4276].)
o 在第2点、第1点、第1点中，在“然后用：”，创建一个2跳元组”下，添加第二个项目符号“N2_lost:=L_lost”。（请注意，根据[Err4276]，此处已将“2跳邻居元组”更正为“2跳元组”。）
In Section 13, replace the second bullet point with:
在第13节中，将第二个要点替换为：
o A Link Tuple's L_status changes from SYMMETRIC, L_SYM_time expires, or the Link Tuple is removed. In this case, the actions specified in Section 13.2 are performed.
o 链接元组的L_状态从“对称”更改，L_SYM_时间过期，或链接元组被删除。在这种情况下，执行第13.2节中规定的操作。
Replace the paragraph after the bullet points with:
将要点后的段落替换为：
If a Link Tuple is removed, or if L_HEARD_time expires and either L_status changes from SYMMETRIC or L_SYM_time expires, then the actions specified in Section 13.2 MUST be performed before the actions specified in Section 13.3 are performed for that Link Tuple.
如果删除链接元组，或者如果L_hear_time过期且L_状态从SYMMETRIC更改或L_SYM_time过期，则必须在对该链接元组执行第13.3节中指定的操作之前执行第13.2节中指定的操作。
In Section 13.2 of [RFC6130], add the following before all other text:
在[RFC6130]第13.2节中，在所有其他文本之前添加以下内容：
For each Link Tuple that has L_SYM_time not expired:
对于L_SYM_time未过期的每个链接元组：
1. If L_SYM_time then expires, or if the Link Tuple is removed:
1. 如果L_SYM_time过期，或者如果链接元组被删除：
1. Remove each 2-Hop Tuple for the same MANET interface with:
1. 使用以下方法删除同一MANET接口的每个2跳元组：
+ N2_neighbor_iface_addr_list contains one or more network addresses in L_neighbor_iface_addr_list.
+ N2_neighbor_iface_addr_列表包含L_neighbor_iface_addr_列表中的一个或多个网络地址。
2. If L_status then changes from SYMMETRIC to LOST because L_lost is set to true:
2. 如果L_状态从对称变为丢失，因为L_丢失设置为true：
1. For each 2-Hop Tuple for the same MANET interface with:
1. 对于同一MANET接口的每个2跳元组：
+ N2_neighbor_iface_addr_list contains one or more network addresses in L_neighbor_iface_addr_list;
+ N2_neighbor_iface_addr_列表包含L_neighbor_iface_addr_列表中的一个或多个网络地址；
set N2_lost := true.
设置N2_丢失：=真。
Also, in Section 13.2 of [RFC6130], remove point 1 and renumber point 2 as point 1.
此外，在[RFC6130]第13.2节中，删除第1点，并将第2点重新编号为第1点。
In Appendix B of [RFC6130], under "In each 2-Hop Tuple:", change the first bullet point to:
在[RFC6130]的附录B中，在“每个2跳元组中：”下，将第一个项目符号更改为：
o There MUST be a Link Tuple associated with the same MANET interface with:
o 必须有一个链接元组与同一MANET接口关联，该接口具有：
* L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND
* L_neighbor_iface_addr_list=N2_neighbor_iface_addr_list；和
* L_SYM_time not expired; AND
* L_SYM_时间未到期；和
* L_lost = N2_lost.
* L_丢失=N2_丢失。
If the implementation of [RFC6130] conceals from any protocol using it the existence of all 2-Hop Tuples with N2_lost = true, then no changes are required to any protocol using [RFC6130]; in particular, no changes are required to [RFC7181].
如果[RFC6130]的实现对使用它的任何协议隐藏了存在N2_lost=true的所有2-Hop元组，则不需要对使用[RFC6130]的任何协议进行更改；特别是，无需对[RFC7181]进行任何更改。
However, if instead the implementation of [RFC6130] makes all 2-Hop Tuples visible, including those with N2_lost = true, then protocols using [RFC6130] MUST ignore such 2-Hop Tuples.
但是，如果[RFC6130]的实现使所有2跳元组可见，包括N2_lost=true的元组，则使用[RFC6130]的协议必须忽略此类2跳元组。
For [RFC7181], given that this protocol uses 2-hop information for Multipoint Relay (MPR) Set and Routing Set calculation but does not include that information in control traffic, this means that an implementation must be behaving (i) as if a 2-Hop Tuple only exists if N2_lost=false and (ii) as if a change of N2_lost (from false to true, or true to false) corresponds to a 2-Hop Tuple appearing or being removed. Specifically, this means behaving as if all of the following changes were to be made to [RFC7181]:
对于[RFC7181]，鉴于该协议使用2跳信息进行多点中继（MPR）集和路由集计算，但不将该信息包括在控制通信量中，这意味着实现必须表现为（i）在N2_丢失=false时，2跳元组才存在；（ii）在N2_丢失的情况下，2跳元组的变化（从false到true，或从true到false）对应于出现或删除的2-Hop元组。具体而言，这意味着其行为就像对[RFC7181]进行以下所有更改一样：
o In Section 17.6 of [RFC7181], point 1, replace the final two bullet points with:
o 在[RFC7181]第17.6节第1点中，将最后两个要点替换为：
* A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC and N2_lost = false is added or removed; OR
* 具有N2_out_度量的两跳元组！=添加或删除未知度量和N2_lost=false；或
* A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC has N2_lost changed; OR
* 具有N2_out_度量的两跳元组！=未知度量已更改；或
* The N2_out_metric of any 2-Hop Tuple with N2_lost = false changes, and either the flooding MPR selection process uses metric values (see Section 18.4), or the change is to or from UNKNOWN_METRIC.
* 具有N2_lost=false的任何2跳元组的N2_out_度量更改，泛洪MPR选择过程使用度量值（参见第18.4节），或者更改为未知_度量或来自未知_度量。
o In Section 17.6 of [RFC7181], point 3, replace the final two bullet points with:
o 在[RFC7181]第17.6节第3点中，将最后两个要点替换为：
* A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC and N2_lost = false is added or removed; OR
* 具有N2_in_度量的两跳元组！=添加或删除未知度量和N2_lost=false；或
* A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC has N2_lost changed; OR
* 具有N2_in_度量的两跳元组！=未知度量已更改；或
* The N2_in_metric of any 2-Hop Tuple with N2_lost = false changes.
* N2_丢失的任何2跳元组的N2_in_度量=错误更改。
o In Section 17.7 of [RFC7181], in the fifth bullet point, add "and N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
o 在[RFC7181]第17.7节中，在第五个项目符号中，在“N2_out_metric！=未知_metric！”之后添加“and N2_lost=false”。
o In Section 18.4 of [RFC7181], in the third bullet point, add ", N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
o 在[RFC7181]第18.4节中，在第三个项目符号中，在“N2_out_metric！=未知_metric！”之后添加“N2_lost=false”。
o In Section 18.5 of [RFC7181], in the third bullet point, add ", N2_lost = false" after "N2_in_metric != UNKNOWN_METRIC".
o 在[RFC7181]第18.5节中，在第三个项目符号中，在“N2_In_metric！=未知_metric！”之后添加“N2_lost=false”。
o In Section 19.1 of [RFC7181], in the final main bullet point (marked as "(OPTIONAL)"), add "and N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
o 在[RFC7181]第19.1节中，在最后一个主项目符号（标记为“（可选）”中，在“N2_out_metric！=未知_metric！”之后添加“and N2_lost=false”。
o In Appendix C.7 of [RFC7181], in point 1, add "and N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
o 在[RFC7181]的附录C.7中，在第1点中，在“N2_out_metric！=未知_metric！”之后添加“和N2_lost=false”。
The update to [RFC6130] enables the retention and reuse of some information collected by that protocol, for only the duration that it could have been used in any case. As such, this protocol introduces no new security considerations to an implementation of [RFC6130] or of any other protocol that uses it, such as [RFC7181].
[RFC6130]的更新允许保留和重用该协议收集的某些信息，保留和重用的时间仅限于在任何情况下都可以使用的时间。因此，该协议不会对[RFC6130]或使用它的任何其他协议（如[RFC7181]）的实现引入新的安全考虑。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011, <http://www.rfc-editor.org/info/rfc6130>.
[RFC6130]Clausen，T.，Dean，J.，和C.Dearlove，“移动自组网（MANET）邻域发现协议（NHDP）”，RFC6130，2011年4月<http://www.rfc-editor.org/info/rfc6130>.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014, <http://www.rfc-editor.org/info/rfc7181>.
[RFC7181]Clausen，T.，Dearlove，C.，Jacquet，P.，和U.Herberg，“优化链路状态路由协议版本2”，RFC 7181，2014年4月<http://www.rfc-editor.org/info/rfc7181>.
[Err4276] RFC Errata, Errata ID 4276, RFC 6130.
[Err4276]RFC勘误表，勘误表ID 4276，RFC 6130。
[NHDP-MIB] Herberg, U., Cole, R., Chakeres, I., and T. Clausen, "Definition of Managed Objects for the Neighborhood Discovery Protocol", Work in Progress, draft-ietf-manet-rfc6779bis, August 2014.
[NHDP-MIB]Herberg，U.，Cole，R.，Chakeres，I.，和T.Clausen，“邻域发现协议管理对象的定义”，正在进行的工作，草案-ietf-manet-rfc6779bis，2014年8月。
Acknowledgements
致谢
The authors would like to thank Liz Cullen (BAE Systems) for first illustrating the issue addressed in this specification.
作者要感谢Liz Cullen（BAE Systems）首先阐述了本规范中解决的问题。
Authors' Addresses
作者地址
Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom
克里斯托弗·迪尔洛夫英国切姆斯福德大巴德西汉宁菲尔德路BAE系统先进技术中心
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Thomas Heide Clausen LIX, Ecole Polytechnique
托马斯·海德·克劳森·利克斯，理工学院
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/