Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 6695 Cisco Systems
Category: Informational August 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 6695 Cisco Systems
Category: Informational August 2012
ISSN: 2070-1721
Methods to Convey Forward Error Correction (FEC) Framework Configuration Information
传递前向纠错（FEC）框架配置信息的方法
Abstract
摘要
The Forward Error Correction (FEC) Framework document (RFC 6363) defines the FEC Framework Configuration Information necessary for the FEC Framework operation. This document describes how to use signaling protocols such as the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time Streaming Protocol (RTSP), etc. for determining and communicating the configuration information between sender(s) and receiver(s).
前向纠错（FEC）框架文档（RFC 6363）定义了FEC框架操作所需的FEC框架配置信息。本文档描述了如何使用信令协议（如会话公告协议（SAP）、会话启动协议（SIP）、实时流协议（RTSP）等）来确定发送方和接收方之间的配置信息并进行通信。
This document doesn't define any new signaling protocol.
本文档未定义任何新的信令协议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc6695.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6695.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................2
2. Specification Language ..........................................3
3. Terminology/Abbreviations .......................................3
4. FEC Framework Configuration Information .........................4
4.1. Encoding Format ............................................5
5. Signaling Protocol Usage ........................................6
5.1. Signaling Protocol for Multicasting ........................7
5.1.1. Sender Procedure ....................................9
5.1.2. Receiver Procedure .................................11
5.2. Signaling Protocol for Unicasting .........................12
5.2.1. SIP ................................................12
5.2.2. RTSP ...............................................13
6. Security Considerations ........................................14
7. IANA Considerations ............................................14
8. Acknowledgments ................................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
1. Introduction ....................................................2
2. Specification Language ..........................................3
3. Terminology/Abbreviations .......................................3
4. FEC Framework Configuration Information .........................4
4.1. Encoding Format ............................................5
5. Signaling Protocol Usage ........................................6
5.1. Signaling Protocol for Multicasting ........................7
5.1.1. Sender Procedure ....................................9
5.1.2. Receiver Procedure .................................11
5.2. Signaling Protocol for Unicasting .........................12
5.2.1. SIP ................................................12
5.2.2. RTSP ...............................................13
6. Security Considerations ........................................14
7. IANA Considerations ............................................14
8. Acknowledgments ................................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
The FEC Framework document [RFC6363] defines the FEC Framework Configuration Information that governs the overall FEC Framework operation common to any FEC scheme. This information must be available at both the sender and receiver(s).
FEC框架文档[RFC6363]定义了FEC框架配置信息，该信息管理任何FEC方案通用的总体FEC框架操作。此信息必须在发送方和接收方都可用。
This document describes how various signaling protocols such as the Session Announcement Protocol (SAP) [RFC2974], the Session Initiation Protocol (SIP) [RFC3261], the Real Time Streaming Protocol (RTSP) [RFC2326], etc. could be used by the FEC scheme (and/or the Content Delivery Protocol (CDP)) to communicate the configuration information
本文档描述了FEC方案（和/或内容交付协议（CDP））如何使用各种信令协议，例如会话公告协议（SAP）[RFC2974]、会话发起协议（SIP）[RFC3261]、实时流协议（RTSP）[RFC2326]等，来传递配置信息
between the sender and receiver(s). The configuration information may be encoded in any compatible format, such as the Session Description Protocol (SDP) [RFC4566], XML, etc., though this document refers to SDP encoding usage quite extensively.
在发送方和接收方之间。配置信息可以以任何兼容的格式编码，例如会话描述协议（SDP）[RFC4566]、XML等，尽管本文档非常广泛地引用了SDP编码用法。
Note that this document doesn't define any new signaling protocol; rather, it just provides examples of how existing protocols should be used. Also, the list of signaling protocols for unicast is not intended to be a complete list.
注意，本文件未定义任何新的信令协议；相反，它只是提供了如何使用现有协议的示例。此外，用于单播的信令协议的列表并不打算是完整的列表。
This document doesn't describe any FEC-Scheme-Specific Information (FSSI) (for example, how source blocks are constructed) or any sender- or receiver-side operation for a particular FEC scheme (for example, whether the receiver makes use of one or more repair flows that are received). Such FEC scheme specifics should be covered in separate document(s). This document doesn't mandate a particular encoding format for the configuration information either.
本文档不描述任何FEC方案特定信息（FSSI）（例如，如何构造源块）或特定FEC方案的任何发送方或接收方操作（例如，接收方是否使用接收到的一个或多个修复流）。此类FEC计划细节应包含在单独的文件中。本文档也没有为配置信息指定特定的编码格式。
This document is structured as follows: Section 3 describes the terms used in this document, Section 4 describes the FEC Framework Configuration Information, Section 5 describes how to use signaling protocols for multicast and unicast applications, and Section 6 discusses security considerations.
本文档的结构如下：第3节描述了本文档中使用的术语，第4节描述了FEC框架配置信息，第5节描述了如何为多播和单播应用程序使用信令协议，第6节讨论了安全注意事项。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document makes use of the terms/abbreviations defined in the FEC Framework document [RFC6363] and defines the following additional terms:
本文件使用了FEC框架文件[RFC6363]中定义的术语/缩写，并定义了以下附加术语：
o Media Sender - Node providing original media flow(s) to the 'FEC Sender'
o 媒体发送方-向“FEC发送方”提供原始媒体流的节点
o Media Receiver - Node performing the media decoding
o 媒体接收器-执行媒体解码的节点
o FEC Sender - Node performing the FEC encoding on the original media flow(s) to produce the FEC repair flow(s)
o FEC发送方-对原始媒体流执行FEC编码以生成FEC修复流的节点
o FEC Receiver - Node performing the FEC decoding, as needed, and providing the original media flow(s) to the Media Receiver
o FEC接收器-根据需要执行FEC解码并向媒体接收器提供原始媒体流的节点
o Sender - Same as FEC Sender
o 发送方-与FEC发送方相同
o Receiver - Same as FEC Receiver
o 接收器-与FEC接收器相同
o (Media) Flow - A single media instance, i.e., an audio stream or a video stream
o （媒体）流-单个媒体实例，即音频流或视频流
This document deliberately refers to the 'FEC Sender' and 'FEC Receiver' as the 'Sender' and 'Receiver', respectively.
本文件有意将“FEC发送方”和“FEC接收方”分别称为“发送方”和“接收方”。
The FEC Framework [RFC6363] defines a minimum set of information that is communicated between the sender and receiver(s) for a proper operation of an FEC scheme. This information is referred to as "FEC Framework Configuration Information". This is the information that the FEC Framework needs in order to apply FEC protection to the transport flows.
FEC框架[RFC6363]定义了发送方和接收方之间为FEC方案的正确操作而通信的最小信息集。该信息称为“FEC框架配置信息”。这是FEC框架将FEC保护应用于传输流所需的信息。
A single instance of the FEC Framework provides FEC protection for all packets of a specified set of source packet flows, by means of one or more packet flows consisting of repair packets. As per Section 5.5 of the FEC Framework document [RFC6363], the FEC Framework Configuration Information includes the following for each FEC Framework instance:
FEC框架的单个实例通过由修复分组组成的一个或多个分组流，为源分组流的指定集合的所有分组提供FEC保护。根据FEC框架文件[RFC6363]第5.5节，FEC框架配置信息包括每个FEC框架实例的以下内容：
1. Identification of the repair flow(s)
1. 确定维修流程
2. Identification of source flow(s)
2. 源流识别
3. Identification of FEC scheme
3. FEC方案的识别
4. Length of Explicit Source FEC Payload ID
4. 显式源FEC有效负载ID的长度
5. FSSI
5. FSSI
FSSI basically provides an opaque container to encode FEC-scheme-specific configuration information such as buffer size, decoding wait-time, etc. Please refer to the FEC Framework document [RFC6363] for more details.
FSSI基本上提供了一个不透明的容器来编码FEC方案特定的配置信息，如缓冲区大小、解码等待时间等。有关更多详细信息，请参阅FEC框架文档[RFC6363]。
The usage of signaling protocols described in this document requires that the application layer responsible for the FEC Framework instance provide the value for each of the configuration information parameters (listed above) encoded as per the chosen encoding format. In case of failure to receive the complete information, the signaling protocol module must return an error for Operations, Administration, and Maintenance (OAM) purposes and optionally convey this error to the application layer. Please refer to Figure 1 of the FEC Framework document [RFC6363] for further illustration.
本文档中描述的信令协议的使用要求负责FEC框架实例的应用层提供根据所选编码格式编码的每个配置信息参数（上面列出）的值。如果无法接收完整信息，信令协议模块必须返回一个用于操作、管理和维护（OAM）目的的错误，并可选地将该错误传递给应用层。请参阅FEC框架文件[RFC6363]的图1以了解更多说明。
This document does not make any assumption that the 'FEC Sender' and 'Media Sender' functionalities are implemented on the same device, though that may be the case. Similarly, this document does not make any assumption that 'FEC Receiver' and 'Media Receiver' functionalities are implemented on the same device, though that may be the case. There may also be more than one Media Sender.
本文档不假设“FEC发送方”和“媒体发送方”功能在同一设备上实现，尽管可能是这样。类似地，本文件不假设“FEC接收器”和“媒体接收器”功能在同一设备上实现，尽管可能是这样。也可能有多个媒体发件人。
The FEC Framework Configuration Information (listed above in Section 4) may be encoded in any format, such as SDP, XML, etc., as chosen or preferred by a particular FEC Framework instance. The selection of such encoding formats or syntax is independent of the signaling protocol and beyond the scope of this document.
FEC框架配置信息（在上文第4节中列出）可以按照特定FEC框架实例选择或优选的任何格式进行编码，例如SDP、XML等。此类编码格式或语法的选择独立于信令协议，并且超出了本文件的范围。
Any encoding format that is selected for a particular FEC Framework instance must be known to the signaling protocol. This is to provide a means (e.g., a field such as Payload Type) in the signaling protocol message(s) to convey the chosen encoding format for the configuration information so that the payload (i.e., configuration information) can be correctly parsed as per the semantics of the chosen encoding format at the receiver. Please note that the encoding format is not a negotiated parameter, but rather a property of a particular FEC Framework instance and/or its implementation.
信令协议必须知道为特定FEC框架实例选择的任何编码格式。这是为了在信令协议消息中提供一种手段（例如，诸如有效载荷类型的字段）来传送所选择的用于配置信息的编码格式，使得有效载荷（即，配置信息）可以在接收机处根据所选择的编码格式的语义被正确解析。请注意，编码格式不是协商参数，而是特定FEC框架实例和/或其实现的属性。
Additionally, the encoding format for each FEC Framework configuration parameter must be defined in terms of a sequence of octets that can be embedded within the payload of the signaling protocol message(s). The length of the encoding format must either be fixed or be derived by examining the encoded octets themselves. For example, the initial octets may include some kind of length indication.
此外，每个FEC框架配置参数的编码格式必须根据可嵌入到信令协议消息的有效载荷中的八位字节序列来定义。编码格式的长度必须是固定的，或者通过检查编码的八位字节本身来推导。例如，初始八位字节可以包括某种长度指示。
Independent of the encoding formats supported by an FEC scheme, each instance of the FEC Framework must use a single encoding format to describe all of the configuration information associated with that instance. The signaling protocol specified in this document should not validate the encoded information, though it may validate the syntax or length of the encoded information.
独立于FEC方案支持的编码格式，FEC框架的每个实例都必须使用单个编码格式来描述与该实例关联的所有配置信息。本文档中指定的信令协议不应验证编码信息，尽管它可以验证编码信息的语法或长度。
The reader may refer to the SDP elements document [RFC6364], which describes the usage of the 'SDP' encoding format as an example encoding format for the FEC Framework Configuration Information.
读者可以参考SDP元素文档[RFC6364]，该文档描述了“SDP”编码格式作为FEC框架配置信息的示例编码格式的用法。
The FEC Framework [RFC6363] requires that certain FEC Framework Configuration Information be available to both the sender and receiver(s). This configuration information is almost always formulated at the sender (or on behalf of the sender) and somehow made available at the receiver(s). While one may envision a static method to populate the configuration information at both the sender and receiver(s), it would not be optimal, since it would (a) require the knowledge of every receiver in advance, (b) require the time and means to configure each receiver and sender, and (c) increase the possibility of misconfiguration. Hence, there is a benefit in using a dynamic method (i.e., signaling protocol) to convey the configuration information between the sender and one or more receivers.
FEC框架[RFC6363]要求某些FEC框架配置信息对发送方和接收方都可用。此配置信息几乎总是在发送方（或代表发送方）制定，并以某种方式在接收方可用。虽然可以设想一种静态方法来填充发送方和接收方的配置信息，但它不是最优的，因为它（a）需要事先了解每个接收方，（b）需要时间和方法来配置每个接收方和发送方，以及（c）增加错误配置的可能性。因此，使用动态方法（即，信令协议）在发送方和一个或多个接收机之间传送配置信息是有益的。
Since the configuration information may be needed at a particular receiver versus many receivers (depending on the multimedia stream being unicast (e.g., Video on Demand (VoD); or multicast, e.g., broadcast or IPTV), we need two types of signaling protocols -- one to deliver the configuration information to many receivers via multicasting (as described in Section 5.1), and the other to deliver the configuration information to one and only one receiver via unicasting (as described in Section 5.2).
由于配置信息可能需要在特定接收器处而不是在多个接收器处（取决于单播的多媒体流（例如，视频点播（VoD）；或多播，例如，广播或IPTV），因此我们需要两种类型的信令协议——一种通过多播将配置信息传递给多个接收器（如第5.1节所述），另一个通过单播（如第5.2节所述）将配置信息传送给一个且仅一个接收器。
Figure 1 below illustrates a sample topology showing the FEC Sender and FEC Receiver (which may or may not be the Media Sender and Media Receiver, respectively) such that FEC_Sender1 is serving FEC_Receiver11, FEC_Receiver12, and FEC_Receiver13 via the multicast signaling protocol, whereas FEC_Sender2 is serving only FEC_Receiver2 via the unicast signaling protocol.
下面的图1示出了一个示例拓扑，该拓扑显示了FEC发送方和FEC接收方（它们可能分别是或可能不是媒体发送方和媒体接收方），使得FEC_发送方1通过多播信令协议为FEC_接收方11、FEC_接收方12和FEC_接收方13提供服务，然而，FEC_发送器2通过单播信令协议仅服务于FEC_接收器2。
FEC_Sender2---------| |--------FEC_Receiver2
| |
FEC_Sender1-------IP/MPLS network
|-----------FEC_Receiver11
|-----------FEC_Receiver12
|-----------FEC_Receiver13
FEC_Sender2---------| |--------FEC_Receiver2
| |
FEC_Sender1-------IP/MPLS network
|-----------FEC_Receiver11
|-----------FEC_Receiver12
|-----------FEC_Receiver13
Figure 1. Topology Using Sender and Receiver
图1。使用发送方和接收方的拓扑
The rest of the document continues to use the terms 'Sender' and 'Receiver' to refer to the 'FEC Sender' and 'FEC Receiver', respectively.
本文件其余部分继续使用术语“发送方”和“接收方”分别指代“FEC发送方”和“FEC接收方”。
This specification describes using SAP version 2 [RFC2974] as the signaling protocol to multicast the configuration information from one sender to many receivers. The apparent advantage is that the server doesn't need to maintain any state for any receiver using SAP.
本规范描述了使用SAP版本2[RFC2974]作为信令协议，将配置信息从一个发送方多播到多个接收方。明显的优势是服务器不需要为任何使用SAP的接收方维护任何状态。
SAP messages are carried over UDP over IP with destination UDP port 9875, as described in [RFC2974], and a source UDP port of any available number. The SAP message(s) MUST contain an authentication header using Pretty Good Privacy (PGP) authentication.
SAP消息通过UDP over IP传输，目标UDP端口为9875（如[RFC2974]中所述），源UDP端口为任何可用号码。SAP邮件必须包含使用相当好的隐私（PGP）身份验证的身份验证标头。
At the high level, a sender, acting as the SAP announcer, signals the FEC Framework Configuration Information for each FEC Framework instance available at the sender, using the SAP message(s). The configuration information, encoded in a suitable format as per Section 4.1, is carried in the payload of the SAP message(s). A receiver, acting as the SAP listener, listens on a well-known UDP port and at least one well-known multicast group IP address (as explained in Section 5.1.1). This enables the receiver to receive the SAP message(s) and obtain the FEC Framework Configuration Information for each FEC Framework instance.
在高层，发送方作为SAP播音员，使用SAP消息向发送方发送每个FEC框架实例的FEC框架配置信息。按照第4.1节以适当格式编码的配置信息载于SAP消息的有效载荷中。作为SAP侦听器的接收器侦听已知的UDP端口和至少一个已知的多播组IP地址（如第5.1.1节所述）。这使接收方能够接收SAP消息并获取每个FEC框架实例的FEC框架配置信息。
Using the configuration information, the receiver becomes aware of available FEC protection options, corresponding multicast trees (S,G or *,G addresses), etc. The receiver may subsequently subscribe to one or more multicast trees to receive the FEC streams using out-of-band multicasting techniques such as PIM [RFC4601]. This, however, is outside the scope of this document.
使用该配置信息，接收机意识到可用的FEC保护选项、相应的多播树（S、G或*、G地址）等。接收机随后可以订阅一个或多个多播树，以使用诸如PIM的带外多播技术来接收FEC流[RFC4601]。但是，这超出了本文件的范围。
Figure 2 below (reprinted from [RFC2974]) illustrates the SAP packet format.
下面的图2（从[RFC2974]转载）说明了SAP数据包格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |A|R|T|E|C| auth len | msg id hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: originating source (32 or 128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional authentication data |
: .... :
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| optional payload type |
+ +-+- - - - - - - - - -+
| |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ |
| |
: payload :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |A|R|T|E|C| auth len | msg id hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: originating source (32 or 128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional authentication data |
: .... :
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| optional payload type |
+ +-+- - - - - - - - - -+
| |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ |
| |
: payload :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. SAP Message Format
图2。SAP消息格式
While [RFC2974] includes explanations for each field, it is worth discussing the 'Payload' and 'Payload Type' fields. The 'Payload' field is used to carry the FEC Framework Configuration Information. Subsequently, the optional 'Payload Type' field, which is a MIME content type specifier, is used to describe the encoding format used to encode the payload.
虽然[RFC2974]包括对每个字段的解释，但值得讨论“有效载荷”和“有效载荷类型”字段。“有效载荷”字段用于携带FEC框架配置信息。随后，可选的“Payload Type”字段（MIME内容类型说明符）用于描述用于编码有效负载的编码格式。
For example, the 'Payload Type' field may be application/sdp if the FEC Framework Configuration Information is encoded in SDP format and carried in the SAP payload. Similarly, it would be application/xml if the FEC Framework Configuration Information were encoded in XML format.
例如，如果FEC框架配置信息以sdp格式编码并携带在SAP有效负载中，“有效负载类型”字段可以是应用程序/sdp。类似地，如果FEC框架配置信息以xml格式编码，那么它将是application/xml。
Section 5.1.1 describes the sender procedure, whereas Section 5.1.2 describes the receiver procedure in the context of config signaling using [RFC2974].
第5.1.1节描述了发送方程序，而第5.1.2节描述了使用[RFC2974]的配置信令上下文中的接收方程序。
The sender signals the FEC Framework Configuration Information for each FEC Framework instance in a periodic SAP announcement message [RFC2974]. The SAP announcement message is sent to a well-known multicast IP address and UDP port, as specified in [RFC2974]. The announcement is multicast with the same scope as the session being announced.
发送方在定期SAP公告消息[RFC2974]中向每个FEC框架实例发送FEC框架配置信息信号。SAP公告消息被发送到已知的多播IP地址和UDP端口，如[RFC2974]中所述。公告是多播的，其作用域与正在公告的会话相同。
The SAP module at the sender obtains the FEC Framework Configuration Information per instance from the 'FEC Framework' module and places that in the SAP payload accordingly. A single SAP (announcement) message must carry the FEC Framework Configuration Information for a single FEC Framework instance. The SAP message is then sent over UDP over IP.
发送方的SAP模块从“FEC Framework”模块获得每个实例的FEC Framework配置信息，并将其相应地放入SAP有效负载中。单个SAP（公告）消息必须包含单个FEC框架实例的FEC框架配置信息。然后，SAP消息通过IP上的UDP发送。
While it is possible to aggregate multiple SAP (announcement) messages in a single UDP datagram as long as the resulting UDP datagram length is less than the IP MTU of the outgoing interface, this specification does not recommend it, since there is no length field in the SAP header to identify a SAP message boundary. Hence, this specification recommends that a single SAP announcement message be sent in a UDP datagram.
虽然只要生成的UDP数据报长度小于传出接口的IP MTU，就可以在单个UDP数据报中聚合多个SAP（公告）消息，但本规范不建议这样做，因为SAP报头中没有用于标识SAP消息边界的长度字段。因此，本规范建议在UDP数据报中发送单个SAP公告消息。
The IP packet carrying the SAP message must be sent to a destination IP address of one of the following, depending on the selected scope:
承载SAP消息的IP数据包必须发送到以下地址之一的目标IP地址，具体取决于所选范围：
- 224.2.127.254 (if IPv4 global scope 224.0.1.0-238.255.255.255 is selected for the FEC stream), or
- 224.2.127.254（如果为FEC流选择了IPv4全局作用域224.0.1.0-238.255.255.255），或
- ff0x:0:0:0:0:0:2:7ffe (if IPv6 multicasting is selected for the FEC stream, where x is the 4-bit scope value), or
- ff0x:0:0:0:0:0:2:7ffe（如果为FEC流选择了IPv6多播，其中x是4位作用域值），或
- the highest multicast address (239.255.255.255, for example) in the relevant administrative scope zone (if IPv4 administrative scope 239.0.0.0-239.255.255.255 is selected for the FEC stream)
- 相关管理作用域区域中的最高多播地址（例如，239.255.255.255）（如果为FEC流选择了IPv4管理作用域239.0.0.0-239.255.255.255）
As defined in [RFC2974], the IP packet carrying a SAP message must use destination UDP port 9875 and a source UDP port of any available number. The default IP Time to Live (TTL) value (or Hop Limit value) should be 255 at the sender, though the sender implementation may allow it to be any other value to implicitly create the multicast boundary for SAP announcements. The IP Differentiated Services Code Point (DSCP) field may be set to any value that indicates a desired QoS treatment in the IP network.
如[RFC2974]中所定义，承载SAP消息的IP数据包必须使用目标UDP端口9875和任何可用号码的源UDP端口。发送方的默认IP生存时间（TTL）值（或跃点限制值）应为255，但发送方实现可能允许该值为任何其他值来隐式创建SAP公告的多播边界。IP区分服务代码点（DSCP）字段可设置为指示IP网络中所需QoS处理的任何值。
The IP packet carrying the SAP message must be sent with a source IP address that is reachable by the receiver. The sender may assign the same IP address in the 'originating source' field of the SAP message as that used in the source IP address of the IP packet.
承载SAP消息的IP数据包必须使用接收方可以访问的源IP地址发送。发送方可以在SAP消息的“始发源”字段中分配与IP数据包的源IP地址中使用的相同的IP地址。
Furthermore, the FEC Framework Configuration Information must not include any of the reserved multicast group IP addresses for the FEC streams (i.e., source or repair flows), though it may use the same IP address as the 'originating source' address to identify the FEC streams (i.e., source or repair flows). Please refer to IANA assignments for multicast addresses.
此外，FEC框架配置信息不得包括FEC流（即，源或修复流）的任何保留多播组IP地址，尽管它可以使用与“源”地址相同的IP地址来识别FEC流（即，源或修复流）。有关多播地址，请参阅IANA分配。
The sender must periodically send the 'SAP announcement' message to ensure that the receiver doesn't purge the cached entry or entries from the database and doesn't trigger the deletion of the FEC Framework Configuration Information.
发送方必须定期发送“SAP公告”消息，以确保接收方不会从数据库中清除缓存条目，也不会触发删除FEC框架配置信息。
While the time interval between repetitions of an announcement can be calculated as per the very sophisticated but complex method explained in [RFC2974], this document recommends a simpler method in which the user specifies the time interval in the range of 1-200 seconds, with a suggested default value of 60 seconds. In this method, the 'time interval' may be signaled in the SAP message payload, e.g., within the FEC Framework Configuration Information.
虽然可以按照[RFC2974]中解释的非常复杂但复杂的方法计算公告重复之间的时间间隔，但本文档推荐了一种更简单的方法，其中用户指定的时间间隔范围为1-200秒，建议默认值为60秒。在该方法中，“时间间隔”可在SAP消息有效载荷中发出信号，例如在FEC框架配置信息内。
Note that SAP doesn't allow the time interval to be signaled in the SAP header. Hence, the usage of a simpler method requires that the time interval be included in the FEC Framework Configuration Information if the default time interval (60 seconds) for SAP message repetitions is not used. For example, the usage of the 'r=' (repeat time) field in SDP may convey the time interval value if the SDP encoding format is used.
请注意，SAP不允许在SAP标头中显示时间间隔。因此，如果没有使用SAP消息重复的默认时间间隔（60秒），则使用更简单的方法需要在FEC框架配置信息中包括时间间隔。例如，如果使用SDP编码格式，则在SDP中使用“r=”（重复时间）字段可能会传递时间间隔值。
The time interval must be chosen to ensure that SAP announcement messages are sent out before the corresponding multicast routing entry, e.g., (S,G) or (*,G) (corresponding to the SAP multicast tree(s)) on the router(s) times out. (It is worth noting that the default timeout period for the multicast routing entry is 210 seconds, per the PIM specification [RFC4601], though the timeout period may be set to another value as allowed by the router implementation.)
必须选择时间间隔，以确保在路由器上相应的多播路由条目（例如，（S，g）或（*，g）（对应于SAP多播树））超时之前发送SAP公告消息。（值得注意的是，根据PIM规范[RFC4601]，多播路由条目的默认超时时间为210秒，尽管超时时间可以设置为路由器实现允许的另一个值。）
A SAP implementation may also support the complex method for determining the SAP announcement time interval and provide the option to select it.
SAP实施还可以支持确定SAP公告时间间隔的复杂方法，并提供选择该时间间隔的选项。
The sender may choose to delete the announced FEC Framework Configuration Information, as defined in Section 4 of [RFC2974]. The explicit deletion is useful if the sender no longer desires to send any more FEC streams.
发送方可以选择删除[RFC2974]第4节中定义的已公布的FEC框架配置信息。如果发送方不再希望发送更多FEC流，则显式删除非常有用。
If the sender needs to modify the announced FEC Framework Configuration Information for one or more FEC instances, then the sender must send a new announcement message with a different 'Message Identifier Hash' value as per the rules described in Section 5 of RFC 2974 [RFC2974]. Such an announcement message should be sent immediately (without having to wait for the time interval) to ensure that the modifications are received by the receiver as soon as possible. The sender must also send the SAP deletion message to delete the previous SAP announcement message (i.e., with the previous 'Message Identifier Hash' value).
如果发送方需要修改一个或多个FEC实例的已公告FEC框架配置信息，则发送方必须根据RFC 2974[RFC2974]第5节中描述的规则，发送具有不同“消息标识符哈希”值的新公告消息。应立即发送此类公告消息（无需等待时间间隔），以确保接收方尽快收到修改。发件人还必须发送SAP删除消息以删除以前的SAP公告消息（即，使用以前的“消息标识符哈希”值）。
The receiver must listen on UDP port 9875 for packets arriving with an IP destination address of either 224.2.127.254 (if an IPv4 global scope session is used for the FEC stream), ff0x:0:0:0:0:0:2:7ffe (if IPv6 is selected, where x is the 4-bit scope value), or the highest IP address (239.255.255.255, for example) in the relevant administrative scope zone (if IPv4 administrative scope 239.0.0.0- 239.255.255.255 is selected for the FEC stream). These IP addresses are mandated for SAP usage by RFC 2974 [RFC2974].
接收器必须在UDP端口9875上侦听IP目标地址为224.2.127.254（如果FEC流使用IPv4全局作用域会话）、ff0x:0:0:0:0:0:2:7ffe（如果选择了IPv6，其中x是4位作用域值）或最高IP地址（例如239.255.255.255）的数据包在相关管理范围区域中（如果为FEC流选择了IPv4管理范围239.0.0.0-239.255.255.255）。RFC 2974[RFC2974]强制要求SAP使用这些IP地址。
The receiver, upon receiving a SAP announcement message, creates an entry, if it doesn't already exist, in a local database and passes the FEC Framework Configuration Information from the SAP Payload field to the 'FEC Framework' module. Each entry also maintains a timeout value, which is (re)set to five times the time interval value, which in turn is either the default of 60 seconds or the value signaled by the sender.
接收方在收到SAP公告消息后，在本地数据库中创建一个条目（如果该条目不存在），并将FEC框架配置信息从SAP有效负载字段传递到“FEC框架”模块。每个条目还保留一个超时值，该值（重新）设置为时间间隔值的五倍，时间间隔值为默认值60秒或发送方发出信号的值。
Note that SAP doesn't allow the time interval to be signaled in the SAP header. Hence, the time interval should be included in the FEC Framework Configuration Information -- for example, the usage of the 'r=' (repeat time) field in SDP to convey the time interval value if the SDP encoding format is used.
请注意，SAP不允许在SAP标头中显示时间间隔。因此，时间间隔应该包含在FEC框架配置信息中——例如，如果使用SDP编码格式，则在SDP中使用“r=”（重复时间）字段来传递时间间隔值。
The timeout value associated with each entry is reset when the corresponding announcement (please see Section 5 of [RFC2974]) is received. If the timeout value for any entry reaches zero, then that entry must be deleted from the database, as described in Section 4 of [RFC2974]. The receiver, upon receiving a SAP delete message, must delete the matching SAP entry in its database, as described in Section 4 of [RFC2974].
当收到相应的公告（请参见[RFC2974]第5节）时，与每个条目相关的超时值将重置。如果任何条目的超时值达到零，则必须从数据库中删除该条目，如[RFC2974]第4节所述。接收方在收到SAP delete消息后，必须删除其数据库中匹配的SAP条目，如[RFC2974]第4节所述。
The deletion of a SAP entry must result in the receiver no longer using the relevant FEC Framework Configuration Information for the corresponding instance and no longer subscribing to any related FEC streams.
删除SAP条目必须导致接收方不再使用相应实例的相关FEC框架配置信息，也不再订阅任何相关FEC流。
This document describes leveraging any signaling protocol that is already used by the unicast application, for exchanging the FEC Framework Configuration Information between two nodes.
本文档描述了利用单播应用程序已经使用的任何信令协议在两个节点之间交换FEC框架配置信息。
For example, a multimedia (VoD) client may send a request via unicasting for a particular content to the multimedia (VoD) server, which may offer various options such as encodings, bitrates, transport, etc. for the content. The client selects the suitable options and answers the server, paving the way for the content to be unicast on the chosen transport from the server to the client. This offer/answer signaling, described in [RFC3264], is commonly utilized by many application protocols, such as SIP, RTSP, etc.
例如，多媒体（VoD）客户端可以通过单播将特定内容的请求发送到多媒体（VoD）服务器，该服务器可以为内容提供诸如编码、比特率、传输等各种选项。客户机选择合适的选项并回答服务器的问题，从而为内容在所选传输上从服务器单播到客户机铺平道路。[RFC3264]中描述的这种提供/应答信令通常被许多应用协议使用，如SIP、RTSP等。
The fact that two nodes desiring unicast communication almost always rely on an application to first exchange the application-related parameters via the signaling protocol makes it logical to enhance such signaling protocol(s) to (a) convey the desire for the FEC protection and (b) subsequently also exchange FEC parameters, i.e., the FEC Framework Configuration Information. This enables the node acting as the offerer to offer 'FEC Framework Configuration Information' for each available FEC instance and the node acting as the answerer to convey the chosen FEC Framework instance(s) to the offerer. The usage of the FEC Framework instance is explained in the FEC Framework document [RFC6363].
期望单播通信的两个节点几乎总是依赖于应用来首先经由信令协议交换与应用相关的参数这一事实使得增强这样的信令协议是合乎逻辑的：（a）传达对FEC保护的期望，并且（b）随后也交换FEC参数，即。，FEC框架配置信息。这使得作为发盘方的节点能够为每个可用的FEC实例提供“FEC框架配置信息”，并且作为应答方的节点能够将所选择的FEC框架实例传递给发盘方。FEC框架文档[RFC6363]解释了FEC框架实例的用法。
While enhancing an application's signaling protocol to exchange FEC parameters is one method (briefly explained above), an alternative method would be to have a unicast-based generic protocol that could be used by two nodes, independent of the application's signaling protocol. The latter is not covered by this document, of course.
虽然增强应用程序的信令协议以交换FEC参数是一种方法（上文简要解释），但另一种方法是具有可由两个节点使用的基于单播的通用协议，独立于应用程序的信令协议。当然，本文件不涉及后者。
The remainder of this section provides example signaling protocols and explains how they can be used to exchange the FEC Framework Configuration Information.
本节的其余部分提供了示例信令协议，并解释了如何使用它们来交换FEC框架配置信息。
SIP [RFC3261] is an application-level signaling protocol to create, modify, and terminate multimedia sessions with one or more participants. SIP also enables the participants to discover one another and to agree on a characterization of a multimedia session
SIP[RFC3261]是一种应用级信令协议，用于创建、修改和终止与一个或多个参与者的多媒体会话。SIP还使参与者能够相互发现，并就多媒体会话的特征达成一致
they would like to share. SIP runs on either TCP, UDP, or Stream Control Transmission Protocol (SCTP) transport and uses SDP as the encoding format to describe multimedia session attributes.
他们想分享。SIP在TCP、UDP或流控制传输协议（SCTP）传输上运行，并使用SDP作为编码格式来描述多媒体会话属性。
SIP already uses an offer/answer model with SDP as described in [RFC3264] to exchange information between two nodes to establish unicast sessions between them. This document extends the usage of this model for exchanging the FEC Framework Configuration Information (described in Section 4). Any SDP-specific enhancements to accommodate the FEC Framework are covered in the SDP elements specification [RFC6364].
SIP已经使用[RFC3264]中描述的SDP提供/应答模型在两个节点之间交换信息，以在它们之间建立单播会话。本文档扩展了该模型用于交换FEC框架配置信息的用途（如第4节所述）。SDP元素规范[RFC6364]中涵盖了适应FEC框架的任何SDP特定增强。
RTSP [RFC2326] is an application-level signaling protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data such as audio and video. RTSP runs on either TCP or UDP transports.
RTSP[RFC2326]是一种应用级信令协议，用于控制具有实时属性的数据传输。RTSP提供了一个可扩展的框架，以支持音频和视频等实时数据的受控按需交付。RTSP在TCP或UDP传输上运行。
RTSP already provides an ability to extend the existing method with new parameters. This specification defines the 'FEC-protection-needed' option tag (please see Section 7 for IANA Considerations) and prescribes including it in the Require (or Proxy-Require) header of SETUP (method) request messages, so as to request FEC protection for the data.
RTSP已经提供了使用新参数扩展现有方法的能力。本规范定义了“需要FEC保护”选项标签（请参见第7节了解IANA注意事项），并规定将其包含在设置（方法）请求消息的Require（或Proxy Require）头中，以便请求数据的FEC保护。
The node receiving such a request either responds with a '200 OK' message that includes offers, i.e., available FEC options (e.g., FEC Framework Configuration Information for each instance) or a '551 Option not supported' message. A sample of a related message exchange is shown below.
接收到这样一个请求的节点要么响应一个“200OK”消息，该消息包括提供，即可用的FEC选项（例如，每个实例的FEC框架配置信息），要么响应一个“551选项不受支持”消息。下面显示了相关消息交换的示例。
Node1->Node2: SETUP < ... > RTSP/1.0
CSeq: 1
Transport: <omitted for simplicity>
Require: FEC-protection-needed
Node1->Node2: SETUP < ... > RTSP/1.0
CSeq: 1
Transport: <omitted for simplicity>
Require: FEC-protection-needed
Node2->Node1: RTSP/1.0 200 OK
CSeq: 1
Transport: <omitted for simplicity>
Node2->Node1: RTSP/1.0 200 OK
CSeq: 1
Transport: <omitted for simplicity>
The requesting node (Node1) may then send a new SETUP message to convey the selected FEC protection to Node2 and proceed with regular RTSP messaging.
请求节点（Node1）随后可发送新的设置消息以将所选FEC保护传送给Node2并继续进行常规RTSP消息传送。
Suffice it to say that if the requesting node (Node1) received a '551 Option not supported' response from Node2, then the requesting node (Node1) may send the SETUP message without using the Require header.
只需说明，如果请求节点（Node1）从Node2接收到“551 Option not supported”响应，则请求节点（Node1）可以在不使用Require报头的情况下发送设置消息。
This document recommends that SAP message(s) be authenticated to ensure sender authentication, as described in Section 5.1.
本文档建议对SAP邮件进行身份验证，以确保发件人身份验证，如第5.1节所述。
There are no additional security considerations other than those already covered in [RFC2974] for SAP, [RFC2326] for RTSP, and [RFC3261] for SIP.
除了SAP的[RFC2974]、RTSP的[RFC2326]和SIP的[RFC3261]中已经介绍的安全注意事项外，没有其他安全注意事项。
IANA has registered a new RTSP option tag (option-tag), listed below, in the RTSP/1.0 Option Tags table of the "Real Time Streaming Protocol (RTSP)/1.0 Parameters" registry available from http://www.iana.org/, and it provides the following information in compliance with Section 3.8.1 of [RFC2326]:
IANA已在“实时流协议（RTSP）/1.0参数”注册表的RTSP/1.0选项标签表中注册了一个新的RTSP选项标签（选项标签），如下所示，可从http://www.iana.org/，并根据[RFC2326]第3.8.1节提供以下信息：
o Name of option-tag: FEC-protection-needed
o 选项标签名称：需要FEC保护
o Description: See Section 5.2.2
o 说明：见第5.2.2节
o Change Control: IETF
o 变更控制：IETF
Thanks to Colin Perkins for pointing out the issue with the time interval for the SAP messages. Additionally, thanks to Vincent Roca, Ali Begen, Mark Watson, Ulas Kozat, and David Harrington for greatly improving this document.
感谢Colin Perkins指出SAP消息的时间间隔问题。此外，感谢Vincent Roca、Ali Begen、Mark Watson、Ulas Kozat和David Harrington大大改进了本文档。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6363]Watson，M.，Begen，A.，和V.Roca，“前向纠错（FEC）框架”，RFC6363，2011年10月。
[RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, October 2011.
[RFC6364]Begen，A.，“前向纠错（FEC）框架的会话描述协议元素”，RFC6364，2011年10月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
Author's Address
作者地址
Rajiv Asati Cisco Systems 7025-6 Kit Creek Rd. RTP, NC 27709-4987
Rajiv Asati Cisco Systems 7025-6 Kit Creek路RTP，北卡罗来纳州27709-4987
EMail: rajiva@cisco.com
EMail: rajiva@cisco.com