Internet Engineering Task Force (IETF) F. Le Faucheur
Request for Comments: 7256 R. Maglione
Updates: 6320 Cisco
Category: Standards Track T. Taylor
ISSN: 2070-1721 Huawei
July 2014
Internet Engineering Task Force (IETF) F. Le Faucheur
Request for Comments: 7256 R. Maglione
Updates: 6320 Cisco
Category: Standards Track T. Taylor
ISSN: 2070-1721 Huawei
July 2014
Multicast Control Extensions for the Access Node Control Protocol (ANCP)
访问节点控制协议（ANCP）的多播控制扩展
Abstract
摘要
This document specifies the extensions to the Access Node Control Protocol (ANCP) (RFC 6320) required for support of the multicast use cases defined in the Access Node Control Protocol framework document (RFC 5851) and one additional use case described in this document. These use cases are organized into the following ANCP capabilities:
本文件规定了支持访问节点控制协议框架文件（RFC 5851）中定义的多播用例所需的访问节点控制协议（ANCP）（RFC 6320）扩展以及本文件中描述的一个附加用例。这些用例被组织为以下ANCP功能：
o multicast replication initiated by the Network Access Server (NAS);
o 由网络访问服务器（NAS）发起的多播复制；
o conditional access and admission control with white and black lists;
o 具有白名单和黑名单的条件接收和接纳控制；
o conditional access and admission control with grey lists;
o 具有灰色列表的条件接收和接纳控制；
o bandwidth delegation; and
o 带宽授权；和
o committed bandwidth reporting.
o 承诺带宽报告。
These capabilities may be combined according to the rules given in this specification.
这些功能可以根据本规范中给出的规则进行组合。
This document updates RFC 6320 by assigning capability type 3 to a capability specified in this document and by changing the starting point for IANA allocation of result codes determined by IETF Consensus from 0x100 to 0x64.
本文档通过将能力类型3分配给本文档中指定的能力，并将IETF共识确定的结果代码的IANA分配起点从0x100更改为0x64，来更新RFC 6320。
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. 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/rfc7256.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7256.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 ....................................................5
1.1. A Note on Scope ............................................7
2. Terminology .....................................................7
3. Multicast Use Cases .............................................7
3.1. NAS-Initiated Multicast Replication Control Use Case .......8
3.1.1. Goals ...............................................8
3.1.2. Message Flow ........................................9
3.2. Conditional Access and Admission Control Use Case ..........9
3.2.1. Goals ...............................................9
3.2.2. Message Flow .......................................10
3.3. Multicast Flow Reporting Use Case .........................11
3.3.1. Goals ..............................................11
3.3.2. Message Flow .......................................11
3.4. Committed Bandwidth Reporting Use Case ....................11
3.4.1. Goals ..............................................11
3.4.2. Message Flow .......................................12
4. ANCP Messages ..................................................13
4.1. Provisioning Message ......................................13
1. Introduction ....................................................5
1.1. A Note on Scope ............................................7
2. Terminology .....................................................7
3. Multicast Use Cases .............................................7
3.1. NAS-Initiated Multicast Replication Control Use Case .......8
3.1.1. Goals ...............................................8
3.1.2. Message Flow ........................................9
3.2. Conditional Access and Admission Control Use Case ..........9
3.2.1. Goals ...............................................9
3.2.2. Message Flow .......................................10
3.3. Multicast Flow Reporting Use Case .........................11
3.3.1. Goals ..............................................11
3.3.2. Message Flow .......................................11
3.4. Committed Bandwidth Reporting Use Case ....................11
3.4.1. Goals ..............................................11
3.4.2. Message Flow .......................................12
4. ANCP Messages ..................................................13
4.1. Provisioning Message ......................................13
4.1.1. Sender Behavior ....................................14
4.1.2. Receiver Behavior ..................................14
4.2. Port Management Message ...................................15
4.2.1. Sender Behavior ....................................16
4.2.2. Receiver Behavior ..................................16
4.3. Multicast Replication Control Message .....................17
4.3.1. Sender Behavior ....................................21
4.3.2. Receiver Behavior ..................................21
4.4. Multicast Admission Control Message .......................24
4.4.1. Sender Behavior ....................................25
4.4.2. Receiver Behavior ..................................26
4.5. Bandwidth Reallocation Request Message ....................27
4.5.1. Sender Behavior ....................................28
4.5.2. Receiver Behavior ..................................28
4.6. Bandwidth Transfer Message ................................31
4.6.1. Sender Behavior ....................................32
4.6.2. Receiver Behavior ..................................32
4.7. Delegated Bandwidth Query Request Message .................34
4.7.1. Sender Behavior ....................................34
4.7.2. Receiver Behavior ..................................34
4.8. Delegated Bandwidth Query Response Message ................34
4.8.1. Sender Behavior ....................................35
4.8.2. Receiver Behavior ..................................35
4.9. Multicast Flow Query Request and Response Messages ........36
4.9.1. Sender Behavior ....................................36
4.9.2. Receiver Behavior ..................................37
4.10. Committed Bandwidth Report Message .......................38
4.10.1. Sender Behavior ...................................38
4.10.2. Receiver Behavior .................................39
5. ANCP TLVs For Multicast ........................................39
5.1. Multicast-Service-Profile TLV .............................39
5.2. Multicast-Service-Profile-Name TLV ........................41
5.3. List-Action TLV ...........................................41
5.4. Sequence-Number TLV .......................................44
5.5. Bandwidth-Allocation TLV ..................................45
5.6. White-List-CAC TLV ........................................45
5.7. MRepCtl-CAC TLV ...........................................46
5.8. Bandwidth-Request TLV .....................................46
5.9. Request-Source-IP TLV .....................................47
5.10. Request-Source-MAC TLV ...................................48
5.11. Request-Source-Device-Id TLV .............................48
5.12. Multicast-Flow TLV .......................................49
5.13. Report-Buffering-Time TLV ................................50
5.14. Committed-Bandwidth TLV ..................................51
6. Multicast Capabilities .........................................51
6.1. Required Protocol Support .................................52
6.1.1. Protocol Requirements for NAS-Initiated
Multicast Replication ..............................52
4.1.1. Sender Behavior ....................................14
4.1.2. Receiver Behavior ..................................14
4.2. Port Management Message ...................................15
4.2.1. Sender Behavior ....................................16
4.2.2. Receiver Behavior ..................................16
4.3. Multicast Replication Control Message .....................17
4.3.1. Sender Behavior ....................................21
4.3.2. Receiver Behavior ..................................21
4.4. Multicast Admission Control Message .......................24
4.4.1. Sender Behavior ....................................25
4.4.2. Receiver Behavior ..................................26
4.5. Bandwidth Reallocation Request Message ....................27
4.5.1. Sender Behavior ....................................28
4.5.2. Receiver Behavior ..................................28
4.6. Bandwidth Transfer Message ................................31
4.6.1. Sender Behavior ....................................32
4.6.2. Receiver Behavior ..................................32
4.7. Delegated Bandwidth Query Request Message .................34
4.7.1. Sender Behavior ....................................34
4.7.2. Receiver Behavior ..................................34
4.8. Delegated Bandwidth Query Response Message ................34
4.8.1. Sender Behavior ....................................35
4.8.2. Receiver Behavior ..................................35
4.9. Multicast Flow Query Request and Response Messages ........36
4.9.1. Sender Behavior ....................................36
4.9.2. Receiver Behavior ..................................37
4.10. Committed Bandwidth Report Message .......................38
4.10.1. Sender Behavior ...................................38
4.10.2. Receiver Behavior .................................39
5. ANCP TLVs For Multicast ........................................39
5.1. Multicast-Service-Profile TLV .............................39
5.2. Multicast-Service-Profile-Name TLV ........................41
5.3. List-Action TLV ...........................................41
5.4. Sequence-Number TLV .......................................44
5.5. Bandwidth-Allocation TLV ..................................45
5.6. White-List-CAC TLV ........................................45
5.7. MRepCtl-CAC TLV ...........................................46
5.8. Bandwidth-Request TLV .....................................46
5.9. Request-Source-IP TLV .....................................47
5.10. Request-Source-MAC TLV ...................................48
5.11. Request-Source-Device-Id TLV .............................48
5.12. Multicast-Flow TLV .......................................49
5.13. Report-Buffering-Time TLV ................................50
5.14. Committed-Bandwidth TLV ..................................51
6. Multicast Capabilities .........................................51
6.1. Required Protocol Support .................................52
6.1.1. Protocol Requirements for NAS-Initiated
Multicast Replication ..............................52
6.1.2. Protocol Requirements for Committed
Multicast Bandwidth Reporting ......................54
6.1.3. Protocol Requirements for Conditional
Access and Admission Control with White
and Black Lists ....................................55
6.1.4. Protocol Requirements for Conditional
Access and Admission Control with Grey Lists .......56
6.1.5. Protocol Requirements for Bandwidth Delegation .....57
6.2. Capability-Specific Procedures for Providing
Multicast Service .........................................57
6.2.1. Procedures for NAS-Initiated Multicast
Replication ........................................58
6.2.2. Procedures for Committed Bandwidth Reporting .......58
6.2.3. Procedures for Conditional Access and
Admission Control with Black and White Lists .......59
6.2.4. Procedures for Conditional Access and
Admission Control with Grey Lists ..................61
6.2.5. Procedures for Bandwidth Delegation ................63
6.3. Combinations of Multicast Capabilities ....................64
6.3.1. Combination of Conditional Access and
Admission Control with White and Black Lists
and Conditional Access and Admission Control
with Grey Lists ....................................64
6.3.2. Combination of Conditional Access and
Admission Control with Bandwidth Delegation ........65
6.3.3. Combination of NAS-Initiated Replication
with Other Capabilities ............................65
6.3.4. Combinations of Committed Bandwidth
Reporting with Other Multicast Capabilities ........66
7. Miscellaneous Considerations ...................................66
7.1. Report Buffering Considerations ...........................66
7.2. Congestion Considerations .................................67
8. Security Considerations ........................................67
9. IANA Considerations ............................................69
10. Acknowledgements ..............................................72
11. References ....................................................73
11.1. Normative References .....................................73
11.2. Informative References ...................................73
Appendix A. Example of Messages and Message Flows ................75
A.1. Provisioning Phase ........................................75
A.2. Handling Grey-Listed Flows ................................81
A.3. Handling White-Listed Flows ...............................87
A.4. Handling of Black-Listed Join Requests ....................92
A.5. Handling of Requests to Join and Leave the On-Line Game ...92
A.6. Example Flow for Multicast Flow Reporting .................95
6.1.2. Protocol Requirements for Committed
Multicast Bandwidth Reporting ......................54
6.1.3. Protocol Requirements for Conditional
Access and Admission Control with White
and Black Lists ....................................55
6.1.4. Protocol Requirements for Conditional
Access and Admission Control with Grey Lists .......56
6.1.5. Protocol Requirements for Bandwidth Delegation .....57
6.2. Capability-Specific Procedures for Providing
Multicast Service .........................................57
6.2.1. Procedures for NAS-Initiated Multicast
Replication ........................................58
6.2.2. Procedures for Committed Bandwidth Reporting .......58
6.2.3. Procedures for Conditional Access and
Admission Control with Black and White Lists .......59
6.2.4. Procedures for Conditional Access and
Admission Control with Grey Lists ..................61
6.2.5. Procedures for Bandwidth Delegation ................63
6.3. Combinations of Multicast Capabilities ....................64
6.3.1. Combination of Conditional Access and
Admission Control with White and Black Lists
and Conditional Access and Admission Control
with Grey Lists ....................................64
6.3.2. Combination of Conditional Access and
Admission Control with Bandwidth Delegation ........65
6.3.3. Combination of NAS-Initiated Replication
with Other Capabilities ............................65
6.3.4. Combinations of Committed Bandwidth
Reporting with Other Multicast Capabilities ........66
7. Miscellaneous Considerations ...................................66
7.1. Report Buffering Considerations ...........................66
7.2. Congestion Considerations .................................67
8. Security Considerations ........................................67
9. IANA Considerations ............................................69
10. Acknowledgements ..............................................72
11. References ....................................................73
11.1. Normative References .....................................73
11.2. Informative References ...................................73
Appendix A. Example of Messages and Message Flows ................75
A.1. Provisioning Phase ........................................75
A.2. Handling Grey-Listed Flows ................................81
A.3. Handling White-Listed Flows ...............................87
A.4. Handling of Black-Listed Join Requests ....................92
A.5. Handling of Requests to Join and Leave the On-Line Game ...92
A.6. Example Flow for Multicast Flow Reporting .................95
[RFC5851] defines a framework and requirements for an Access Node (AN) control mechanism between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations. [RFC6320] specifies a protocol for Access Node Control in broadband networks in line with this framework.
[RFC5851]定义了多业务参考体系结构中网络接入服务器（NAS）和接入节点（例如，数字用户线接入多路复用器（DSLAM））之间的接入节点（an）控制机制的框架和要求，以便执行QoS相关、服务相关和用户相关的操作。[RFC6320]根据该框架规定了宽带网络中接入节点控制的协议。
[RFC6320] supports, specifically for DSL access, three use cases defined in [RFC5851]: the Topology Discovery use case, the Line Configuration use case, and the Remote Connectivity Test use case. However, it does not support the multicast use cases defined in [RFC5851]. The present document specifies the extensions to the Access Node Control Protocol required for support of these multicast use cases. In addition, it supports the Committed Bandwidth Reporting use case, described below. In terms of ANCP, these use cases are organized into five capabilities:
[RFC6320]特别支持DSL访问[RFC5851]中定义的三个用例：拓扑发现用例、线路配置用例和远程连接测试用例。但是，它不支持[RFC5851]中定义的多播用例。本文档指定了支持这些多播用例所需的访问节点控制协议的扩展。此外，它还支持下面描述的提交带宽报告用例。就ANCP而言，这些用例被组织为五种能力：
o NAS-initiated multicast replication;
o NAS发起的多播复制；
o conditional access and admission control with white and black lists;
o 具有白名单和黑名单的条件接收和接纳控制；
o conditional access and admission control with grey lists;
o 具有灰色列表的条件接收和接纳控制；
o bandwidth delegation; and
o 带宽授权；和
o committed bandwidth reporting.
o 承诺带宽报告。
NAS-initiated multicast replication assumes that multicast join and leave requests are terminated on the NAS or that the NAS receives requests to establish multicast sessions through other means (e.g., application-level signaling). The NAS sends commands to the AN to start or stop replication of specific multicast flows on specific subscriber ports. This use case is described briefly in the next-to-last paragraph of Section 3.4 of [RFC5851].
NAS启动的多播复制假定多播加入和离开请求在NAS上终止，或者NAS通过其他方式（例如，应用程序级信令）接收建立多播会话的请求。NAS向AN发送命令，以启动或停止特定订户端口上特定多播流的复制。[RFC5851]第3.4节的下一段最后一段简要描述了该用例。
Conditional access is described in Section 3.4.1 of [RFC5851]. Section 3.4.2.2 of [RFC5851] mentions a way in which conditional access can be combined with admission control to allow best-effort multicast flows, and Section 3.4.2.3 points out the necessary conditions for using both conditional access and admission control.
[RFC5851]第3.4.1节描述了条件接收。[RFC5851]的第3.4.2.2节提到了条件接收与准入控制相结合的方式，以允许尽力而为的多播流，第3.4.2.3节指出了同时使用条件接收和准入控制的必要条件。
In the case of "conditional access and admission control with white and black lists", multicast join and leave requests are terminated at the AN and accepted or ignored in accordance with the direction
在“具有白名单和黑名单的条件接收和接纳控制”的情况下，多播加入和离开请求在AN处终止，并根据指示接受或忽略
provided by white and black lists, respectively. The white and black lists are provisioned per port at startup time and may be modified thereafter. The NAS may combine conditional access with admission control of white-listed flows by appropriate provisioning.
分别由白名单和黑名单提供。白名单和黑名单在启动时按端口设置，并可在启动后进行修改。NAS可以通过适当的配置将条件接收与白名单流的准入控制相结合。
Conditional access and admission control with grey lists is similar to conditional access and admission control with white lists, except that before accepting any request matching a grey list entry, the AN sends a request to the NAS for permission to replicate the flow. Again, the NAS can enable admission control of grey-listed flows at the AN.
带有灰色列表的条件接收和接纳控制类似于带有白色列表的条件接收和接纳控制，不同的是，在接受任何与灰色列表条目匹配的请求之前，AN向NAS发送请求，以获得复制流的权限。同样，NAS可以在AN启用灰色列表流的准入控制。
Bandwidth delegation is described in Section 3.4.2.1 of [RFC5851]. It allows flexible sharing of total video bandwidth on an access line between the AN and the NAS. One application of such bandwidth sharing is where the AN does multicast admission control, while the NAS or Policy Server does unicast admission control. In that case, bandwidth delegation allows dynamic sharing of bandwidth between unicast and multicast video traffic on each access line.
[RFC5851]第3.4.2.1节描述了带宽授权。它允许在an和NAS之间的接入线上灵活共享总视频带宽。这种带宽共享的一个应用是AN进行多播许可控制，而NAS或策略服务器进行单播许可控制。在这种情况下，带宽委派允许在每条接入线上的单播和多播视频流量之间动态共享带宽。
Committed bandwidth reporting is described in Section 3.4. The AN reports the amount of multicast bandwidth it has granted to a given access line each time that value changes. These reports may be buffered for a NAS-provisionable interval so that reports for multiple access lines can be bundled into the same message.
第3.4节描述了提交的带宽报告。AN在每次该值更改时报告其授予给定访问线的多播带宽量。这些报告可以缓冲一段NAS可配置的时间间隔，以便多条接入线的报告可以捆绑到同一条消息中。
The formal specification of the behaviors associated with each of these capabilities, singly and in combination, is given in Section 6.
第6节给出了与这些能力中的每一项相关的行为的正式规范（单独或组合）。
In addition to the multicast service processing behavior just sketched, the definition of each capability includes support for the multicast accounting and reporting services described in Section 3.4.3 of [RFC5851]. Because of this common content and because of other protocol overlaps between the different capabilities, the protocol descriptions for the multicast extensions specified in this document are merged into a single non-redundant narrative. Tables in Section 6 then indicate the specific sub-sections of the protocol description that have to be implemented to support each capability.
除了刚才概述的多播服务处理行为外，每个功能的定义还包括对[RFC5851]第3.4.3节中描述的多播记帐和报告服务的支持。由于此公共内容以及不同功能之间的其他协议重叠，本文档中指定的多播扩展的协议描述合并为一个非冗余叙述。第6节中的表格指出了协议描述中必须实施以支持每种能力的特定小节。
This document updates RFC 6320 by assigning capability type 3 to the NAS-initiated multicast replication capability and by changing the starting point for IANA allocation of result codes determined by IETF Consensus from 0x100 to 0x64.
本文档通过将能力类型3分配给NAS启动的多播复制能力，并通过将IETF共识确定的结果代码的IANA分配起点从0x100更改为0x64，来更新RFC 6320。
The requirements in [RFC5851] were formulated with the IPTV application in mind. Two basic assumptions underlie the use case descriptions:
[RFC5851]中的要求是在考虑IPTV应用的情况下制定的。用例描述有两个基本假设：
o that the Home Gateway operates in bridged mode, and
o 家庭网关以桥接模式运行，以及
o that multicast signaling uses IGMP ([RFC2236] [RFC3376]) or Multicast Listener Discovery (MLD) [RFC3810] rather than PIM [RFC4601].
o 该多播信令使用IGMP（[RFC2236][RFC3376]）或多播侦听器发现（MLD）[RFC3810]而不是PIM[RFC4601]。
Without the first assumption the AN may lose sight of individual subscriber devices making requests for multicast service. This has a very minor effect on the capabilities described below but prevents the application of per-device policies at the NAS. Changing the second assumption would require that, in applications where the AN is responsible for snooping IGMP and MLD, it now also monitors for PIM signaling. The capabilities described in the present document do not depend explicitly on what type of multicast signaling is used, but the multiple phases of PIM setup could add complexity to their implementation.
如果没有第一个假设，AN可能会忽略单个订户设备对多播服务的请求。这对下面描述的功能影响很小，但会阻止在NAS上应用每设备策略。改变第二个假设要求，在AN负责监听IGMP和MLD的应用中，它现在还监视PIM信令。本文档中描述的功能并不明确取决于所使用的多播信令的类型，但PIM设置的多个阶段可能会增加其实现的复杂性。
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 uses the terms "connection admission control" ("CAC" or simply "admission control") and "conditional access" as they are used in [RFC5851].
本文件使用了[RFC5851]中使用的术语“连接许可控制”（“CAC”或简称“许可控制”）和“条件接收”。
The expression "delegated bandwidth" is used as a shorter way of saying: "the total amount of video bandwidth delegated to the AN for multicast admission control".
表达式“委派带宽”用作表示“委派给AN用于多播许可控制的视频带宽总量”的较短方式。
Quoting from [RFC5851]:
引用自[RFC5851]：
... the Access Node, aggregation node(s), and the NAS must all be involved in the multicast replication process. This prevents several copies of the same stream from being sent within the access/aggregation network. In case of an Ethernet-based access/ aggregation network, this may, for example, be achieved by means of IGMP snooping or IGMP proxy in the Access Node and aggregation node(s).
... 访问节点、聚合节点和NAS都必须参与多播复制过程。这将防止在访问/聚合网络中发送同一流的多个副本。在基于以太网的接入/聚合网络的情况下，这可以例如通过接入节点和聚合节点中的IGMP窥探或IGMP代理来实现。
By introducing IGMP processing in the access/aggregation nodes, the multicast replication process is now divided between the NAS, the aggregation node(s), and Access Nodes. In order to ensure backward compatibility with the ATM-based model, the NAS, aggregation node, and Access Node need to behave as a single logical device. This logical device must have exactly the same functionality as the NAS in the ATM access/aggregation network. The Access Node Control Mechanism can be used to make sure that this logical/functional equivalence is achieved by exchanging the necessary information between the Access Node and the NAS.
通过在访问/聚合节点中引入IGMP处理，现在可以在NAS、聚合节点和访问节点之间划分多播复制过程。为了确保与基于ATM的模型向后兼容，NAS、聚合节点和访问节点需要作为单个逻辑设备。此逻辑设备必须与ATM访问/聚合网络中的NAS具有完全相同的功能。访问节点控制机制可用于确保通过在访问节点和NAS之间交换必要的信息来实现这种逻辑/功能等效。
[RFC5851] describes the use cases for ANCP associated with such multicast operations and identifies the associated ANCP requirements. This section describes a subset of these use cases as background to facilitate reading of this document, but the reader is referred to [RFC5851] for a more exhaustive description of the ANCP multicast use cases. Detailed example message flows can also be found in Appendix A.
[RFC5851]描述了与此类多播操作相关的ANCP用例，并确定了相关的ANCP要求。本节将这些用例的子集描述为背景，以便于阅读本文档，但读者可参考[RFC5851]了解ANCP多播用例的更详尽描述。附录A中还提供了详细的消息流示例。
In the diagrams below, participation of the Home Gateway is optional, depending on whether it is operating in bridged or routed mode. Note that devices behind the Home Gateway may require the Home Gateway to operate in routed mode to ensure that they can obtain access to non-IPTV multicast services.
在下图中，家庭网关的参与是可选的，这取决于它是以桥接模式还是路由模式运行。注意，家庭网关后面的设备可能要求家庭网关在路由模式下运行，以确保它们能够访问非IPTV多播服务。
One option for multicast handling is for the subscriber to communicate the join/leave information to the NAS. This can be done, for instance, by terminating all subscriber IGMP ([RFC3376]) or MLD ([RFC2710] [RFC3810]) signaling on the NAS. Another example could be a subscriber using some form of application-level signaling, which is redirected to the NAS. In any case, this option is transparent to the access and aggregation network. In this scenario, the NAS uses ANCP to create and remove replication state in the AN for efficient multicast replication. Thus, the NAS only sends a single copy of the multicast stream towards the AN, which, in turn, performs replication to multiple subscribers as instructed by the NAS via ANCP. The NAS performs conditional access and admission control when processing multicast join requests and only creates replication state in the AN if admission succeeds.
多播处理的一个选项是订户将加入/离开信息传送到NAS。例如，可以通过终止NAS上的所有订户IGMP（[RFC3376]）或MLD（[RFC2710][RFC3810]）信令来实现这一点。另一个示例是使用某种形式的应用程序级信令的订户，该信令被重定向到NAS。在任何情况下，此选项对访问和聚合网络都是透明的。在此场景中，NAS使用ANCP在AN中创建和删除复制状态，以实现高效的多播复制。因此，NAS仅向AN发送多播流的单个副本，而AN又按照NAS经由ANCP的指示执行到多个订户的复制。NAS在处理多播加入请求时执行条件访问和接纳控制，并且仅在接纳成功时在AN中创建复制状态。
With the NAS-initiated use case, a Multicast Replication Control message is sent by the NAS to the AN with a directive to either join or leave one (or more) multicast flow(s). In the example message flow, the AN uses a Generic Response message to convey the outcome of the directive. Figure 1 illustrates such an ANCP message exchange as well as the associated AN behavior.
在NAS启动的用例中，NAS向AN发送一条多播复制控制消息，其中包含加入或离开一个（或多个）多播流的指令。在示例消息流中，AN使用通用响应消息来传递指令的结果。图1说明了这样一个ANCP消息交换以及相关的行为。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<-------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | (*)
| | | Multicast-Replication-Ctl |
| | | (Target, add, Flow 1) |
| | |<--------------------------|
| Mcast Flow 1 | |
|<===========+==============+ |
| | | Generic Response |
| | |-------------------------->|
| | | |
| | | |
~ ~ ~ ~
| | | |
| | | Multicast-Replication-Ctl |
| | | (Target,delete, Flow 1) |
| | |<--------------------------|
| | | |
| <Stop Replication of X |
| Mcast Flow 1> | Generic Response |
| | |-------------------------->|
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<-------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | (*)
| | | Multicast-Replication-Ctl |
| | | (Target, add, Flow 1) |
| | |<--------------------------|
| Mcast Flow 1 | |
|<===========+==============+ |
| | | Generic Response |
| | |-------------------------->|
| | | |
| | | |
~ ~ ~ ~
| | | |
| | | Multicast-Replication-Ctl |
| | | (Target,delete, Flow 1) |
| | |<--------------------------|
| | | |
| <Stop Replication of X |
| Mcast Flow 1> | Generic Response |
| | |-------------------------->|
(*) The NAS may optionally seek direction from an external Authorization/Policy Server before admitting the flow.
（*）NAS可以选择在允许流量之前从外部授权/策略服务器寻求方向。
Figure 1: NAS-Initiated Multicast Replication Control
图1:NAS启动的多播复制控制
One option for multicast handling is for the access/aggregation nodes to participate in IGMP/MLD processing (e.g., via IGMP/MLD snooping). In this scenario, on detecting a join/leave request from an end user for a multicast flow (in the grey list), the AN uses ANCP to request a conditional access and admission control decision from the NAS. In turn, after conditional access and admission control checks, the NAS
多播处理的一个选项是访问/聚合节点参与IGMP/MLD处理（例如，通过IGMP/MLD窥探）。在该场景中，当检测到来自最终用户的多播流（在灰色列表中）的加入/离开请求时，an使用ANCP从NAS请求条件接入和接纳控制决策。反过来，在条件接收和准入控制检查之后，NAS
uses ANCP to instruct the AN to change the replication states accordingly.
使用ANCP指示AN相应地更改复制状态。
For support of the conditional access and admission control use case, on detection of an IGMP/MLD join request, the AN sends a Multicast Admission Control message to the NAS to request a conditional access and admission control check. In the case of a positive outcome, the NAS sends a Multicast Replication Control message to the AN with a directive to replicate the multicast flow to the corresponding user. Similarly, on detection of an IGMP/MLD leave, a Multicast Admission Control message is sent by the AN to the NAS to keep the NAS aware of user departure for the flow. This message flow is illustrated in Figure 2.
为了支持条件接收和接纳控制用例，在检测到IGMP/MLD加入请求时，an向NAS发送多播接纳控制消息以请求条件接收和接纳控制检查。在肯定结果的情况下，NAS向AN发送多播复制控制消息，并指示将多播流复制到相应的用户。类似地，在检测到IGMP/MLD离开时，an向NAS发送多播接纳控制消息，以使NAS知道用户离开流。该消息流如图2所示。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(Gr-Flow1) | Multicast-Admission-Crl |
|------------+---------->| (Target,add,Gr-Flow1) |
| | |-------------------------->|
| | | (*)
| | | Multicast-Replication-Crl |
| | | (Target,add,Gr-Flow1) |
| | |<--------------------------|
| Mcast Gr-Flow1 | |
|<===========+===========+ |
| | | |
~ ~ ~ ~
| | | |
| Leave(Gr-Flow1) | Multicast-Admission-Crl |
|------------+---------->| (Target,delete,Gr-Flow1) |
| | |-------------------------->|
| <Stop Replication of X |
| Mcast Gr-Flow1> | |
| | | |
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(Gr-Flow1) | Multicast-Admission-Crl |
|------------+---------->| (Target,add,Gr-Flow1) |
| | |-------------------------->|
| | | (*)
| | | Multicast-Replication-Crl |
| | | (Target,add,Gr-Flow1) |
| | |<--------------------------|
| Mcast Gr-Flow1 | |
|<===========+===========+ |
| | | |
~ ~ ~ ~
| | | |
| Leave(Gr-Flow1) | Multicast-Admission-Crl |
|------------+---------->| (Target,delete,Gr-Flow1) |
| | |-------------------------->|
| <Stop Replication of X |
| Mcast Gr-Flow1> | |
| | | |
Gr-Flow1: a multicast flow matching the grey list for that port
Gr-Flow1：与该端口的灰色列表匹配的多播流
(*) The NAS may optionally seek direction from an external Authorization/Policy Server before admitting the flow.
（*）NAS可以选择在允许流量之前从外部授权/策略服务器寻求方向。
Figure 2: Multicast Conditional Access and Admission Control
图2：多播条件接收和接纳控制
The multicast flow reporting use case allows the NAS to asynchronously query the AN to obtain an instantaneous status report related to multicast flows currently replicated by the AN.
多播流报告用例允许NAS异步查询AN，以获得与AN当前复制的多播流相关的即时状态报告。
The NAS sends a Multicast Flow Query Request message to the AN in order to query the AN about information such as which multicast flows are currently active on a given AN port or which ports are currently replicating a given multicast flow. The AN conveys the requested information to the NAS in a Multicast Flow Query Response message. This message flow is illustrated in Figure 3.
NAS向AN发送多播流查询请求消息，以便查询有关信息，例如给定端口上哪些多播流当前处于活动状态，或者哪些端口当前正在复制给定多播流。AN在多播流查询响应消息中向NAS传送请求的信息。该消息流如图3所示。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast Flow |
| | | Query Request |
| | |<------------------|
| | | |
| | | Multicast Flow |
| | | Query Response |
| | |------------------>|
| | | |
| | | |
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast Flow |
| | | Query Request |
| | |<------------------|
| | | |
| | | Multicast Flow |
| | | Query Response |
| | |------------------>|
| | | |
| | | |
Figure 3: Multicast Flow Reporting
图3：多播流报告
The committed bandwidth reporting use case allows the NAS to maintain current awareness of how much multicast bandwidth the AN has committed to a given access line, so that the NAS can adjust its forwarding scheduler to ensure the associated QoS. Note that this involves a finer level of detail than provided by bandwidth delegation, since the amount of delegated bandwidth is an upper limit on the amount of bandwidth committed rather than an actual value. To reduce the volume of messaging, reports from the AN may be buffered so that one message reports on changes for multiple access lines.
提交的带宽报告用例允许NAS保持对AN已提交给给定接入线的多播带宽的当前感知，以便NAS可以调整其转发调度器以确保相关的QoS。请注意，这涉及到比带宽委派更精细的细节级别，因为委派的带宽量是承诺的带宽量的上限，而不是实际值。为了减少消息量，可以缓冲来自AN的报告，以便一条消息报告多个访问线路的更改。
The message flow associated with this use case is shown in Figure 4. The figure assumes that a non-zero buffering interval was previously provisioned on the AN.
与此用例相关的消息流如图4所示。该图假定先前在AN上设置了非零缓冲间隔。
+-----+ +-------+ +-----+ ANCP +-----+
|Subs |+ | Home |+ | AN |<---------->| NAS |
|1,2 || |GW 1,2 || +-----+ +-----+
+-----+| +-------+| | |
+|----+ +|------+ | |
| | | | | |
| |Join(Subs1, Ch1) | |
|----------+--------------->| Start buffering |
| | | Multicast flow | timer. Create |
|<=========+================| message with |
| | | | | initial contents |
| | | | | reporting new |
| | | | | Subs1 bandwidth. |
| | Join(Subs2, Ch2) | |
| |----------+------------->| Add report for |
| | | Multicast flow | new Subs2 b/w. |
| |<=========+==============| |
| | | | | |
| |Leave(Subs1, Ch1) | |
|----------+--------------->| Replace report |
| | | | | for Subs1 with |
| | Stop replication X new value (which |
| | | | | happens to be |
| | | | | the same as the |
| | | | | starting value). |
| | | | | |
| | | | >|< TIMER expires |
| | | | | |
| | | | |Committed |
| | | | | Bandwidth Report |
| | | | |------------------>|
| | | | | (for latest |
| | | | | Subs1 and Subs2 |
| | | | | bandwidth) |
| | | | | |
+-----+ +-------+ +-----+ ANCP +-----+
|Subs |+ | Home |+ | AN |<---------->| NAS |
|1,2 || |GW 1,2 || +-----+ +-----+
+-----+| +-------+| | |
+|----+ +|------+ | |
| | | | | |
| |Join(Subs1, Ch1) | |
|----------+--------------->| Start buffering |
| | | Multicast flow | timer. Create |
|<=========+================| message with |
| | | | | initial contents |
| | | | | reporting new |
| | | | | Subs1 bandwidth. |
| | Join(Subs2, Ch2) | |
| |----------+------------->| Add report for |
| | | Multicast flow | new Subs2 b/w. |
| |<=========+==============| |
| | | | | |
| |Leave(Subs1, Ch1) | |
|----------+--------------->| Replace report |
| | | | | for Subs1 with |
| | Stop replication X new value (which |
| | | | | happens to be |
| | | | | the same as the |
| | | | | starting value). |
| | | | | |
| | | | >|< TIMER expires |
| | | | | |
| | | | |Committed |
| | | | | Bandwidth Report |
| | | | |------------------>|
| | | | | (for latest |
| | | | | Subs1 and Subs2 |
| | | | | bandwidth) |
| | | | | |
Figure 4: Message Flow for Committed Bandwidth Reporting
图4：提交带宽报告的消息流
This section defines new ANCP messages and new usage of existing ANCP messages as well as procedures associated with the use of these messages.
本节定义了新的ANCP消息和现有ANCP消息的新用法，以及与这些消息的使用相关的程序。
Unless stated otherwise, receivers MUST ignore message contents that are not supported by the set of capabilities negotiated between the NAS and the Access Node.
除非另有说明，否则接收方必须忽略NAS和访问节点之间协商的一组功能不支持的消息内容。
Section 4.1 of [RFC6320] defines the Provisioning message that is sent by the NAS to the AN to provision information in the AN.
[RFC6320]的第4.1节定义了NAS向AN发送的配置消息，以提供AN中的to配置信息。
The present document specifies that the Provisioning message MAY be used by the NAS to provision multicast-related information (e.g., multicast service profiles). The ANCP Provisioning message payload MAY contain:
本文档规定，NAS可以使用供应消息来供应多播相关信息（例如，多播服务简档）。ANCP设置消息有效负载可能包含：
o one or more instances of the Multicast-Service-Profile TLV. The Multicast-Service-Profile TLV is defined in the present document in Section 5.1. Each instance of the Multicast-Service-Profile TLV contains a multicast service profile name and one or more list actions. A list action consists of an action (add, delete, replace), a list type (white, black, or grey), and list content (multicast source and group addresses).
o 多播服务配置文件TLV的一个或多个实例。本文件第5.1节定义了多播服务配置文件TLV。多播服务配置文件TLV的每个实例都包含一个多播服务配置文件名称和一个或多个列表操作。列表操作包括操作（添加、删除、替换）、列表类型（白色、黑色或灰色）和列表内容（多播源地址和组地址）。
o an instance of the White-List-CAC TLV. The White-List-CAC TLV is defined in Section 5.6. If present, this TLV indicates that the AN is required to do admission control before replicating white-listed flows.
o 白名单CAC TLV的一个实例。第5.6节定义了白名单CAC TLV。如果存在，此TLV表示AN需要在复制白名单流之前进行准入控制。
o an instance of the MRepCtl-CAC TLV. The MRepCtl-CAC TLV is defined in Section 5.7. If present, this TLV indicates that the AN is required to do admission control before replicating flows specified in Multicast Replication Control messages.
o MRepCtl CAC TLV的一个实例。MRepCtl CAC TLV的定义见第5.7节。如果存在此TLV，则表示需要AN在复制多播复制控制消息中指定的流之前执行准入控制。
o an instance of the Report-Buffering-Time TLV. The Report-Buffering-Time TLV is defined in Section 5.13. If present, this TLV indicates Committed Bandwidth Report messages should be buffered for the amount of time given by the TLV before being transmitted to the NAS.
o 报告缓冲时间TLV的实例。第5.13节定义了报告缓冲时间TLV。如果存在，此TLV表示提交的带宽报告消息在传输到NAS之前应缓冲TLV给定的时间量。
See Section 6 for information on which multicast capabilities require support of these TLVs in the Provisioning message.
请参阅第6节，了解在配置消息中哪些多播功能需要支持这些TLV。
When directed by the Policy Server or by management action, the NAS sends the Provisioning message to initially provision or to update the white, black, and/or grey multicast channel lists associated with a set of named multicast service profiles or to direct the AN to perform admission control for specific classes of flows.
当由策略服务器或管理操作指示时，NAS将发送供应消息，以初始供应或更新与一组命名多播服务配置文件相关联的白色、黑色和/或灰色多播信道列表，或指示AN对特定流类执行准入控制。
To provision or update a multicast service profile, the NAS MUST include within the message one or more instances of the Multicast-Service-Profile TLV specifying the content to be provisioned or updated. The NAS MUST NOT include any list type (white, black, or grey) that is not supported by the set of multicast capabilities negotiated between the NAS and the AN. The NAS MUST NOT use the Provisioning message to send instances of the Multicast-Service-Profile TLV to the AN unless the Multicast-Service-Profile TLV is supported by the set of multicast capabilities negotiated between the NAS and the AN.
要提供或更新多播服务配置文件，NAS必须在消息中包含多播服务配置文件TLV的一个或多个实例，指定要提供或更新的内容。NAS不得包括NAS和AN之间协商的多播功能集不支持的任何列表类型（白色、黑色或灰色）。NAS不得使用设置消息将多播服务配置文件TLV的实例发送到AN，除非NAS和AN之间协商的多播功能集支持多播服务配置文件TLV。
To require admission control to be performed at the AN on white-listed flows, the NAS MUST include a copy of the White-List-CAC TLV in the Provisioning message. The White-List-CAC TLV MUST NOT be provided unless the negotiated set of capabilities includes conditional access and admission control with white and black lists.
要要求在白名单流上的AN上执行准入控制，NAS必须在配置消息中包含白名单CAC TLV的副本。不得提供白名单CAC TLV，除非协商的能力集包括白名单和黑名单的条件接收和接纳控制。
To require admission control to be performed at the AN on grey-listed flows or on NAS-initiated flows, the NAS MUST include a copy of the MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV MUST NOT be provided unless the negotiated set of capabilities includes NAS-initiated multicast replication or conditional access and admission control with grey lists.
要要求在灰名单流或NAS启动流上的AN上执行准入控制，NAS必须在配置消息中包含MRepCtl CAC TLV的副本。不得提供MRepCtl CAC TLV，除非协商的一组功能包括NAS启动的多播复制或带有灰色列表的条件接收和准入控制。
To require buffering of Committed Bandwidth Report messages so that reports for multiple access lines can be included in the same message, the NAS MUST include a copy of the Report-Buffering-Time TLV containing a non-zero time value in a Provisioning message sent to the AN. The Report-Buffering-Time TLV MUST NOT be provided unless the negotiated set of capabilities includes committed bandwidth reporting.
要要求缓冲提交的带宽报告消息，以便在同一消息中包含多条接入线的报告，NAS必须在发送到AN的配置消息中包含一份报告缓冲时间TLV的副本，该TLV包含一个非零时间值。除非协商的功能集包括提交的带宽报告，否则不得提供报告缓冲时间TLV。
The receiving AN provisions/updates the white, black, and/or grey lists associated with the multicast service profile names contained in the Multicast-Service-Profile TLV instances within the message according to the contents of the associated List-Action TLVs. The AN MUST process List-Action TLVs in the order in which they appear within the message. In keeping with the general rule stated in
接收AN根据相关联的列表动作TLV的内容，规定/更新与包含在消息内的多播服务简档TLV实例中的多播服务简档名称相关联的白色、黑色和/或灰色列表。必须按照TLV在消息中出现的顺序处理列表操作TLV。符合本协议中规定的一般规则
Section 4, the AN MUST ignore instances of the List-Action TLV referring to any list type (white, black, or grey) that is not supported by the set of multicast capabilities negotiated between the NAS and the AN.
第4节，AN必须忽略列表操作TLV的实例，该TLV引用NAS和AN之间协商的多播功能集不支持的任何列表类型（白色、黑色或灰色）。
When a new multicast service profile is identified by a Multicast-Service-Profile TLV, the initial state of all lists associated with that profile according to the negotiated set of multicast capabilities is empty until changed by the contents of Multicast-Service-Profile TLVs.
当新的多播服务简档由多播服务简档TLV标识时，根据协商的多播能力集与该简档相关联的所有列表的初始状态为空，直到多播服务简档TLV的内容改变为止。
The receipt of a Provisioning message containing updates to an existing multicast service profile subsequent to startup will cause the AN to review the status of active flows on all ports to which that profile has been assigned. For further details, see Section 6.
在启动后接收到包含对现有多播服务配置文件更新的设置消息，将导致an检查该配置文件已分配到的所有端口上的活动流的状态。有关更多详细信息，请参见第6节。
If the White-List-CAC and/or MRepCtl-CAC TLV is present in the Provisioning message and the respective associated capabilities have been negotiated, the AN prepares (or continues) to do admission control on the indicated class(es) of flow. If one or both of these TLVs was present in an earlier Provisioning message but is absent in the latest message received, the AN ceases to do admission control on the indicated class(es) of flow.
如果白名单CAC和/或MRepCtl CAC TLV存在于供应消息中，并且已经协商了相应的关联能力，则AN准备（或继续）对所指示的流类进行准入控制。如果这些TLV中的一个或两个出现在较早的供应消息中，但在最近接收到的消息中不存在，则an将停止对指定的流类进行准入控制。
The buffering time specified in an instance of the Report-Buffering-Time TLV will not be applied until the current accumulation process of Committed Bandwidth Report messages finishes.
在提交的带宽报告消息的当前累积过程完成之前，不会应用报告缓冲时间TLV实例中指定的缓冲时间。
As indicated in [RFC6320], the AN MUST NOT reply to the Provisioning message if it processed it successfully. If an error prevents successful processing of the message content, the AN MUST return a Generic Response message as defined in [RFC6320], containing a Status-Info TLV with the appropriate content describing the error. For this purpose, the presence of a list type in a Multicast-Service-Profile TLV, which was ignored because it was not supported by the negotiated set of capabilities, is not considered to be an error.
如[RFC6320]中所述，如果AN成功地处理了设置消息，则不得回复该消息。如果错误阻止成功处理消息内容，则an必须返回[RFC6320]中定义的通用响应消息，其中包含状态信息TLV以及描述错误的适当内容。为此，多播服务配置文件TLV中存在列表类型（由于协商的功能集不支持该类型而被忽略）不被视为错误。
As specified in [RFC6320], the NAS may send DSL line configuration information to the AN (ANCP-based DSL line configuration use case) using ANCP Port Management messages. See Section 7.3 of [RFC6320] for the format of the Port Management message in that usage.
如[RFC6320]中所述，NAS可以使用ANCP端口管理消息向AN发送DSL线路配置信息（基于ANCP的DSL线路配置用例）。参见[RFC6320]第7.3节了解该用法中的端口管理消息格式。
This document specifies that the Port Management message MAY be used to convey either or both of the following TLVs:
本文件规定，端口管理消息可用于传送以下TLV之一或两者：
o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This TLV associates a Multicast Service Profile with the access line specified by the extension block and, in the case of white and black lists, delegates conditional access to the AN for the specified access line and channels.
o 多播服务配置文件名称TLV（定义见第5.2节）。此TLV将多播服务配置文件与扩展块指定的接入线相关联，并且在白名单和黑名单的情况下，将指定接入线和信道的有条件接入委托给AN。
o Bandwidth-Allocation TLV (defined in Section 5.5). This TLV specifies the total multicast bandwidth available to the AN for admission control at the access line.
o 带宽分配TLV（定义见第5.5节）。此TLV指定AN在接入线路上可用于准入控制的总多播带宽。
When the Port Management message is used for this purpose:
当端口管理消息用于此目的时：
o the Function field in the Port Management message MUST be set to 8, "Configure Connection Service Data".
o 端口管理消息中的功能字段必须设置为8，“配置连接服务数据”。
o the message MUST include TLV(s) to identify the access line concerned. If the access line is a DSL loop, the line-identifying TLV(s) MUST be as specified in Section 5.1.2 of [RFC6320]. For non-DSL access lines, the appropriate alternative line-identifying TLV(s) MUST be present. Line configuration data other than the two TLVs listed in the previous paragraph MAY be present.
o 信息必须包括TLV，以识别相关的接入线路。如果接入线路是DSL环路，则识别TLV的线路必须符合[RFC6320]第5.1.2节的规定。对于非DSL接入线路，必须提供识别TLV的适当替代线路。可能存在上一段中列出的两个TLV以外的线路配置数据。
The NAS sends the Port Management message at startup time to initialize parameters associated with the access line specified in the message and with the multicast capabilities negotiated between the NAS and the AN. The NAS MAY send additional Port Management messages subsequent to startup, to update or, in the case of the Bandwidth-Allocation TLV, reset these parameters. If the NAS includes a Multicast-Service-Profile-Name TLV in the Port Management message, the name MUST match a profile name provided in a Multicast-Service-Profile TLV in a prior Provisioning message. The NAS MUST NOT include a TLV unless it is supported by the set of multicast capabilities negotiated between the NAS and the AN. See Section 6 for further information.
NAS在启动时发送端口管理消息，以初始化与消息中指定的接入线以及NAS和AN之间协商的多播功能相关的参数。NAS可在启动后发送额外的端口管理消息，以更新或在带宽分配TLV的情况下重置这些参数。如果NAS在端口管理消息中包含多播服务配置文件名称TLV，则该名称必须与先前设置消息中多播服务配置文件TLV中提供的配置文件名称相匹配。NAS不得包括TLV，除非它受到NAS和AN之间协商的一组多播功能的支持。更多信息请参见第6节。
If the Port Management message contains a Multicast-Service-Profile-Name TLV, the AN associates the named profile with the specified access line. This association replaces any previous association. That is, a given access line is associated with at most one multicast service profile. The replacement of one multicast service profile with another will cause the AN to review the status of all active flows on the target port. For further details see Section 6.
如果端口管理消息包含多播服务配置文件名TLV，AN会将指定的配置文件与指定的访问线路相关联。此关联将替换以前的任何关联。也就是说，给定的接入线最多与一个多播服务配置文件相关联。用另一个多播服务配置文件替换一个多播服务配置文件将导致AN检查目标端口上所有活动流的状态。有关更多详细信息，请参见第6节。
If the Port Management message contains a Bandwidth-Allocation TLV, the AN adopts this as the current value of its total multicast bandwidth limit for the target port. If the AN has already committed multicast bandwidth exceeding the amount given in the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the new limit, unless such action is required by local policy. However, the AN MUST NOT admit new multicast streams that are subject to admission control until it can do so within the limit specified by the Bandwidth-Allocation TLV.
如果端口管理消息包含带宽分配TLV，AN将其作为目标端口的总多播带宽限制的当前值。如果AN已提交的多播带宽超过带宽分配TLV中给定的数量，则AN不应中断任何多播流以将带宽降低到新限制内，除非本地策略要求这样做。但是，AN必须在带宽分配TLV指定的限制范围内接纳受接纳控制的新多播流。
If the Port Management request cannot be processed due to error and the Result field of the request is Nack (0x1) or AckAll (0x2), the AN SHOULD add a Status-Info TLV to the Extension Value field in its reply if this will provide useful information beyond what is provided by the Result Code value returned in the response header. In particular, if the name within the Multicast-Service-Profile-Name TLV does not match a profile name given in a prior Provisioning message, the AN SHOULD return a reply where the Result Code field in the header indicates 0x55, "Invalid TLV contents", the Error Message field in the Status-Info TLV contains the text "Multicast profile name not provisioned", and the Status-Info TLV contains a copy of the Multicast-Service-Profile-Name TLV.
如果由于错误而无法处理端口管理请求，且请求的结果字段为Nack（0x1）或AckAll（0x2），则AN应在其回复中向扩展值字段添加状态信息TLV，前提是这将提供响应标头中返回的结果代码值所提供信息之外的有用信息。特别是，如果多播服务配置文件名称TLV中的名称与先前设置消息中给定的配置文件名称不匹配，AN应返回一个回复，其中标头中的结果代码字段指示0x55“无效TLV内容”，状态信息TLV中的错误消息字段包含文本“未设置多播配置文件名”，状态信息TLV包含多播服务配置文件名TLV的副本。
This section defines a new message called the Multicast Replication Control message. The Multicast Replication Control message is sent by the NAS to the AN with one or more directives to add (join) or delete (leave) a multicast flow on a target object identified in the content of the message.
本节定义了一条称为多播复制控制消息的新消息。多播复制控制消息由NAS发送到AN，其中包含一个或多个指令，用于在消息内容中标识的目标对象上添加（加入）或删除（离开）多播流。
The Message Type for the Multicast Replication Control message is 144.
多播复制控制消息的消息类型为144。
The ANCP Multicast Replication Control message payload contains the following TLVs:
ANCP多播复制控制消息负载包含以下TLV：
o Target TLV: The Target TLV is defined in Section 4.3 of [RFC6320]. It MUST appear once and only once. It is encoded as specified in [RFC6320] or extensions and identifies the AN port subject to the request for admission or release.
o 目标TLV：目标TLV在[RFC6320]第4.3节中定义。它必须出现一次，而且只能出现一次。按照[RFC6320]或扩展中的规定对其进行编码，并根据准入或释放请求标识端口。
o Command TLV: The Command TLV is defined in Section 4.4 of [RFC6320]. It MUST be present. It MAY appear multiple times.
o 命令TLV：命令TLV在[RFC6320]第4.4节中定义。它必须存在。它可能会出现多次。
As [RFC6320] indicates, the contents of the Command Info field within the Command TLV are specific to the message in which the TLV occurs. For the Multicast Replication Control message, these contents consist of:
正如[RFC6320]所指出的，命令TLV中的命令信息字段的内容特定于发生TLV的消息。对于多播复制控制消息，这些内容包括：
o a Command Code field;
o 命令代码字段；
o an Accounting field; and
o 会计领域；和
o an instance of the Multicast-Flow TLV.
o 多播流TLV的一个实例。
Figure 5 illustrates the complete Command TLV with the contents specific to the Multicast Replication Control message.
图5展示了完整的命令TLV，其中包含特定于多播复制控制消息的内容。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | Command TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Command Code | Accounting | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Flow TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other embedded TLV Type | Other embedded TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Other embedded TLV data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | Command TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Command Code | Accounting | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Flow TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other embedded TLV Type | Other embedded TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Other embedded TLV data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Contents of the Command TLV in the Multicast Replication Control Message
图5：多播复制控制消息中命令TLV的内容
o Command Code: One of the following command directives:
o 命令代码：以下命令指令之一：
1 "Add"
1“添加”
2 "Delete"
2“删除”
3 "Delete All"
3“全部删除”
4 "Admission Control Reject"
4“接纳控制拒绝”
5 "Conditional Access Reject"
5“有条件接收拒绝”
6 "Admission Control and Conditional Access Reject"
6“接纳控制和条件接收拒绝”
Directives 4 through 6 are used as described in Section 4.4.2.
如第4.4.2节所述，使用指令4至6。
o Accounting: Meaningful only when the Command Code is "Add" (1). In that case, 0 indicates flow accounting is disabled, and 1 indicates that octet accounting for the flow is requested. The sender MUST set the Accounting field to 0, and the receiver MUST ignore the Accounting field for other Command Code values.
o 记帐：仅当命令代码为“添加”（1）时才有意义。在这种情况下，0表示流记帐已禁用，1表示请求流的八位字节记帐。发送方必须将记帐字段设置为0，接收方必须忽略其他命令代码值的记帐字段。
o Reserved: Reserved for future use. MUST be set to zeroes by the sender and ignored by the receiver.
o 保留：保留供将来使用。发送方必须将其设置为零，接收方则忽略。
o Multicast-Flow TLV: An instance of the Multicast-Flow TLV (Section 5.12) specifying the flow to be added or deleted. The Multicast-Flow TLV is omitted if the Command Code has value "Delete All" (3).
o 多播流TLV：多播流TLV的实例（第5.12节），指定要添加或删除的流。如果命令代码的值为“全部删除”（3），则省略多播流TLV。
o Other embedded TLV data: No other embedded TLVs are currently specified within the Multicast Replication Control message and Command TLV. However, see the description of the Multicast Admission Control message (Section 4.4). Unrecognized embedded TLVs SHOULD be silently discarded.
o 其他嵌入式TLV数据：当前在多播复制控制消息和命令TLV中未指定其他嵌入式TLV。但是，请参见多播接纳控制消息的描述（第4.4节）。不可识别的嵌入式TLV应该被悄悄地丢弃。
The figure below is an example of a Multicast Replication Control message that would result in a swap from multicast Source-Specific Multicast (SSM) flows 2001:DB8::1, FF34::2 to 2001:DB8::2, FF34::3 on the target identified by the Access Loop Circuit ID:
下图是多播复制控制消息的示例，该消息将导致在访问环路ID标识的目标上从多播源特定多播（SSM）流2001:DB8:：1，FF34:：2到2001:DB8:：2，FF34:：3进行交换：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MsgType=144 | Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | Command TLV Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 2 | Acctg = 0 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | TLV Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | AddrFam = 2 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Multicast Group Address ~
| = FF34::2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Source Address ~
| = 2001:DB8::1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | Command-TLV Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | TLV Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | AddrFam = 2 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Multicast Group Address ~
| = FF34::3 |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MsgType=144 | Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | Command TLV Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 2 | Acctg = 0 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | TLV Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | AddrFam = 2 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Multicast Group Address ~
| = FF34::2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Source Address ~
| = 2001:DB8::1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | Command-TLV Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | TLV Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | AddrFam = 2 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Multicast Group Address ~
| = FF34::3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Source Address ~
| = 2001:DB8::2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Source Address ~
| = 2001:DB8::2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example Change of Source Flow Using Multicast Replication Control Message
图6：使用多播复制控制消息更改源流的示例
The NAS MAY issue a Multicast Replication Control message to the AN to convey one or more directives to add (join) or delete (leave) one or more multicast flows.
NAS可以向AN发出多播复制控制消息，以传递一个或多个指令来添加（加入）或删除（离开）一个或多个多播流。
The NAS MAY send this message on its own initiative to support the NAS-initiated multicast control use case presented in [RFC5851] and summarized in Section 3.1. In that case, the NAS MUST set the Result field to AckAll (0x2) or Nack (0x1) according to its requirements.
NAS可主动发送此消息，以支持[RFC5851]中介绍并在第3.1节中总结的NAS发起的多播控制用例。在这种情况下，NAS必须根据其要求将结果字段设置为AckAll（0x2）或Nack（0x1）。
The NAS MAY also send this message in response to a Multicast Admission Control message (defined in Section 4.4) received from the AN to support the conditional access and admission control use case presented in [RFC5851] and summarized in Section 3.2. In that case, the NAS MUST set the Result field to Nack (0x1).
NAS还可以发送此消息，以响应从AN接收的多播接纳控制消息（第4.4节中定义），以支持[RFC5851]中介绍并在第3.2节中总结的条件接收和接纳控制用例。在这种情况下，NAS必须将结果字段设置为Nack（0x1）。
In either case, the sender MUST populate the Result Code field with the value 0 and the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320].
在任何一种情况下，发送方必须使用值0填充结果代码字段，并使用唯一值填充ANCP交易标识符字段，如[RFC6320]第3.6.1.6节所述。
Each Multicast Replication Control message MUST contain one or more commands, each encapsulated in its own Command TLV. The sender MUST use a separate Command TLV for each distinct multicast flow.
每个多播复制控制消息必须包含一个或多个命令，每个命令都封装在自己的命令TLV中。发送方必须为每个不同的多播流使用单独的命令TLV。
When the order of processing of two commands does not matter, the commands MUST be transmitted in separate Multicast Replication Control messages.
当两个命令的处理顺序无关紧要时，必须在单独的多播复制控制消息中传输这些命令。
When successive commands (in the same or different messages) relate to the same target and multicast flow, the state of each feature controlled or affected by attributes received in the Multicast Replication Control message SHALL be as set by the last command or message referring to that target and flow and containing the controlling attribute. As an example, successive Multicast Replication Control messages containing add commands for a given port and flow but differing only in the Accounting field update the state
当连续命令（在相同或不同的消息中）与相同的目标和多播流相关时，多播复制控制消息中接收到的属性控制或影响的每个特性的状态应与引用该目标和流并包含控制属性的最后一个命令或消息的状态相同。例如，连续多播复制控制消息（包含针对给定端口和流的add命令，但仅在记帐字段中有所不同）会更新状态
of the accounting feature to what is set in the final command received, but all other features are unaffected by the second message.
将记帐功能设置为接收到的最终命令中设置的值，但所有其他功能不受第二条消息的影响。
If more than one Command TLV is present in a Multicast Replication Control message, the AN MUST act on the commands in the order in which they are presented in the message. The AN SHALL assign a sequence number to each command in a given Multicast Replication Control message, starting from 1 for the first command.
如果多播复制控制消息中存在多个命令TLV，则AN必须按照命令在消息中的显示顺序对这些命令执行操作。AN应为给定多播复制控制消息中的每个命令分配一个序列号，第一个命令从1开始。
If a Command TLV adds one or more flows and the AN is performing admission control for Multicast Replication Control messages, then the AN MUST perform admission control before replicating the flows. If the admission control check fails, the AN MUST treat the failure as an error as described below. The appropriate Result Code value for the response is 0x13 "Out of resources".
如果命令TLV添加了一个或多个流，并且AN正在对多播复制控制消息执行许可控制，则AN必须在复制流之前执行许可控制。如果准入控制检查失败，AN必须将失败视为错误，如下所述。响应的相应结果代码值为0x13“资源不足”。
If the AN processes the complete Multicast Replication Control message successfully and the Result field of the Multicast Replication Control message was set to AckAll (0x2), the AN MUST respond with a Generic Response message where the Result field is set to Success (0x3), the Result Code field is set to 0, and the Transaction Identifier field is copied from the Multicast Replication Control message. The body of the response MAY be empty or MAY be copied from the Multicast Replication Control message.
如果AN成功处理完整的多播复制控制消息，并且多播复制控制消息的结果字段设置为AckAll（0x2），则AN必须使用通用响应消息进行响应，其中结果字段设置为Success（0x3），结果代码字段设置为0，事务标识符字段从多播复制控制消息复制。响应的正文可以是空的，或者可以从多播复制控制消息复制。
If the AN processes the complete Multicast Replication Control message successfully and the Result field of the Multicast Replication Control message was set to Nack (0x1), the AN MUST NOT respond to the message.
如果AN成功处理完整的多播复制控制消息，并且多播复制控制消息的结果字段设置为Nack（0x1），则AN不得响应该消息。
The processing/execution of multiple commands contained in a single Multicast Replication Control message MUST be interrupted at the first error encountered and the remaining commands in the Multicast Replication Control message discarded. Similarly, if a given command specifies multiple Single-Source Multicast (SSM) flows and an error occurs, processing MUST be interrupted at that point, and the remainder of the Command TLV discarded.
在遇到第一个错误时，必须中断单个多播复制控制消息中包含的多个命令的处理/执行，并丢弃多播复制控制消息中的其余命令。类似地，如果给定命令指定多个单源多播（SSM）流，并且发生错误，则处理必须在该点中断，并且命令TLV的其余部分将被丢弃。
If the AN detects an error in a received Multicast Replication Control message and the Result field in that message was set to Nack (0x1) or AckAll(0x2), the AN MUST generate a Generic Response message providing error information to the NAS. This specification identifies the following new Result Code values beyond those specified in [RFC6320], which MAY be used in a Generic Response sent in reply to a Multicast Replication Control message:
如果AN在接收的多播复制控制消息中检测到错误，并且该消息中的结果字段设置为Nack（0x1）或AckAll（0x2），则AN必须生成一条向NAS提供错误信息的通用响应消息。本规范确定了[RFC6320]中规定之外的以下新结果代码值，这些值可用于回复多播复制控制消息而发送的一般响应：
0x64 Command error.
0x64命令错误。
Where detected: ANCP agent at the AN.
检测到的位置：AN处的ANCP代理。
Further description: an invalid command code has been received.
进一步说明：接收到无效的命令代码。
Required additional information in the message: see below.
信息中需要的其他信息：见下文。
Target: ANCP agent at the NAS.
目标：NAS的ANCP代理。
Action RECOMMENDED for the receiving ANCP agent: Report the error to the control application with an indication of the erroneous information associated with the invalid TLV(s).
建议接收ANCP代理采取的措施：向控制应用程序报告错误，并指示与无效TLV相关的错误信息。
0x65 Invalid flow address.
0x65无效的流地址。
Where detected: ANCP agent at the AN.
检测到的位置：AN处的ANCP代理。
Further description: either inconsistent flow address information has been provided or the address family is unsupported.
进一步说明：提供的流地址信息不一致，或者不支持地址族。
Required additional information in the message: see below.
信息中需要的其他信息：见下文。
Target: ANCP agent at the NAS.
目标：NAS的ANCP代理。
Action RECOMMENDED for the receiving ANCP agent: Report the error to the control application with an indication of the erroneous information associated with the invalid TLV(s).
建议接收ANCP代理采取的措施：向控制应用程序报告错误，并指示与无效TLV相关的错误信息。
0x66 Multicast flow does not exist.
0x66多播流不存在。
Where detected: control application at the AN.
检测到的位置：AN上的控制应用程序。
Further description: the NAS has attempted to delete a flow that is not active on the given access line.
进一步说明：NAS试图删除给定访问线路上不活动的流。
Required additional information in the message: see below.
信息中需要的其他信息：见下文。
Target: control application at the NAS.
目标：控制NAS上的应用程序。
Action RECOMMENDED for the receiving ANCP agent: report the error to the control application with an indication of the erroneous information associated with the invalid TLV(s).
建议接收ANCP代理采取的措施：向控制应用程序报告错误，并指示与无效TLV相关的错误信息。
A Generic Response message responding to the Multicast Replication Control message and containing one of the above Result Code values MUST include a Status-Info TLV, which includes one or two embedded TLVs as follows:
响应多播复制控制消息并包含上述结果代码值之一的通用响应消息必须包含一个状态信息TLV，其中包括一个或两个嵌入式TLV，如下所示：
o a Sequence-Number TLV as described in Section 5.4, giving the sequence number of the failed command, MUST be included; and
o 必须包括第5.4节所述的序列号TLV，给出失败命令的序列号；和
o the failed Command TLV itself SHOULD be included.
o 应包括失败的命令TLV本身。
Note: The Error Message field of the Status-Info TLV MAY be used to report more details than implied by the Result Code value in the message header. For example, the Result Code value could be 0x65, and the Error Message field could contain the text: "Source address present for ASM flow".
注意：状态信息TLV的错误消息字段可用于报告比消息头中的结果代码值暗示的更多详细信息。例如，结果代码值可以是0x65，错误消息字段可以包含文本：“ASM流的源地址存在”。
This section defines a new message called the Multicast Admission Control message. The Multicast Admission Control message is sent by the AN to the NAS to request admission of a multicast flow, or to notify of the removal of a multicast flow, for a given target.
本节定义了一个称为多播许可控制消息的新消息。多播接纳控制消息由AN发送到NAS，以针对给定目标请求多播流的接纳，或通知多播流的移除。
The Message Type for the Multicast Admission Control message is 145.
多播接纳控制消息的消息类型为145。
The ANCP Multicast Admission Control message payload contains two TLVs:
ANCP多播接纳控制消息有效负载包含两个TLV：
o Target TLV: The Target TLV is defined in [RFC6320]. It MUST appear once and only once in the Multicast Admission Control message. It is encoded as specified in [RFC6320] or extensions and identifies the AN port subject to the request for admission or release.
o 目标TLV：目标TLV在[RFC6320]中定义。它必须在多播接纳控制消息中出现一次且仅出现一次。按照[RFC6320]或扩展中的规定对其进行编码，并根据准入或释放请求标识端口。
o Command TLV: The Command TLV is defined in [RFC6320]. It MUST be present. If it appears more than once, only the first instance is considered meaningful in the present version of this specification, and the other instances are ignored.
o 命令TLV：命令TLV在[RFC6320]中定义。它必须存在。如果多次出现，则在本规范的当前版本中，仅第一个实例被视为有意义的，而忽略其他实例。
Note: In the future, the specification of the Multicast Admission Control message may be extended to allow transport of more than a single directive (e.g., to carry both a leave from one group and a join to another group for the same target). It is expected that this would support a similar notion of strict sequenced processing as currently defined for handling multiple directives in the Multicast Replication Control message whereby all directives following the first directive that cannot be executed are not
注意：在将来，多播接纳控制消息的规范可被扩展以允许传输多于一个指令（例如，为同一目标携带来自一个组的离开和到另一个组的加入）。预计这将支持严格顺序处理的类似概念，如当前为处理多播复制控制消息中的多个指令而定义的那样，其中第一个指令之后无法执行的所有指令都不会执行
executed either. When the strict sequenced processing of the directives is not required, the directives are distributed across separate messages.
要么执行。当不需要对指令进行严格的顺序处理时，指令将分布在不同的消息中。
The Command TLV has the same contents as were described above for the Multicast Replication Control message, with the following additions:
命令TLV的内容与上述多播复制控制消息的内容相同，但增加了以下内容：
o A Request-Source-IP TLV MAY be appended to the Command TLV as an additional embedded TLV.
o 请求源IP TLV可以作为附加嵌入式TLV附加到命令TLV。
o Similarly, a Request-Source-MAC TLV MAY be appended to the Command TLV as an additional embedded TLV.
o 类似地，请求源MAC TLV可以作为附加嵌入式TLV附加到命令TLV。
o Finally and preferably, a Request-Source-Device-Id TLV MAY be appended to the Command TLV as an additional embedded TLV.
o 最后且优选地，请求源设备Id TLV可作为附加嵌入式TLV附加到命令TLV。
Note that the Command TLV length includes the length of any embedded TLVs, including the embedded TLV headers.
请注意，命令TLV length包括任何嵌入式TLV的长度，包括嵌入式TLV头。
The AN sending the Multicast Admission Control message MUST set the Result field to Ignore (0x0).
发送多播接纳控制消息的AN必须将结果字段设置为忽略（0x0）。
The AN MUST populate the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320].
AN必须使用唯一值填充ANCP交易标识符字段，如[RFC6320]第3.6.1.6节所述。
The AN MUST encode the Command TLV as specified in Section 4.3 with the following additional rules:
AN必须按照第4.3节的规定使用以下附加规则对命令TLV进行编码：
o The Accounting field MUST be set to 0.
o 会计字段必须设置为0。
o The Command Code field MUST be set to "Add" (1) when the message conveys a join request, to "Delete" (2) when the message conveys a leave, and to "Delete All" (3) when the message conveys a leave of all channels (on the target).
o 当消息传递加入请求时，命令代码字段必须设置为“添加”（1），当消息传递许可时，必须设置为“删除”（2），当消息传递所有频道的许可时，必须设置为“全部删除”（3）。
o The Multicast-Flow TLV within the Command TLV identifies the multicast flow subject to the request for admission or release. When the Command Code is 3, the Multicast-Flow TLV is omitted.
o 命令TLV中的多播流TLV标识受接纳或释放请求约束的多播流。当命令代码为3时，将忽略多播流TLV。
o The Request-Source-IP embedded TLV MAY be included by the AN to convey the IP address of the sender of the join/leave message (e.g., IGMP/MLD join/leave) that triggered the AN to include the corresponding Command TLV in the Multicast Admission Control message. If it appears more than once, only the first instance is considered meaningful, and the other instances are ignored.
o AN可以包括请求源IP嵌入TLV，以传送加入/离开消息（例如，IGMP/MLD加入/离开）的发送方的IP地址，该加入/离开消息触发AN以在多播接纳控制消息中包括相应的命令TLV。如果多次出现，则仅第一个实例被视为有意义，而忽略其他实例。
o The Request-Source-MAC embedded TLV MAY be included by the AN to convey the Media Access Control (MAC) address of the sender of the join/leave message (e.g., IGMP/MLD join/leave) that triggered the AN to include the corresponding Command TLV in the Multicast Admission Control message. If it appears more than once, only the first instance is considered meaningful, and the other instances are ignored.
o 请求源MAC嵌入TLV可由AN包括以传送加入/离开消息（例如，IGMP/MLD加入/离开）的发送方的媒体访问控制（MAC）地址，该加入/离开消息触发AN以在多播接纳控制消息中包括相应的命令TLV。如果多次出现，则仅第一个实例被视为有意义，而忽略其他实例。
o As a third alternative, the Request-Source-Device-Id embedded TLV MAY be included by the AN to convey a local identifier of the sender of the join/leave message (e.g., IGMP/MLD join/leave) that triggered the AN to include the corresponding Command TLV in the Multicast Admission Control message. If it appears more than once, only the first instance is considered meaningful, and the other instances are ignored.
o 作为第三备选方案，AN可以包括嵌入TLV的请求源设备Id，以传递加入/离开消息（例如，IGMP/MLD加入/离开）的发送方的本地标识符，该加入/离开消息触发AN以在多播接纳控制消息中包括对应的命令TLV。如果多次出现，则仅第一个实例被视为有意义，而忽略其他实例。
The inclusion of Request-Source-IP or Request-Source-MAC in the Multicast Admission Control message is typically done to allow the application of policies applicable to specific devices within the customer's network. However, transmission of either of these fields beyond the AN introduces potential privacy issues. Instead of transmitting either of these identifiers, it is RECOMMENDED that the AN map the required identifier to a local value known to the AN and Authentication, Authorization, and Accounting (AAA) but not to the NAS, as discussed in Section 8. The local identifier is transmitted using the Request-Source-Device-Id TLV.
在多播接纳控制消息中包括请求源IP或请求源MAC通常是为了允许应用适用于客户网络内的特定设备的策略。但是，在AN之外传输这些字段都会带来潜在的隐私问题。如第8节所述，建议AN将所需标识符映射到AN和认证、授权和记帐（AAA）已知的本地值，而不是NAS，而不是传输这些标识符中的任何一个。使用请求源设备Id TLV传输本地标识符。
On receipt of a Multicast Admission Control message:
在收到多播接纳控制消息时：
o The NAS MUST ignore the Result field.
o NAS必须忽略结果字段。
o If the directive in the Multicast Admission Control message is "Delete" (2) or "Delete All" (3) and is processed correctly by the NAS, the NAS MUST NOT generate any ANCP message in response to the Multicast Admission Control message.
o 如果多播接纳控制消息中的指令为“Delete”（2）或“Delete All”（3），并且由NAS正确处理，则NAS不得生成任何ANCP消息以响应多播接纳控制消息。
o If the directive in the Multicast Admission Control message is "Add" (1) and is accepted by the NAS, the NAS MUST generate a Multicast Replication Control message in response to the Multicast Admission Control message. The Multicast Replication Control message:
o 如果多播许可控制消息中的指令为“Add”（1）且被NAS接受，则NAS必须生成多播复制控制消息以响应多播许可控制消息。多播复制控制消息：
* MUST contain a Result set to Nack (0x1);
* 必须包含Nack（0x1）的结果集；
* MUST contain a Transaction ID with a unique value, as described in Section 3.6.1.6 of [RFC6320]; and
* 必须包含具有唯一值的交易ID，如[RFC6320]第3.6.1.6节所述；和
* MUST contain the directive as accepted by the NAS. The NAS MAY modify the Accounting field if flow accounting is required.
* 必须包含NAS接受的指令。如果需要流量记帐，NAS可以修改记帐字段。
o If the directive in the Multicast Admission Control message is "Add" (1) and is processed correctly but not accepted by the NAS (i.e., it does not pass the conditional access and admission control check), the NAS MAY generate a Multicast Replication Control message in response to the Multicast Admission Control message. This optional message can be used by the AN to maintain statistics about admission control rejections. When used in this situation, the Multicast Replication Control message:
o 如果多播接纳控制消息中的指令为“添加”（1），并且被正确处理但未被NAS接受（即，它未通过条件接收和接纳控制检查），则NAS可生成多播复制控制消息以响应多播接纳控制消息。AN可以使用此可选消息来维护关于准入控制拒绝的统计信息。在这种情况下使用时，多播复制控制消息：
* MUST contain a Result set to 0x0;
* 必须包含一个设置为0x0的结果；
* MUST contain a Transaction ID with a unique value, as described in Section 3.6.1.6 of [RFC6320]; and
* 必须包含具有唯一值的交易ID，如[RFC6320]第3.6.1.6节所述；和
* MUST contain the directive rejected by the NAS (i.e., Target TLV and Command TLV) but with a Command Code set to "Admission Control Reject" (4), "Conditional Access Reject" (5), or "Admission Control and Conditional Access Reject" (6) as applicable.
* 必须包含NAS拒绝的指令（即目标TLV和命令TLV），但命令代码设置为“准入控制拒绝”（4）、“条件接收拒绝”（5）或“准入控制和条件接收拒绝”（6）（如适用）。
o If the Multicast Admission Control message cannot be processed correctly by the NAS (e.g., the message is malformed, the multicast flow does not exist, etc.), the NAS MUST generate a Generic Response message (defined in Section 4.2 of [RFC6320]) with appropriate content indicating the reason for the failure.
o 如果NAS无法正确处理多播许可控制消息（例如，消息格式不正确、多播流不存在等），NAS必须生成一条通用响应消息（在[RFC6320]第4.2节中定义），其中包含指示故障原因的适当内容。
The Bandwidth Reallocation Request message is used when the bandwidth delegation capability is included in the negotiated set. It MAY be sent either by the NAS or by the AN to request an adjustment in the amount of delegated bandwidth. It will be sent by the NAS typically to reduce the multicast bandwidth allocated to the AN in order for the NAS to satisfy a request to add one or more flows. Conversely, the AN will send a Bandwidth Reallocation Request message to obtain additional bandwidth to satisfy a request to add a multicast channel. In each case, the requestor has a minimum requirement for additional bandwidth and MAY ask for additional bandwidth beyond this amount (e.g., to handle anticipated future requests).
带宽重新分配请求消息在带宽委派能力包含在协商集时使用。它可以由NAS或AN发送，以请求调整委派的带宽量。它通常由NAS发送以减少分配给AN的多播带宽，以便NAS满足添加一个或多个流的请求。相反，AN将发送带宽重新分配请求消息以获得额外带宽以满足添加多播信道的请求。在每种情况下，请求者对额外带宽都有一个最低要求，并且可能要求额外带宽超过这个数量（例如，处理预期的未来请求）。
The Bandwidth Reallocation Request message contains two TLVs:
带宽重新分配请求消息包含两个TLV：
o the Target TLV (Section 4.3 of [RFC6320] or an extension), specifying a single access line; and
o 指定单个接入线的目标TLV（RFC6320第4.3节）或扩展；和
o the Bandwidth-Request TLV (Section 5.8), specifying the required and preferred amounts of delegated bandwidth.
o 带宽请求TLV（第5.8节），指定所需和首选的授权带宽量。
The Message Type for the Bandwidth Reallocation Request message is 146.
带宽重新分配请求消息的消息类型为146。
The Result field in the header of the Bandwidth Reallocation Request message is not used, and the sender MUST set it to Ignore (0x0).
带宽重新分配请求消息头中的结果字段未使用，发送方必须将其设置为忽略（0x0）。
The bandwidth values in the Bandwidth-Request TLV are expressed in terms of total multicast bandwidth allocated to the AN.
带宽请求TLV中的带宽值以分配给AN的总多播带宽表示。
Note: The choice of "total bandwidth" rather than "incremental bandwidth" was made so that it would be easier for the AN and NAS to keep their respective views of the current amount of delegated bandwidth synchronized.
注意：选择“总带宽”而不是“增量带宽”是为了使AN和NAS更容易保持其当前委派带宽量的视图同步。
Because the values are totals rather than desired increments/ decrements, the relationship between the required amount and the preferred amount will differ depending on whether the Bandwidth Reallocation Request message is issued by the NAS or the AN.
由于这些值是总计，而不是期望的增量/减量，因此所需量和首选量之间的关系将因NAS或AN发出的带宽重新分配请求消息而异。
o If the NAS is making the request, the preferred amount MUST be less than or equal to the required amount. The required amount MUST be less than the current amount of delegated bandwidth.
o 如果NAS提出请求，首选金额必须小于或等于所需金额。所需数量必须小于当前委派带宽的数量。
o If the AN is making the request, the preferred amount MUST be greater than or equal to the required amount. The required amount MUST be greater than the current amount of delegated bandwidth.
o 如果AN提出请求，首选金额必须大于或等于所需金额。所需数量必须大于当前委派带宽的数量。
When the peer receives a valid Bandwidth Reallocation Request message, it SHOULD determine whether it can satisfy the request from its existing allocation of unused video bandwidth. If it decides that it can reallocate bandwidth to the peer, it MAY choose to return any amount between the required and the preferred amounts indicated in the Bandwidth Reallocation Request message.
当对等方收到有效的带宽重新分配请求消息时，它应该确定是否可以通过其现有的未使用视频带宽分配来满足请求。如果它决定可以将带宽重新分配给对等方，它可以选择返回带宽重新分配请求消息中指示的所需和首选数量之间的任何数量。
The peer MUST return a Bandwidth Transfer message (Section 4.6) indicating its decision. If the request is met, the Result field of the Bandwidth Transfer message MUST be set to Success (0x3), the Result Code field MUST be set to 0x000, and the Bandwidth-Allocation TLV (Section 5.5) MUST contain the new value of total multicast bandwidth. This new value MUST lie between the required and preferred values, inclusive, from the request message. If the
对等方必须返回表明其决定的带宽传输消息（第4.6节）。如果满足请求，则带宽传输消息的结果字段必须设置为成功（0x3），结果代码字段必须设置为0x000，并且带宽分配TLV（第5.5节）必须包含总多播带宽的新值。此新值必须位于请求消息中的必需值和首选值（包括）之间。如果
request is not met, the Result field of the Bandwidth Transfer message MUST be set to Failure (0x4), the Result Code field MUST be set to 0, and the Bandwidth-Allocation TLV MUST contain the value of the currently allocated amount of delegated bandwidth as the responder views it.
未满足请求，带宽传输消息的结果字段必须设置为失败（0x4），结果代码字段必须设置为0，带宽分配TLV必须包含响应者查看时当前分配的委派带宽量的值。
The following cases indicate that the sender holds a different view of the amount of delegated bandwidth from the receiver:
以下情况表明，发送方对来自接收方的委派带宽量持有不同的看法：
o The NAS receives a request where the required amount is less than its view of the current amount of delegated bandwidth.
o NAS接收到一个请求，其中所需的带宽量小于其当前委派带宽量的视图。
o The AN receives a request where the required amount is greater than its view of the current amount of delegated bandwidth.
o AN收到一个请求，其中所需的带宽量大于其当前委派带宽量的视图。
If one of these cases occurs, the receiver, with one exception, MUST send a Bandwidth Transfer message indicating Success.
如果出现上述情况之一，则除了一个例外，接收器必须发送一条带宽传输消息，指示成功。
o If the NAS received the request, the allocated amount in the NAS's response MUST be at least equal to the NAS's view of the current amount of delegated bandwidth.
o 如果NAS收到请求，NAS响应中的分配量必须至少等于NAS对当前委派带宽量的视图。
o If the AN received the request, the allocated amount in the AN's response MUST be no greater than the AN's view of the current amount of delegated bandwidth.
o 如果AN收到请求，则AN响应中的分配量不得大于AN当前委派带宽量的视图。
The exception is when the NAS receives a request while it has a request of its own outstanding. Handling of that case is described below.
例外情况是，NAS在收到请求的同时有自己的未完成请求。该案件的处理情况如下所述。
Note: While the cases just described are an error condition, the success response achieves a graceful recovery.
注意：虽然刚才描述的情况是错误情况，但成功响应实现了良好的恢复。
To avoid deadlock due to race conditions, the following rules MUST be applied:
为避免因竞争条件而导致死锁，必须应用以下规则：
a. If the NAS receives a Bandwidth Reallocation Request message while it has a Bandwidth Reallocation Request message of its own outstanding for the same access line, the NAS MUST provide an immediate failure response to the request from the AN, with a Result Code value set to 0x68 "Inconsistent views of delegated bandwidth amount" or 0x69 "Bandwidth request conflict" as applicable. (See below for more information).
a. 如果NAS接收到带宽重新分配请求消息，而其自身对同一接入线有未完成的带宽重新分配请求消息，则NAS必须立即对来自an的请求提供故障响应，结果代码值设置为0x68“不一致的委派带宽量视图”或0x69“带宽请求冲突”（如适用）（有关更多信息，请参阅下文）。
b. If the AN receives a Bandwidth Reallocation Request message while it has a Bandwidth Reallocation Request message of its own outstanding for the same access line, the AN MUST release any bandwidth it has already committed to an outstanding join request
b. 如果AN接收到带宽重新分配请求消息，而其自身对同一接入线有未完成的带宽重新分配请求消息，则AN必须释放其已提交给未完成加入请求的任何带宽
while it is awaiting a response from the NAS. It MUST decide upon and send its response to the NAS taking the released bandwidth into account.
它正在等待NAS的响应。它必须决定并向NAS发送响应，同时考虑释放的带宽。
If the receiver is unable to process the Bandwidth Reallocation Request message due to an error, then the receiver MUST return a Bandwidth Transfer message where:
如果接收器由于错误而无法处理带宽重新分配请求消息，则接收器必须返回带宽传输消息，其中：
o the Result field is set to Failure (0x4),
o 结果字段设置为失败（0x4），
o the Result Code field is set appropriately to indicate the type of error that was detected,
o 适当设置结果代码字段，以指示检测到的错误类型，
o the Bandwidth-Allocation TLV contains the value of the current amount of delegated bandwidth as the responder views it, and
o 带宽分配TLV包含响应者查看的当前委派带宽量的值，以及
o a Status-Info TLV MAY follow the Bandwidth-Allocation TLV giving further information about the error.
o 状态信息TLV可以跟随带宽分配TLV，给出关于错误的进一步信息。
This specification provides three new Result Code values applicable specifically to the contents of the Bandwidth-Request TLV. These Result Code values by their nature MUST only be used when the error is being reported in a Bandwidth Transfer message rather than a Generic Response message.
本规范提供了三个新的结果代码值，具体适用于带宽请求TLV的内容。仅当在带宽传输消息（而非一般响应消息）中报告错误时，才能使用这些结果代码值。
0x67 Invalid preferred bandwidth amount.
0x67首选带宽量无效。
Where detected: control application at the receiver of the Bandwidth Reallocation Request message.
检测到的位置：在带宽重新分配请求消息的接收器处控制应用程序。
Further description: the preferred and required amounts of bandwidth in the TLV do not have the numerical relationship described above.
进一步说明：TLV中的优选带宽量和所需带宽量不具有上述数字关系。
Required additional information in the message: as described above.
消息中需要的其他信息：如上所述。
Target: control application at the sender of the Bandwidth Reallocation Request message.
目标：控制带宽重新分配请求消息发送方的应用程序。
Action RECOMMENDED for the receiving ANCP agent: report the error to the control application with the returned value of the Bandwidth-Allocation TLV. See also Section 4.6.2.2.
为接收ANCP代理建议的操作：使用带宽分配TLV的返回值向控制应用程序报告错误。另见第4.6.2.2节。
0x68 Inconsistent views of delegated bandwidth amount.
0x68委派带宽量的视图不一致。
Where detected: control application at the NAS.
检测到的位置：NAS上的控制应用程序。
Further description: the NAS has an outstanding Bandwidth Reallocation Request, so it is rejecting a similar request from the AN. In the AN request, the required amount was less than the NAS's view of the current amount of delegated bandwidth.
进一步说明：NAS有一个未完成的带宽重新分配请求，因此它拒绝了来自an的类似请求。在AN请求中，所需的带宽量小于NAS的当前委派带宽量视图。
Required additional information in the message: as described above.
消息中需要的其他信息：如上所述。
Target: control application at the AN.
目标：在AN上控制应用程序。
Action RECOMMENDED for the receiving ANCP agent: report the error to the AN control application with the returned value of the Bandwidth-Allocation TLV. See also Section 4.6.2.2.
为接收ANCP代理建议的操作：使用带宽分配TLV的返回值向控制应用程序报告错误。另见第4.6.2.2节。
0x69 Bandwidth request conflict.
0x69带宽请求冲突。
Where detected: control application at the NAS.
检测到的位置：NAS上的控制应用程序。
Further description: the NAS has an outstanding Bandwidth Reallocation Request, so it is rejecting a similar, valid request from the AN.
进一步说明：NAS有一个未完成的带宽重新分配请求，因此它拒绝了来自an的类似有效请求。
Required additional information in the message: as described above.
消息中需要的其他信息：如上所述。
Target: control application at the AN.
目标：在AN上控制应用程序。
Action RECOMMENDED for the receiving ANCP agent: report the error to the AN control application with the returned value of the Bandwidth-Allocation TLV. See also Section 4.6.2.2.
为接收ANCP代理建议的操作：使用带宽分配TLV的返回值向控制应用程序报告错误。另见第4.6.2.2节。
The Bandwidth Transfer message is used to transfer video bandwidth from the sender to the peer for a specific access line. This message MAY be sent either from the AN or from the NAS. As described in the previous section, it is the required response to a valid Bandwidth Reallocation Request message.
带宽传输消息用于将视频带宽从发送方传输到特定接入线路的对等方。此消息可以从AN或NAS发送。如前一节所述，这是对有效带宽重新分配请求消息的必要响应。
The Bandwidth Transfer message MAY also be used to transfer bandwidth autonomously from one peer to another. One example of this usage is to release bandwidth borrowed earlier by means of the Bandwidth
带宽传输消息还可用于自动地将带宽从一个对等点传输到另一个对等点。这种用法的一个例子是通过带宽释放先前借用的带宽
Reallocation Request message. When the message is used in this way, the Result field in the Bandwidth Transfer message MUST be set to Ignore (0x0).
重新分配请求消息。以这种方式使用消息时，带宽传输消息中的结果字段必须设置为忽略（0x0）。
Note: This allows the receiver to distinguish between an autonomous transfer and a response to a previous Bandwidth Reallocation Request message, for purposes of validation.
注意：为了验证，这允许接收器区分自动传输和对先前带宽重新分配请求消息的响应。
The Message Type for the Bandwidth Transfer message is 147. The Bandwidth Transfer message contains the following TLVs:
带宽传输消息的消息类型为147。带宽传输消息包含以下TLV：
o the Target TLV, designating the access line concerned;
o 指定相关接入线的目标TLV；
o an instance of the Bandwidth-Allocation TLV (Section 5.5). The bandwidth value in the Bandwidth-Allocation TLV is the new amount of delegated bandwidth allocated to the target.
o 带宽分配TLV的实例（第5.5节）。带宽分配TLV中的带宽值是分配给目标的新委派带宽量。
When sending a Bandwidth Transfer message where the Result value is Ignore (0x0) or Success (0x3), the following relationships MUST hold:
当发送结果值为Ignore（0x0）或Success（0x3）的带宽传输消息时，必须保持以下关系：
o If the message is sent by the NAS, the bandwidth value in the Bandwidth-Allocation TLV MUST be greater than or equal to the sender's view of the current amount of delegated bandwidth for the access line concerned.
o 如果消息是由NAS发送的，则带宽分配TLV中的带宽值必须大于或等于发送方对相关接入线的当前委派带宽量的看法。
o If the message is sent by the AN, the bandwidth value in the Bandwidth-Allocation TLV MUST be less than or equal to the sender's view of the current amount of delegated bandwidth for the access line concerned.
o 如果消息由AN发送，则带宽分配TLV中的带宽值必须小于或等于发送方对相关接入线的当前委派带宽量的看法。
Further sender behavior is specified above, in Section 4.5.2.
上文第4.5.2节规定了发送者的进一步行为。
If the amount of delegated bandwidth provided in the Bandwidth-Allocation TLV is not greater than the NAS's view of the current amount of delegated bandwidth, the NAS MUST update its view of the current amount of delegated bandwidth to the amount indicated in the Bandwidth Transfer message. This is required regardless of whether the Result field of that message indicates Success or Failure.
如果带宽分配TLV中提供的委派带宽量不大于NAS的当前委派带宽量视图，则NAS必须将其当前委派带宽量视图更新为带宽传输消息中指示的量。无论该消息的结果字段指示成功还是失败，这都是必需的。
If the amount of delegated bandwidth provided in the Bandwidth-Allocation TLV is greater than the NAS's view of the current amount of delegated bandwidth, the NAS MAY accept the given value as its new
如果带宽分配TLV中提供的委派带宽量大于NAS对当前委派带宽量的看法，NAS可以接受给定值作为其新值
value of delegated bandwidth. Alternatively, the NAS MAY force the AN to modify its view of the amount of delegated bandwidth to that held by the NAS by sending a Port Management message for the target access line concerned that contains a Bandwidth-Allocation TLV with a value equal to the amount of delegated bandwidth the NAS wishes to enforce.
委派带宽的值。或者，NAS可以通过发送有关目标接入线的端口管理消息（该消息包含带宽分配TLV，其值等于NAS希望实施的委派带宽量），迫使AN将其委派带宽量的视图修改为NAS持有的带宽量。
If the amount of delegated bandwidth provided in the Bandwidth-Allocation TLV of the Bandwidth Transfer message differs from the AN's view of the current amount of delegated bandwidth, the AN MUST update its view of the current amount of delegated bandwidth to the amount indicated in the Bandwidth Transfer message. This is required with the exception of a Bandwidth Transfer message with a Result field equal to Failure (0x4) and a Result Code field equal to 0x68 "Inconsistent views of delegated bandwidth amount" or 0x69 "Bandwidth request conflict". If Result Code value 0x68 is received, the AN MUST issue a Delegated Bandwidth Query Request message to determine the NAS's current view of the amount of delegated bandwidth. The AN MUST update its own view based on the value returned in the Delegated Bandwidth Query Response message. If Result Code value 0x69 is received, the AN SHOULD carry out this procedure unless it can account for the discrepancy as a result of a transfer of bandwidth to the NAS that was carried out just before the incoming Bandwidth Transfer message was processed.
如果带宽传输消息的带宽分配TLV中提供的委派带宽量与AN的当前委派带宽量视图不同，则AN必须将其当前委派带宽量视图更新为带宽传输消息中指示的量。这是必需的，但带宽传输消息除外，其结果字段等于Failure（0x4），结果代码字段等于0x68“委托带宽量的不一致视图”或0x69“带宽请求冲突”。如果收到结果代码值0x68，则AN必须发出委派带宽查询请求消息，以确定NAS对委派带宽量的当前视图。AN必须根据委派带宽查询响应消息中返回的值更新自己的视图。如果接收到结果代码值0x69，则AN应执行此过程，除非它能够解释在处理传入带宽传输消息之前执行的向NAS传输带宽所导致的差异。
Note: The two Result Code values indicate a race condition where the AN may have just completed a transfer of bandwidth to the NAS. As a result, the value given in the Bandwidth Transfer message may be outdated, and the AN needs to query the NAS to find its latest view. The procedure assumes that ordering is preserved between the Bandwidth Transfer message sent by the AN in response to the NAS's request and the subsequent Delegated Bandwidth Query Request message.
注意：两个结果代码值表示竞争条件，其中AN可能刚刚完成到NAS的带宽传输。因此，带宽传输消息中给出的值可能已过时，AN需要查询NAS以查找其最新视图。该过程假定在AN响应NAS请求而发送的带宽传输消息和随后的委派带宽查询请求消息之间保留排序。
If the AN has already committed multicast bandwidth exceeding the amount given in the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the new limit, unless such action is required by local policy. However, the AN MUST NOT admit new multicast streams that are subject to admission control until it can do so within the limit specified by the Bandwidth-Allocation TLV. As specified in Section 6.2.5.2, the AN MAY attempt to correct the situation by sending a request to the NAS for an increased allocation of delegated bandwidth using the Bandwidth Reallocation Request message.
如果AN已提交的多播带宽超过带宽分配TLV中给定的数量，则AN不应中断任何多播流以将带宽降低到新限制内，除非本地策略要求这样做。但是，AN必须在带宽分配TLV指定的限制范围内接纳受接纳控制的新多播流。如第6.2.5.2节所述，AN可尝试通过使用带宽重新分配请求消息向NAS发送请求以增加委派带宽的分配来纠正这种情况。
The Message Type for the Delegated Bandwidth Query Request (and Response) messages is 148.
委派带宽查询请求（和响应）消息的消息类型为148。
The Delegated Bandwidth Query Request message MAY be sent either by the NAS or by the AN to retrieve the peer's view of the amount of delegated bandwidth. The request contains one TLV:
委派带宽查询请求消息可由NAS或AN发送，以检索对等方对委派带宽量的视图。该请求包含一个TLV：
o a Target TLV designating the access line for which the information is requested.
o 指定请求信息的接入线路的目标TLV。
The sender MUST set the Result field in the header of the Delegated Bandwidth Query Request message to AckAll (0x2). The Result Code value MUST be set to 0. The sender MUST populate the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320].
发送方必须将委派带宽查询请求消息头中的结果字段设置为AckAll（0x2）。结果代码值必须设置为0。发送方必须使用唯一值填充ANCP交易标识符字段，如[RFC6320]第3.6.1.6节所述。
If the AN or NAS receives a valid Delegated Bandwidth Query Request message, it MUST respond with a Delegated Bandwidth Query Response message. The Result field in the header of the response MUST be set to Success (0x3). The Result Code field MUST be set to 0. The Transaction Identifier field MUST be copied from the request message. The body of the response MUST contain the Target TLV, copied from the request message. Finally, the body of the response MUST contain a Bandwidth-Allocation TLV, containing the current amount of delegated bandwidth from the point of view of the receiver of the request.
如果AN或NAS收到有效的委派带宽查询请求消息，则必须使用委派带宽查询响应消息进行响应。响应头中的结果字段必须设置为成功（0x3）。结果代码字段必须设置为0。必须从请求消息复制事务标识符字段。响应的主体必须包含从请求消息复制的目标TLV。最后，响应主体必须包含带宽分配TLV，该TLV包含从请求接收方的角度来看的当前委派带宽量。
If the contents of the Delegated Bandwidth Query Request message are in error, the receiver MUST return a Delegated Bandwidth Query Response message with the Result field in the header set to Failure (0x3). The Result Code field MUST be set to the value that indicates the nature of the error (e.g., 0x500 "One or more of the specified ports do not exist"). The Transaction Identifier field MUST be copied from the request. The body of the response MUST contain the Target TLV copied from the request. This MAY be followed by a Status-Info TLV giving further information about the error.
如果委派带宽查询请求消息的内容有误，则接收方必须返回委派带宽查询响应消息，消息头中的结果字段设置为失败（0x3）。结果代码字段必须设置为指示错误性质的值（例如，0x500“一个或多个指定端口不存在”）。必须从请求中复制事务标识符字段。响应的主体必须包含从请求复制的目标TLV。随后可能会出现一个状态信息TLV，提供有关错误的进一步信息。
The Delegated Bandwidth Query Response message is sent in reply to a Delegated Bandwidth Query Request message. The response to a valid request contains two TLVs:
发送委派带宽查询响应消息以响应委派带宽查询请求消息。对有效请求的响应包含两个TLV：
o the Target TLV, copied from the request; and
o 从请求复制的目标TLV；和
o a Bandwidth-Allocation TLV, giving the responder's view of the current amount of multicast bandwidth delegated to the AN.
o 带宽分配TLV，提供响应者对委托给AN的当前多播带宽量的看法。
The Message Type for the Delegated Bandwidth Query Response message is 148.
委派带宽查询响应消息的消息类型为148。
Sender behavior for the Delegated Bandwidth Query Response message is specified in Section 4.7.2.
第4.7.2节规定了委派带宽查询响应消息的发送方行为。
If the Delegated Bandwidth Query Response message indicates Success (0x3), the actions described in Sections 4.8.2.1 and 4.8.2.2 apply.
如果委派带宽查询响应消息指示成功（0x3），则第4.8.2.1节和第4.8.2.2节中描述的操作适用。
If the amount of delegated bandwidth provided in the Bandwidth-Allocation TLV is less than the NAS's view of the current amount of delegated bandwidth, the NAS MUST update its view of the current amount of delegated bandwidth to the amount indicated in the Delegated Bandwidth Query Response message.
如果带宽分配TLV中提供的委派带宽量小于NAS的当前委派带宽量视图，NAS必须将其当前委派带宽量视图更新为委派带宽查询响应消息中指示的量。
If the amount of delegated bandwidth provided in the Bandwidth-Allocation TLV is greater than the NAS's view of the current amount of delegated bandwidth, the NAS MAY accept the given value as its new value of delegated bandwidth. Alternatively, the NAS MAY force the AN to modify its view of the amount of delegated bandwidth to that held by the NAS by sending a Port Management message for the target access line concerned that contains a Bandwidth-Allocation TLV with a value equal to the amount of delegated bandwidth the NAS wishes to enforce.
如果带宽分配TLV中提供的委托带宽量大于NAS对当前委托带宽量的看法，NAS可以接受给定值作为其新的委托带宽值。或者，NAS可以通过发送有关目标接入线的端口管理消息（该消息包含带宽分配TLV，其值等于NAS希望实施的委派带宽量），迫使AN将其委派带宽量的视图修改为NAS持有的带宽量。
The AN SHOULD accept the value returned in the Bandwidth-Allocation TLV of the Delegated Bandwidth Query Response message as the correct value of the current amount of delegated bandwidth. If the AN has already committed multicast bandwidth exceeding the amount given in the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the new limit, unless such action is required by local policy. However, the AN MUST NOT admit new multicast streams that are subject to admission control until it can do so within the limit specified by the Bandwidth-Allocation TLV. As specified in Section 6.2.5.2, the AN
AN应接受在委派带宽查询响应消息的带宽分配TLV中返回的值作为当前委派带宽量的正确值。如果AN已提交的多播带宽超过带宽分配TLV中给定的数量，则AN不应中断任何多播流以将带宽降低到新限制内，除非本地策略要求这样做。但是，AN必须在带宽分配TLV指定的限制范围内接纳受接纳控制的新多播流。根据第6.2.5.2节的规定，AN
MAY attempt to correct the situation by sending a request to the NAS for an increased allocation of delegated bandwidth using the Bandwidth Reallocation Request message.
可以尝试通过使用带宽重新分配请求消息向NAS发送请求以增加委派带宽的分配来纠正这种情况。
Note: A race condition is possible where the AN sends a query, the NAS requests more bandwidth, then receives and responds to the query, and then receives the Bandwidth Transfer message responding to its request. It is up to the AN to take appropriate action in this case. The best action appears to be not to act on the result of the first query but to repeat the query after sending the Bandwidth Transfer message. Similar considerations apply to a race between queries from both sides.
注意：竞争条件是可能的，即AN发送查询，NAS请求更多带宽，然后接收并响应查询，然后接收响应其请求的带宽传输消息。在这种情况下，应由AN采取适当的行动。最好的操作似乎不是对第一次查询的结果进行操作，而是在发送带宽传输消息后重复查询。类似的考虑也适用于双方查询之间的竞争。
This section defines two new messages called the Multicast Flow Query Request and Multicast Flow Query Response. The Multicast Flow Query Request message is sent by the NAS to request information about the multicast flows that are active on the AN. The Multicast Flow Query Response message is sent in response by the AN to provide the requested information to the NAS.
本节定义了两条新消息，称为多播流查询请求和多播流查询响应。多播流查询请求消息由NAS发送，以请求有关AN上活动的多播流的信息。多播流查询响应消息由AN响应发送，以向NAS提供请求的信息。
The Message Type for the Multicast Flow Query Request and Multicast Flow Query Response messages is 149.
多播流查询请求和多播流查询响应消息的消息类型为149。
The contents of the Multicast Flow Query Request and Multicast Flow Query Response messages depend on the nature of the query, as described below.
多播流查询请求和多播流查询响应消息的内容取决于查询的性质，如下所述。
The sender of a Multicast Flow Query Request message MUST set the Result field to AckAll (0x2). The Result Code field MUST be set to 0x000. The sender MUST populate the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320].
多播流查询请求消息的发送方必须将结果字段设置为AckAll（0x2）。结果代码字段必须设置为0x000。发送方必须使用唯一值填充ANCP交易标识符字段，如[RFC6320]第3.6.1.6节所述。
The Multicast Flow Query Request message MAY be used by the NAS to retrieve:
NAS可以使用多播流查询请求消息来检索：
o the AN's view of which multicast flows are currently active on a specified set of access ports; or
o AN的视图，其中多播流当前在一组指定的接入端口上处于活动状态；或
o the AN's view of the access ports on which a specified set of multicast flows are currently active; or
o AN的接入端口视图，其中指定的一组多播流当前处于活动状态；或
o the AN's view of all the multicast flows currently active on each access port of the AN.
o AN的每个访问端口上当前活动的所有多播流的视图。
To retrieve the AN's view of which multicast flows are currently active on a given port of the AN, the NAS MUST include a Target TLV in the Multicast Flow Query Request payload identifying that port. The Target TLV is encoded as specified in [RFC6320].
要检索AN的视图，查看AN的给定端口上当前有哪些多播流处于活动状态，NAS必须在多播流查询请求有效负载中包含一个目标TLV，以标识该端口。目标TLV按照[RFC6320]中的规定进行编码。
To retrieve the AN's view of the ports currently receiving a given multicast flow, the NAS MUST include a Multicast-Flow TLV in the Multicast Flow Query Request payload identifying that flow. The Multicast-Flow TLV is encoded as specified in Section 5.12.
要检索AN当前接收给定多播流的端口的视图，NAS必须在多播流查询请求有效负载中包含多播流TLV，以标识该流。按照第5.12节的规定对多播流TLV进行编码。
The NAS MAY include multiple Target TLVs or multiple Multicast-Flow TLVs in the Multicast Flow Query Request message but MUST NOT include both Target and Multicast-Flow TLVs in the same message.
NAS可以在多播流查询请求消息中包括多个目标TLV或多个多播流TLV，但不能在同一消息中同时包括目标和多播流TLV。
To retrieve the AN's view of all of the multicast flows currently active on each port of the AN, the NAS MUST send a Multicast Flow Query Request message that does not contain any instance of the Target TLV or the Multicast-Flow TLV.
要检索AN每个端口上当前活动的所有多播流的AN视图，NAS必须发送不包含任何目标TLV或多播流TLV实例的多播流查询请求消息。
The AN MUST respond to a Multicast Flow Query Request message that has a valid format and a valid content with a Multicast Flow Query Response message. The Result field in the response MUST be set to Success (0x3). The Result Code field MUST be set to 0. The Transaction Identifier field MUST be copied from the request.
AN必须使用多播流查询响应消息响应具有有效格式和有效内容的多播流查询请求消息。响应中的结果字段必须设置为成功（0x3）。结果代码字段必须设置为0。必须从请求中复制事务标识符字段。
If the Multicast Flow Query Request contains one (or more) Target TLVs, the AN MUST include, for each of these Target TLVs, the following set of TLVs:
如果多播流查询请求包含一个（或多个）目标TLV，AN必须为每个目标TLV包含以下TLV集：
o Target TLV. This MUST be identical to the Target TLV in the received Multicast Flow Query Request message.
o 目标TLV。这必须与接收到的多播流查询请求消息中的目标TLV相同。
o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once per multicast flow that is currently active on the AN port identified in the preceding Target TLV.
o 多播流TLV。对于前一个目标TLV中标识的端口上当前处于活动状态的每个多播流，多播流TLV必须出现一次。
The Target TLVs MUST appear in the response from the AN in the same order as in the query from the NAS.
目标TLV必须以与NAS查询相同的顺序出现在来自AN的响应中。
If the Multicast Flow Query Request message contains one (or more) Multicast-Flow TLVs, the AN MUST include, for each of these Multicast-Flow TLVs, the following set of TLVs:
如果多播流查询请求消息包含一个（或多个）多播流TLV，则AN必须为这些多播流TLV中的每一个包含以下TLV集：
o Multicast-Flow TLV. This MUST be identical to the Multicast-Flow TLV in the received Multicast Flow Query Request message.
o 多播流TLV。这必须与接收到的多播流查询请求消息中的多播流TLV相同。
o Target TLV(s). The Target TLV MUST appear once per AN port on which the multicast flow identified in the preceding Multicast-Flow TLV is active.
o 目标TLV。目标TLV必须在前一个多播流TLV中标识的多播流处于活动状态的每个端口上出现一次。
The Multicast-Flow TLVs MUST appear in the response from the AN in the same order as in the query from the NAS.
多播流TLV必须以与来自NAS的查询相同的顺序出现在来自AN的响应中。
If the Multicast Flow Query Request message contains no Target TLV and no Multicast Flow TLV, the AN MUST include, for each AN port currently receiving multicast flow(s), the following set of TLVs:
如果多播流查询请求消息不包含目标TLV和多播流TLV，则AN必须为当前接收多播流的每个AN端口包含以下TLV集：
o Target TLV. This MUST identify one AN port.
o 目标TLV。这必须标识一个端口。
o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once per Multicast Flow that is currently active on the AN port identified in the preceding Target TLV.
o 多播流TLV。对于前一个目标TLV中标识的端口上当前处于活动状态的每个多播流，多播流TLV必须出现一次。
If the contents of the Multicast Flow Query Request message are in error, the AN MUST reply with a Multicast Flow Query Response message with the Result field set to Failure (0x4) and the Result Code field set to indicate the nature of the error. If the request contained multiple instances of the Target TLV or the Multicast-Flow TLV and one of these is in error, the response message MUST contain the results for the preceding instances of the TLV as if there had been no error. These successful results MUST be followed by the TLV in error, copied from the request. The AN MUST NOT do further processing of the request. The AN MAY add a Status-Info TLV to provide further information on the nature of the error.
如果多播流查询请求消息的内容出错，AN必须使用多播流查询响应消息进行回复，结果字段设置为Failure（0x4），结果代码字段设置为指示错误的性质。如果请求包含目标TLV或多播流TLV的多个实例，并且其中一个实例出错，则响应消息必须包含TLV先前实例的结果，就像没有错误一样。这些成功的结果之后必须有从请求复制的出错TLV。AN不得对请求进行进一步处理。AN可以添加状态信息TLV，以提供有关错误性质的进一步信息。
This section describes the Committed Bandwidth Report message, which is sent from the AN to the NAS to report the most recent amount of multicast bandwidth usage committed to one or more access lines.
本节描述提交的带宽报告消息，该消息从AN发送到NAS，以报告提交到一条或多条接入线的最新多播带宽使用量。
The Message Type for the Committed Bandwidth Report message is 150.
提交的带宽报告消息的消息类型为150。
The Committed Bandwidth Report message contains one or more instances of the Committed-Bandwidth TLV, as described in Section 5.14.
提交的带宽报告消息包含提交的带宽TLV的一个或多个实例，如第5.14节所述。
The sender of a Committed Bandwidth Report message MUST set the Result field to Ignore (0x0). The Result Code field MUST be set to 0x000. The sender MUST populate the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320].
提交的带宽报告消息的发件人必须将结果字段设置为忽略（0x0）。结果代码字段必须设置为0x000。发送方必须使用唯一值填充ANCP交易标识符字段，如[RFC6320]第3.6.1.6节所述。
Each instance of the Committed-Bandwidth TLV included in the message MUST identify an access line for which the amount of committed multicast bandwidth has changed since the previous Committed Bandwidth Report message was sent and MUST report the latest amount of multicast bandwidth committed to that line. There MUST be only one instance of the Committed-Bandwidth TLV present in the message for any given access line. The message MUST include an instance of the Committed-Bandwidth TLV for every access line for which committed multicast bandwidth has changed since the previous Committed Bandwidth Report message was sent.
消息中包含的已提交带宽TLV的每个实例必须标识自上一个已提交带宽报告消息发送以来已更改的已提交多播带宽量的接入线路，并且必须报告提交到该线路的最新多播带宽量。对于任何给定的访问线路，消息中必须只有一个提交带宽TLV实例。该消息必须包括每个接入线的提交带宽TLV实例，自上一个提交带宽报告消息发送以来，提交的多播带宽已更改。
Further behavior at the AN is specified in Section 6.2.2.
第6.2.2节规定了AN的进一步行为。
The usage of the contents of a Committed Bandwidth Report message received by the NAS is implementation-dependent. One example is that the NAS uses the reports of multicast bandwidth commitments to adjust its forwarding scheduler operation to provide the intended level of QoS.
NAS接收的已提交带宽报告消息内容的使用情况取决于实现。一个例子是，NAS使用多播带宽承诺的报告来调整其转发调度器操作，以提供预期的QoS水平。
The NAS MUST NOT reply to a valid Committed Bandwidth Report message. The NAS MAY send a Generic Response message indicating the nature of any errors detected in a Committed Bandwidth Report message that it has received.
NAS不得回复有效的已提交带宽报告消息。NAS可发送通用响应消息，指示其已接收的提交带宽报告消息中检测到的任何错误的性质。
This section defines new ANCP TLVs for the control of multicast flows.
本节定义了用于控制多播流的新ANCP TLV。
This document defines the new Multicast-Service-Profile TLV.
本文档定义了新的多播服务配置文件TLV。
The Multicast-Service-Profile TLV MAY be included in a Provisioning message as specified in Section 4.1.
如第4.1节所述，多播服务配置文件TLV可包含在供应消息中。
The Multicast-Service-Profile TLV is illustrated in Figure 7. It consists of a TLV header encapsulating a single instance of the Multicast-Service-Profile-Name TLV and one or more instances of the List-Action TLV.
多播服务配置文件TLV如图7所示。它由一个TLV头组成，该头封装了多播服务配置文件名TLV的单个实例和列表操作TLV的一个或多个实例。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Service-Profile 0x0013 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Service-Profile-Name TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Service-Profile 0x0013 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Service-Profile-Name TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Multicast-Service-Profile TLV
图7：多播服务配置文件TLV
The Multicast-Service-Profile TLV has the following fields:
多播服务配置文件TLV具有以下字段：
o TLV Type: 0x0013
o TLV类型：0x0013
o TLV Length: determined by the contents following the TLV header.
o TLV长度：由TLV标题后面的内容确定。
o Multicast-Service-Profile-Name TLV: described in Section 5.2. The Multicast-Service-Profile-Name TLV MUST contain an identifier that is unique over all profiles provisioned to the same AN partition. This identifier will be used to refer to the profile when activating it for a given target within a Port Management message (see Section 4.2).
o 多播服务配置文件名称TLV：如第5.2节所述。多播服务配置文件名称TLV必须包含一个标识符，该标识符在提供给同一分区的所有配置文件中都是唯一的。当在端口管理消息中为给定目标激活配置文件时，此标识符将用于引用配置文件（参见第4.2节）。
o List-Action TLV: described in Section 5.3. The List-Action TLV(s) provide the content of a newly defined multicast service profile or modify the existing content. If more than one List-Action TLV is present, the order of the TLVs may be significant, since List-Action TLVs are processed in the order in which they appear.
o 列出行动TLV：如第5.3节所述。列表操作TLV提供新定义的多播服务配置文件的内容或修改现有内容。如果存在多个列表操作TLV，则TLV的顺序可能很重要，因为列表操作TLV是按照它们出现的顺序处理的。
The Multicast-Service-Profile-Name TLV carries the identifier of a multicast service profile provisioned on the AN. It is illustrated in Figure 8.
多播服务配置文件名称TLV携带在AN上提供的多播服务配置文件的标识符。如图8所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Svc-Profile-Name 0x0018 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Svc-Profile-Name 0x0018 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Multicast-Service-Profile-Name TLV
图8：多播服务配置文件名称TLV
The Multicast-Service-Profile-Name TLV has the following fields:
多播服务配置文件名称TLV包含以下字段：
o TLV Type: 0x0018
o TLV类型：0x0018
o TLV Length: up to 255 octets.
o TLV长度：最多255个八位字节。
o Multicast service profile identifier: an opaque sequence of octets identifying a specific multicast service profile.
o 多播服务配置文件标识符：标识特定多播服务配置文件的不透明八位字节序列。
Note: The identifier could have the form of human-readable text or an arbitrary binary value, depending on the operator's practices.
注意：标识符可以是人类可读的文本形式，也可以是任意的二进制值，具体取决于操作员的实践。
The List-Action TLV identifies multicast flows to be added to or removed from a list of white-, black-, or grey-listed flows. It is meaningful only in association with a Multicast-Service-Profile-Name TLV identifying the profile to which the List-Action TLV applies. Such an association can be achieved by placing both TLVs in the same base message payload or as embedded TLVs of another TLV such as the Multicast-Service-Profile TLV. The List-Action TLV is shown in Figure 9.
列表操作TLV标识要添加到白名单、黑名单或灰名单中或从中删除的多播流。它仅在与标识列表操作TLV应用到的配置文件的多播服务配置文件名称TLV关联时才有意义。这种关联可以通过将两个TLV放置在相同的基本消息有效载荷中或作为另一个TLV（例如多播服务概要文件TLV）的嵌入式TLV来实现。列表操作TLV如图9所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation | List Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation | List Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: List-Action TLV
图9：列表操作TLV
The List-Action TLV contains the following fields:
列表操作TLV包含以下字段：
o TLV Type: 0x0021
o TLV类型：0x0021
o TLV Length: length of the subsequent contents.
o TLV长度：后续内容的长度。
o Operation: operation to be performed upon the white, black, or grey list identified by the List Type field within the profile identified by the associated Multicast-Service-Profile-Name embedded TLV. The possible values are:
o 操作：在由关联的多播服务配置文件名称嵌入TLV标识的配置文件中的列表类型字段标识的白色、黑色或灰色列表上执行的操作。可能的值为：
* 1 "Add": the multicast flow fields are to be added to the list.
* 1“添加”：将多播流字段添加到列表中。
* 2 "Delete": the multicast flow fields are to be removed from the list. Each multicast flow field in the List-Action MUST match exactly an existing entry in the list concerned. Thus, to remove part of the range provided by a wildcarded list entry, it is necessary to remove the entire entry and add back the remaining partial range(s).
* 2“删除”：将从列表中删除多播流字段。列表操作中的每个多播流字段必须与相关列表中的现有条目完全匹配。因此，要删除通配符列表项提供的部分范围，必须删除整个项并添加回剩余的部分范围。
* 3 "Replace": the multicast flow fields replace the existing contents of the list.
* 3“替换”：多播流字段替换列表的现有内容。
o List Type: the list type being modified by this List-Action TLV. The possible values are 1 "White", 2 "Black", or 3 "Grey".
o 列表类型：此列表操作TLV正在修改的列表类型。可能的值为1“白色”、2“黑色”或3“灰色”。
o Reserved: a sender MUST set this field to zeroes. A receiver MUST ignore the contents of this field.
o 保留：发件人必须将此字段设置为零。接收者必须忽略此字段的内容。
o Address Family: the IP version of the set of multicast flow fields that follow, encoded according to [PIMreg]. Possible values are 1 "IPv4" or 2 "IPv6". Either an IPv4 list or an IPv6 list or both MAY be present in the List-Action TLV.
o Address Family：随后的一组多播流字段的IP版本，根据[PIMreg]进行编码。可能的值为1“IPv4”或2“IPv6”。列表操作TLV中可能存在IPv4列表或IPv6列表或两者。
o Number of flow fields: the number of multicast flow fields of the given address family that follows.
o Number of flow fields：后续给定地址族的多播流字段数。
o Multicast flow field: a field identifying one or more multicast flows. It consists of an 8-bit group address prefix length, an 8-bit source address prefix length, a group prefix of 0-16 octets, and a source prefix of 0-16 octets, as shown in Figure 10.
o 多播流字段：标识一个或多个多播流的字段。它由8位组地址前缀长度、8位源地址前缀长度、0-16个八位字节的组前缀和0-16个八位字节的源前缀组成，如图10所示。
Each multicast flow field refers either to a Source-Specific Multicast (SSM) channel or to an Any-Source Multicast (ASM) group. The scope of the designation may be broadened to multiple channels or groups through use of prefix length values smaller than the total address length for the given address family. Multicast flow fields MUST be placed consecutively within the embedded TLV without intervening padding except to round out individual addresses to the nearest octet boundary.
每个多播流域都指向源特定多播（SSM）通道或任意源多播（ASM）组。通过使用小于给定地址族的总地址长度的前缀长度值，可以将指定的范围扩大到多个信道或组。多播流字段必须连续放置在嵌入式TLV中，无需插入填充，除非将单个地址四舍五入到最近的八位字节边界。
A multicast flow field consists of two single-octet prefix lengths followed by zero to two prefix values as shown in Figure 10:
多播流场由两个单八位组前缀长度和0到2个前缀值组成，如图10所示：
+-+-+-+-+-+-+-+-+
| Group PrefLen |
+-+-+-+-+-+-+-+-+
| Source PrefLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Prefix (multicast) (0 to 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Prefix (unicast, SSM only) (0 to 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Group PrefLen |
+-+-+-+-+-+-+-+-+
| Source PrefLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Prefix (multicast) (0 to 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Prefix (unicast, SSM only) (0 to 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Organization of a Single Multicast Flow Field
图10：单个多播流场的组织
The prefix length has its usual meaning. It is the number of most-significant bits specified within the corresponding prefix. The prefix length MAY vary from 0 to 32 in the IPv4 sub-list and from 0 to 128 in the IPv6 sub-list.
前缀长度有其通常的含义。它是在相应前缀中指定的最高有效位数。前缀长度在IPv4子列表中可能从0到32不等，在IPv6子列表中可能从0到128不等。
A value of 0 for either the Group PrefLen (prefix length) or the Source PrefLen indicates that any value of the corresponding address will match (wildcard). If the value 0 is provided for a particular prefix length, the corresponding prefix MUST be omitted from the field contents.
组PrefLen（前缀长度）或源PrefLen的值为0表示相应地址的任何值都将匹配（通配符）。如果为特定前缀长度提供了值0，则必须从字段内容中省略相应的前缀。
The length of a Source or Group Prefix field is equal to (PrefLen + 7)/8 octets, truncated to the nearest integer. Unused bits at the end of the prefix MUST be set to zeroes.
源或组前缀字段的长度等于（PrefLen+7）/8个八位字节，截断为最接近的整数。前缀末尾未使用的位必须设置为零。
The Sequence-Number TLV conveys a sequence number of some sort. The specific meaning of the sequence number is message-specific. Within this specification, the Sequence-Number TLV is used as an embedded TLV in a Status-Info TLV in a Generic Response message reporting a failed command in a Multicast Replication Control or Multicast Admission Request message. It identifies the sequence number within the message of the command that failed.
序列号TLV表示某种序列号。序列号的特定含义是消息特定的。在本规范中，序列号TLV用作通用响应消息中状态信息TLV中的嵌入式TLV，该消息报告多播复制控制或多播许可请求消息中的失败命令。它标识失败命令消息中的序列号。
The Sequence-Number TLV has the format shown in Figure 11.
序列号TLV的格式如图11所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Sequence-Number 0x0022 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Sequence-Number 0x0022 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Sequence-Number TLV
图11：序列号TLV
The Sequence-Number TLV has the following fields:
序列号TLV具有以下字段：
o TLV Type: 0x0022
o TLV类型：0x0022
o TLV Length: 4
o TLV长度：4
o Sequence number: the sequence number of a specific entity within a series, where numbering starts from 1 for the first entity in the series. Represented as a 32-bit binary number, most significant bit first.
o 序列号：序列中特定实体的序列号，序列中第一个实体的编号从1开始。表示为32位二进制数，最高有效位在前。
The Bandwidth-Allocation TLV is used to indicate the total amount of video bandwidth delegated to the AN for multicast admission control for a given access line, in kilobits per second. The TLV has the format shown in Figure 12.
带宽分配TLV用于指示为给定接入线的多播接入控制而委托给AN的视频带宽总量，单位为千比特/秒。TLV的格式如图12所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Bandwidth-Allocation TLV
图12：带宽分配TLV
The Bandwidth-Allocation TLV has the following fields:
带宽分配TLV具有以下字段：
o TLV Type: 0x0015
o TLV类型：0x0015
o TLV Length: 4
o TLV长度：4
o Delegated amount: the bandwidth amount delegated to the AN for admission of multicast video on a given port, kilobits per second. Represented as a 32-bit binary value, most significant bit first.
o 委派量：为在给定端口上允许多播视频而委派给AN的带宽量，千比特/秒。表示为32位二进制值，最高有效位优先。
The White-List-CAC TLV is used to indicate that the NAS wishes the AN to do admission control for white-listed flows. Details on when the White-List-CAC TLV may be provisioned are specified in Section 6. The White-List-CAC TLV is illustrated in Figure 13.
白名单CAC TLV用于指示NAS希望AN对白名单流进行准入控制。第6节规定了何时提供白名单CAC TLV的详细信息。白名单CAC TLV如图13所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = White-List-CAC 0x0024 | TLV Length = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = White-List-CAC 0x0024 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: White-List-CAC TLV
图13：白名单CAC TLV
The White-List-CAC TLV contains the following fields:
白名单CAC TLV包含以下字段：
o TLV Type: 0x0024
o TLV类型：0x0024
o TLV Length: 0, since the TLV contains no data other than the TLV header.
o TLV长度：0，因为TLV不包含除TLV标头以外的任何数据。
The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to do admission control for flows added by the Multicast Replication Control message. Details on when the MRepCtl-CAC TLV may be provisioned are specified in Section 6. The MRepCtl-CAC TLV is illustrated in Figure 14.
MRepCtl CAC TLV用于指示NAS希望AN对多播复制控制消息添加的流进行准入控制。第6节详细说明了何时可以提供MRepCtl CAC TLV。MRepCtl CAC TLV如图14所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = MRepCtl-CAC 0x0025 | TLV Length = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = MRepCtl-CAC 0x0025 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: MRepCtl-CAC TLV
图14:MRepCtl CAC TLV
The MRepCtl-CAC TLV contains the following fields:
MRepCtl CAC TLV包含以下字段：
o TLV Type: 0x0025
o TLV类型：0x0025
o TLV Length: 0, since the TLV contains no data other than the TLV header.
o TLV长度：0，因为TLV不包含除TLV标头以外的任何数据。
The Bandwidth-Request TLV is used to request an adjustment of the total amount of video bandwidth allocated to the AN for multicast admission control for a given line. The "Required amount" field indicates the minimum adjustment required to meet the request. The "Preferred amount" field indicates the adjustment the requestor would prefer to have, if possible. Section 4.5 discusses the required relationships between the "Required amount", "Preferred amount", and current values of total bandwidth allocated to the AN.
带宽请求TLV用于请求调整分配给an的视频带宽总量，以用于给定线路的组播许可控制。“所需金额”字段表示满足请求所需的最小调整。“首选金额”字段表示请求者希望进行的调整（如果可能）。第4.5节讨论了“所需数量”、“首选数量”和分配给AN的总带宽的当前值之间的所需关系。
The Bandwidth-Request TLV has the format shown in Figure 15.
带宽请求TLV的格式如图15所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=Bandwidth-Request 0x0016 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=Bandwidth-Request 0x0016 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Bandwidth-Request TLV
图15：带宽请求TLV
The Bandwidth-Request TLV has the following fields:
带宽请求TLV具有以下字段：
o TLV Type: 0x0016
o TLV类型：0x0016
o TLV Length: 8 octets
o TLV长度：8个八位字节
o Required amount: the minimum or maximum amount, depending on whether the sender is the AN or the NAS respectively, of delegated video bandwidth that is being requested, in kilobits per second. Represented as a 32-bit binary value, most significant bit first.
o Required amount（所需数量）：请求的代理视频带宽的最小或最大数量，具体取决于发送方是AN还是NAS，单位为千比特/秒。表示为32位二进制值，最高有效位优先。
o Preferred amount: the preferred amount of delegated video bandwidth that is being requested, in kilobits per second. Represented as a 32-bit binary value, most significant bit first.
o 首选量：请求的代理视频带宽的首选量，以千比特每秒为单位。表示为32位二进制值，最高有效位优先。
The Request-Source-IP TLV provides the IP address of the entity that originated a specific request to join or leave a multicast channel. The TLV is illustrated in Figure 16.
请求源IP TLV提供发起加入或离开多播信道的特定请求的实体的IP地址。TLV如图16所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Request-Source-IP | TLV Length = 4 or 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Request-Source-IP | TLV Length = 4 or 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Request-Source-IP TLV
图16：请求源IP TLV
The Request-Source-IP TLV contains the following fields:
请求源IP TLV包含以下字段：
o TLV Type: 0x0092
o TLV类型：0x0092
o TLV Length: 4 for an IPv4 address or 16 for an IPv6 address.
o TLV长度：IPv4地址为4，IPv6地址为16。
o Unicast address: IP address of the source of a multicast flow join request, in network byte order.
o 单播地址：多播流加入请求源的IP地址，按网络字节顺序排列。
The Request-Source-MAC TLV provides the MAC address of the entity that originated a specific request to join or leave a multicast channel. The TLV is illustrated in Figure 17.
请求源MAC TLV提供发起加入或离开多播信道的特定请求的实体的MAC地址。TLV如图17所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type=Request-Source-MAC | TLV Length = 6 or 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+- IEEE MAC Address +-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type=Request-Source-MAC | TLV Length = 6 or 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+- IEEE MAC Address +-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Request-Source-MAC TLV
图17：请求源MAC TLV
The Request-Source-MAC TLV contains the following fields:
请求源MAC TLV包含以下字段：
o TLV Type: 0x0093.
o TLV类型：0x0093。
o TLV Length: either 6 octets (MAC-48 or EUI-48) or 8 octets (EUI-64).
o TLV长度：6个八位字节（MAC-48或EUI-48）或8个八位字节（EUI-64）。
o IEEE MAC Address: MAC address of the device originating the request to join a multicast flow. Within the address, bytes and bits, respectively, shall be ordered from most to least significant, consistent with [IEEE48] for MAC-48 and EUI-48 and with [IEEE64] for EUI-64.
o IEEE MAC地址：发起加入多播流请求的设备的MAC地址。在地址中，字节和位应分别从最高有效到最低有效，与MAC-48和EUI-48的[IEEE48]和EUI-64的[IEEE64]一致。
Note: EUI-48 and EUI-64 are registered trademarks of the IEEE.
注：EUI-48和EUI-64是IEEE的注册商标。
The Request-Source-Device-Id TLV provides a local identifier of the entity that originated a specific request to join or leave a multicast channel. The TLV is illustrated in Figure 18.
请求源设备Id TLV提供发起加入或离开多播信道的特定请求的实体的本地标识符。TLV如图18所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-Source-Device-Id | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-Source-Device-Id | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Request-Source-Device-Id TLV
图18：请求源设备Id TLV
The Request-Source-Device-Id TLV contains the following fields:
请求源设备Id TLV包含以下字段：
o TLV Type: 0x0096.
o TLV类型：0x0096。
o TLV Length: 4
o TLV长度：4
o Identifier value: local device identifier value, known to the AN and AAA. Given that the scope of the identifier is a single customer network, 32 bits is a more-than-sufficient numbering space.
o 标识符值：AN和AAA已知的本地设备标识符值。鉴于标识符的范围是单个客户网络，32位是一个足够的编号空间。
IGMPv3 [RFC3376] and MLDv2 [RFC3810] allow multicast listeners to specify multiple source addresses for the same multicast group. Similarly, the Multicast-Flow TLV specifies a multicast flow in terms of its multicast group address and, if applicable, one or more unicast source addresses. The Multicast-Flow TLV is illustrated in Figure 19.
IGMPv3[RFC3376]和MLDv2[RFC3810]允许多播侦听器为同一多播组指定多个源地址。类似地，多播流TLV根据其多播组地址和一个或多个单播源地址（如果适用）来指定多播流。多播流TLV如图19所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Addr Family | Number of Source Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Unicast Source Address (for SSM flows only) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Addr Family | Number of Source Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Unicast Source Address (for SSM flows only) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Multicast-Flow TLV
图19：多播流TLV
The Multicast-Flow TLV has the following fields:
多播流TLV具有以下字段：
o TLV Type: 0x0019
o TLV类型：0x0019
o TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow) upwards. Total length is 4 + 4*(Number of Source Addresses +1) for IPv4 or 4 + 16*(Number of Source Addresses + 1) for IPv6.
o TLV长度：最小范围为8（对于ASM IPv4流）以上。IPv4的总长度为4+4*（源地址数+1），IPv6的总长度为4+16*（源地址数+1）。
o Flow Type: 1 "Any-Source Multicast (ASM)", 2 "Source-Specific Multicast (SSM)".
o 流类型：1“任意源多播（ASM）”，2“源特定多播（SSM）”。
o Addr Family: address family of the multicast source and group addresses, encoded in accordance with the IANA "PIM Address Family" registry ([PIMreg]). 1 indicates IPv4; 2 indicates IPv6.
o Addr系列：多播源地址和组地址的地址系列，根据IANA“PIM地址系列”注册表（[PIMreg]）进行编码。1表示IPv4；2表示IPv6。
o Number of Source Addresses: 0 for ASM, 1 or more for SSM.
o 源地址数：ASM为0，SSM为1或更多。
o Multicast Group Address: a multicast group address within the given address family. The group address MUST always be present.
o 多播组地址：给定地址族中的多播组地址。组地址必须始终存在。
o Unicast Source Address: unicast address within the given address family. If the Flow Type is "ASM" (1), a source address MUST NOT be present. If the Flow Type is "SSM" (2), the number of source addresses given by the Number of Source Addresses field MUST be present.
o 单播源地址：给定地址族中的单播地址。如果流类型为“ASM”（1），则源地址不得存在。如果流类型为“SSM”（2），则源地址数字段给出的源地址数必须存在。
The full versions of IGMPv3 and MLDv2 support both INCLUDE and EXCLUDE modes for specifying the desired sources for SSM flows. The Multicast-Flow TLV supports INCLUDE mode only. [RFC5790] (Lightweight IGMPv3 and MLDv2) provides guidance on converting EXCLUDE mode IGMP/MLD records to INCLUDE mode for the Multicast-Flow TLV.
IGMPv3和MLDv2的完整版本支持包括和排除指定SSM流所需源的模式。多播流TLV仅支持包含模式。[RFC5790]（轻量级IGMPv3和MLDv2）提供了将排除模式IGMP/MLD记录转换为多播流TLV的包含模式的指南。
The Report-Buffering-Time TLV provides the time for which a Committed Bandwidth Report message must be held with the intention of accumulating multiple reports of changed committed multicast bandwidth in one report, to reduce the volume of messages sent to the NAS. For further information see Section 6.2.2. The TLV is illustrated in Figure 20.
报告缓冲时间TLV提供了提交的带宽报告消息必须保持的时间，目的是在一个报告中累积多个已更改提交的多播带宽报告，以减少发送到NAS的消息量。有关更多信息，请参见第6.2.2节。TLV如图20所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report-Buffering-Time 0x0094 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffering Time (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report-Buffering-Time 0x0094 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffering Time (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Report-Buffering-Time TLV
图20：报告缓冲时间TLV
The Report-Buffering-Time TLV contains the following fields:
报告缓冲时间TLV包含以下字段：
o TLV Type: 0x0094
o TLV类型：0x0094
o TLV Length: 4 octets
o TLV长度：4个八位字节
o Buffering Time is a 32-bit unsigned integer containing a time value in milliseconds (ms).
o 缓冲时间是一个32位无符号整数，包含以毫秒（ms）为单位的时间值。
The Committed-Bandwidth TLV identifies an access line and provides the current amount of multicast bandwidth that the AN has committed to it. The TLV is illustrated in Figure 21.
提交的带宽TLV标识接入线，并提供an已提交给它的当前多播带宽量。TLV如图21所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed-Bandwidth 0x0095 | TLV Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Multicast Bandwidth (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Target TLV ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed-Bandwidth 0x0095 | TLV Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Multicast Bandwidth (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Target TLV ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Committed-Bandwidth TLV
图21：提交的带宽TLV
The Committed-Bandwidth TLV contains the following fields:
提交的带宽TLV包含以下字段：
o TLV Type: 0x0095
o TLV类型：0x0095
o TLV Length: 4 octets plus the length of the Target TLV, including its header and any padding.
o TLV长度：4个八位字节加上目标TLV的长度，包括其头部和任何填充。
o Committed Multicast Bandwidth: a 32-bit unsigned integer providing a bandwidth amount in kbits/s.
o 提交的多播带宽：一个32位无符号整数，提供以kbit/s为单位的带宽量。
o Target TLV: identifies the access line to which this amount of multicast bandwidth is currently committed.
o 目标TLV：标识当前提交此数量的多播带宽的接入线。
Section 3.5 of [RFC6320] defines a capability negotiation mechanism as well as a number of capabilities. This section defines five new capabilities in support of different modes of multicast operation:
[RFC6320]第3.5节定义了一种能力协商机制以及一系列能力。本节定义了支持不同多播操作模式的五种新功能：
o NAS-initiated multicast replication (capability type 3);
o NAS启动的多播复制（能力类型3）；
o committed bandwidth reporting (capability type 5);
o 承诺带宽报告（能力类型5）；
o conditional access and admission control with white and black lists (capability type 6);
o 具有白名单和黑名单的条件接收和接纳控制（能力类型6）；
o conditional access and admission control with grey lists (capability type 7); and
o 具有灰色列表的条件接收和接纳控制（能力类型7）；和
o bandwidth delegation (capability type 8).
o 带宽委派（能力类型8）。
The "Capability Data" field within the Capability TLV for all of these capabilities is empty. All of these capabilities are independent of the access technology.
所有这些能力的能力TLV中的“能力数据”字段为空。所有这些功能都独立于接入技术。
The remainder of this section consists of three sub-sections. Section 6.1 specifies the protocol elements that must be implemented in order to support each capability. Section 6.2 specifies the procedures that apply to each capability on its own. Section 6.3 specifies how the capabilities interact if more than one multicast capability is included in the set of capabilities negotiated between the AN and the NAS.
本节其余部分由三个小节组成。第6.1节规定了为支持每种能力而必须实施的协议元素。第6.2节规定了适用于每种能力的程序。第6.3节规定了在AN和NAS之间协商的一组功能中包含多个多播功能时，这些功能如何交互。
This section specifies the protocol elements that MUST be implemented to support each of the five multicast capabilities. Support of multiple multicast capabilities requires implementation of the union of the sets of protocol elements applying to each of the individual capabilities in the supported set.
本节指定必须实现的协议元素，以支持五种多播功能中的每一种。支持多个多播功能需要实现协议元素集的并集，该协议元素集应用于支持集中的每个单独功能。
In addition to the elements listed below, implementation of the Target TLV (Section 4.3 of [RFC6320]) is REQUIRED for all of the capabilities specified in this document.
除以下列出的要素外，本文件规定的所有能力都需要实现目标TLV（RFC6320第4.3节）。
Table 1 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the NAS-initiated multicast replication capability. Additionally, implementation of the Multicast Replication Control message requires implementation of the Command TLV (Section 4.4 of [RFC6320] with additional details in Section 4.3 of this document).
表1指定了第4节和第5节中必须实现的协议元素，以支持NAS启动的多播复制功能。此外，多播复制控制消息的实现需要实现命令TLV（RFC6320第4.4节，本文件第4.3节有更多详细信息）。
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with MRepCtl-CAC TLV |
| | |
| Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV |
| | |
| Section 4.3 | Multicast Replication Control message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.4 | Sequence Number TLV |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.7 | MRepCtl-CAC TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with MRepCtl-CAC TLV |
| | |
| Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV |
| | |
| Section 4.3 | Multicast Replication Control message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.4 | Sequence Number TLV |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.7 | MRepCtl-CAC TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 1: Protocol Requirements for NAS-Initiated Multicast Replication
表1：NAS启动的多播复制的协议要求
6.1.2. Protocol Requirements for Committed Multicast Bandwidth Reporting
6.1.2. 提交多播带宽报告的协议要求
Table 2 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the committed multicast bandwidth reporting capability.
表2指定了第4节和第5节中必须实现的协议元素，以支持提交的多播带宽报告功能。
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Report-Buffering-Time |
| | TLV |
| | |
| Section 4.10 | Committed Bandwidth Report message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.13 | Report-Buffering-Timer TLV |
| | |
| Section 5.14 | Committed-Bandwidth TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Report-Buffering-Time |
| | TLV |
| | |
| Section 4.10 | Committed Bandwidth Report message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.13 | Report-Buffering-Timer TLV |
| | |
| Section 5.14 | Committed-Bandwidth TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 2: Protocol Requirements for Committed Multicast Bandwidth Reporting
表2：提交的多播带宽报告的协议要求
6.1.3. Protocol Requirements for Conditional Access and Admission Control with White and Black Lists
6.1.3. 具有白名单和黑名单的条件接收和接纳控制协议要求
Table 3 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the conditional access and admission control with white and black lists multicast capability.
表3规定了第4节和第5节中必须实现的协议元素，以支持具有白名单和黑名单多播能力的条件接收和接纳控制。
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Multicast-Service- |
| | Profile TLV, white and black lists only, and |
| | White-List-CAC TLV |
| | |
| Section 4.2 | Port Management message with Multicast-Service- |
| | Profile-Name and Bandwidth-Allocation TLVs |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.1 | Multicast-Service-Profile TLV |
| | |
| Section 5.2 | Multicast-Service-Profile-Name TLV |
| | |
| Section 5.3 | List-Action TLV, white and black lists only |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.6 | White-List-CAC TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Multicast-Service- |
| | Profile TLV, white and black lists only, and |
| | White-List-CAC TLV |
| | |
| Section 4.2 | Port Management message with Multicast-Service- |
| | Profile-Name and Bandwidth-Allocation TLVs |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.1 | Multicast-Service-Profile TLV |
| | |
| Section 5.2 | Multicast-Service-Profile-Name TLV |
| | |
| Section 5.3 | List-Action TLV, white and black lists only |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.6 | White-List-CAC TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 3: Protocol Requirements for Conditional Access and Admission Control with White and Black Lists
表3：白名单和黑名单条件接收和接纳控制的协议要求
6.1.4. Protocol Requirements for Conditional Access and Admission Control with Grey Lists
6.1.4. 带灰色列表的条件接收和接纳控制协议要求
Table 4 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the conditional access and admission control with grey lists multicast capability. Additionally, implementation of the Multicast Replication Control message requires implementation of the Command TLV (Section 4.4 of [RFC6320] with additional details in Section 4.3 of this document).
表4规定了第4节和第5节中必须实现的协议元素，以支持具有灰名单多播能力的条件接收和接纳控制。此外，多播复制控制消息的实现需要实现命令TLV（RFC6320第4.4节，本文件第4.3节有更多详细信息）。
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Multicast-Service- |
| | Profile TLV, grey lists only, and MRepCtl-CAC TLV |
| | |
| Section 4.2 | Port Management message with Multicast-Service- |
| | Profile-Name and Bandwidth-Allocation TLVs |
| | |
| Section 4.3 | Multicast Replication Control message |
| | |
| Section 4.4 | Multicast Admission Control message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.1 | Multicast-Service-Profile TLV, grey lists only |
| | |
| Section 5.2 | Multicast-Service-Profile-Name TLV |
| | |
| Section 5.3 | List-Action TLV, grey lists only |
| | |
| Section 5.4 | Sequence Number TLV |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.7 | MRepCtl-CAC TLV |
| | |
| Section 5.9 | Request-Source-IP TLV |
| | |
| Section 5.10 | Request-Source-MAC TLV |
| | |
| Section 5.11 | Request-Source-Device-Id TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Multicast-Service- |
| | Profile TLV, grey lists only, and MRepCtl-CAC TLV |
| | |
| Section 4.2 | Port Management message with Multicast-Service- |
| | Profile-Name and Bandwidth-Allocation TLVs |
| | |
| Section 4.3 | Multicast Replication Control message |
| | |
| Section 4.4 | Multicast Admission Control message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.1 | Multicast-Service-Profile TLV, grey lists only |
| | |
| Section 5.2 | Multicast-Service-Profile-Name TLV |
| | |
| Section 5.3 | List-Action TLV, grey lists only |
| | |
| Section 5.4 | Sequence Number TLV |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.7 | MRepCtl-CAC TLV |
| | |
| Section 5.9 | Request-Source-IP TLV |
| | |
| Section 5.10 | Request-Source-MAC TLV |
| | |
| Section 5.11 | Request-Source-Device-Id TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 4: Protocol Requirements for Conditional Access and Admission Control with Grey Lists
表4：带有灰色列表的条件接收和接纳控制协议要求
Table 5 specifies the protocol elements within Section 4 and Section 5 that MUST be implemented to support the bandwidth delegation capability.
表5规定了第4节和第5节中必须实现的协议元素，以支持带宽委派能力。
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV |
| | |
| Section 4.5 | Bandwidth Reallocation Request message |
| | |
| Section 4.6 | Bandwidth Transfer message |
| | |
| Section 4.7 | Delegated Bandwidth Query Request message |
| | |
| Section 4.8 | Delegated Bandwidth Query Response message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.8 | Bandwidth-Request TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV |
| | |
| Section 4.5 | Bandwidth Reallocation Request message |
| | |
| Section 4.6 | Bandwidth Transfer message |
| | |
| Section 4.7 | Delegated Bandwidth Query Request message |
| | |
| Section 4.8 | Delegated Bandwidth Query Response message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.8 | Bandwidth-Request TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 5: Protocol Requirements for Bandwidth Delegation
表5：带宽委派的协议要求
This section describes multicast service procedures for each capability as if it were the only multicast capability within the negotiated set. Procedures involving combinations of multicast capabilities are described in Section 6.3.
本节描述每个功能的多播服务过程，就好像它是协商集内唯一的多播功能一样。第6.3节描述了涉及多播功能组合的程序。
The use of the Multicast Flow Query Request and Response messages to determine the association between multicast flows and ports is common to all multicast capabilities. No additional text is required here, beyond that already given in Section 4.9 to describe the use of those messages.
使用多播流查询请求和响应消息来确定多播流和端口之间的关联对于所有多播功能都是通用的。除第4.9节中已经给出的文本外，此处不需要额外的文本来描述这些消息的使用。
NAS-initiated multicast replication may be negotiated to support a mode of operation where IGMP/MLD requests are terminated on the NAS. Alternatively, it may be negotiated to allow the NAS to respond to requests sent by other means (e.g., through application signaling) that require the replication of multicast channels to a given access line.
NAS发起的多播复制可以协商以支持在NAS上终止IGMP/MLD请求的操作模式。或者，可以协商以允许NAS响应通过其他方式（例如，通过应用信令）发送的请求，这些方式要求将多播信道复制到给定的接入线。
The NAS MAY perform admission control for NAS-initiated replication. In this case, it MUST NOT include the MRepCtl-CAC TLV in a Provisioning message sent to the AN. Alternatively, the NAS MAY enable admission control at the AN for NAS-initiated multicast replication. To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the AN, and it MUST also include a Bandwidth-Allocation TLV in a Port Management message for each access line.
NAS可以对NAS启动的复制执行许可控制。在这种情况下，它不能在发送到AN的配置消息中包含MRepCtl CAC TLV。或者，NAS可以在AN处为NAS发起的多播复制启用准入控制。为此，它必须在发送到AN的配置消息中包含MRepCtl CAC TLV，并且还必须在每个接入线的端口管理消息中包含带宽分配TLV。
The procedures associated with NAS-initiated multicast replication are straightforward. To initiate replication, the NAS MUST send a Multicast Replication Control message to the AN, containing one or more commands adding flows, as described in Section 4.3.1. To terminate replication, the NAS MUST send a Multicast Replication Control message where the commands delete instead of adding the flows. The AN acts upon these messages as specified in Section 4.3.2.
与NAS启动的多播复制相关的过程非常简单。要启动复制，NAS必须向AN发送多播复制控制消息，其中包含一个或多个添加流的命令，如第4.3.1节所述。要终止复制，NAS必须发送一条多播复制控制消息，其中命令将删除而不是添加流。AN根据第4.3.2节的规定对这些信息进行操作。
Committed bandwidth reporting may be negotiated if the NAS requires current knowledge of the amount of multicast bandwidth committed to each access line and cannot obtain this information by other means.
如果NAS要求当前了解每个接入线的多播带宽量，并且无法通过其他方式获得该信息，则可以协商提交的带宽报告。
The default buffering time when committed bandwidth reporting is enabled is zero (immediate reporting). To change this, the NAS MAY send an instance of the Report-Buffering-Time TLV containing a non-zero time value to the AN in a Provisioning message. If the NAS subsequently wishes to change the buffering time again, it MAY do so in another Provisioning message.
启用提交带宽报告时的默认缓冲时间为零（立即报告）。要改变这一点，NAS可以在配置消息中向an发送包含非零时间值的报告缓冲时间TLV实例。如果NAS随后希望再次更改缓冲时间，则可以在另一条设置消息中进行更改。
If the buffering time for committed bandwidth reporting is zero, the AN MUST send a Committed Bandwidth Report message to the NAS each time the amount of multicast bandwidth committed to any access line under its control changes.
如果提交带宽报告的缓冲时间为零，则AN必须在每次提交到其控制下的任何接入线的多播带宽量发生变化时向NAS发送提交带宽报告消息。
If a non-zero value is provided in the Report-Buffering-Time TLV, the AN is in one of two states at any given moment: not-buffering or buffering. The AN enters buffering state if it is in not-buffering state and the multicast bandwidth amount committed to some access line changes. It leaves buffering state when the AN sends a Committed Bandwidth Report message.
如果报告缓冲时间TLV中提供了非零值，则AN在任何给定时刻处于两种状态之一：不缓冲或缓冲。如果AN处于非缓冲状态，并且提交给某些接入线的多播带宽量发生变化，则AN将进入缓冲状态。当AN发送提交的带宽报告消息时，它将离开缓冲状态。
Upon entry to the buffering state, the AN MUST start a buffering timer and create a Committed Bandwidth Report message containing a Committed-Bandwidth TLV for the triggering access line, but it MUST NOT send it. If a multicast bandwidth change occurs for another access line, the AN MUST add a new Committed-Bandwidth TLV to the message for that additional line. If a multicast bandwidth change occurs for a line for which a Committed-Bandwidth TLV is already present in the buffered report, the AN MUST update the corresponding Committed-Bandwidth TLV to contain the new bandwidth value rather than adding another Committed-Bandwidth TLV for the same access line.
进入缓冲状态后，AN必须启动缓冲计时器并创建包含触发访问线的已提交带宽TLV的已提交带宽报告消息，但它不得发送该消息。如果另一条接入线的多播带宽发生变化，AN必须为该额外线路的消息添加新的提交带宽TLV。如果缓存报告中已存在提交带宽TLV的线路发生多播带宽更改，AN必须更新相应的提交带宽TLV以包含新带宽值，而不是为同一接入线路添加另一个提交带宽TLV。
The buffering timer expires after the period provided by the Report-Buffering-Time TLV. When it expires, the AN MUST send the Committed Bandwidth Report message that it has been accumulating to the NAS. Exceptionally, the AN MAY choose to send the message before the timer expires, in which case it MUST clear the buffering timer when the message is sent. In either case, the AN enters the not-buffering state as a result.
缓冲计时器在报告缓冲时间TLV提供的时间段后过期。到期时，AN必须向NAS发送其已累积的已提交带宽报告消息。例外情况下，AN可以选择在计时器到期之前发送消息，在这种情况下，它必须在发送消息时清除缓冲计时器。在任何一种情况下，AN都会因此进入非缓冲状态。
Note: Report buffering implies that NAS reaction to changes in multicast bandwidth usage is delayed by the amount of the buffering period. The choice of buffering period must take this into consideration.
注意：报告缓冲意味着NAS对多播带宽使用变化的反应会延迟缓冲期的长度。缓冲期的选择必须考虑到这一点。
6.2.3. Procedures for Conditional Access and Admission Control with Black and White Lists
6.2.3. 黑白名单条件接收和准入控制程序
The NAS provisions named multicast service profiles containing white and black lists on the AN using the Provisioning message containing one or more Multicast-Service-Profile TLVs. The NAS MAY update the contents of these profiles from time to time as required by sending
NAS规定使用包含一个或多个多播服务配置文件TLV的设置消息在AN上命名多播服务配置文件，其中包含白名单和黑名单。NAS可根据需要随时更新这些配置文件的内容，发送
additional Provisioning messages with Multicast-Service-Profile TLVs containing incremental modifications to the existing white and black lists or replacements for them.
具有多播服务配置文件TLV的附加配置消息，包含对现有白名单和黑名单的增量修改或替换。
The NAS assigns a specific multicast service profile to an individual access line using the Port Management message containing a Multicast-Service-Profile-Name TLV. The NAS MAY change the multicast service profile for a given access line at any time by sending a Port Management message identifying a new multicast service profile.
NAS使用包含多播服务配置文件名称TLV的端口管理消息将特定多播服务配置文件分配给单个接入线路。NAS可以通过发送标识新的多播服务配置文件的端口管理消息，随时更改给定接入线的多播服务配置文件。
The NAS MAY choose to enable admission control at the AN for white-listed flows. To do this, it MUST send a Provisioning message as described in Section 4.1, which includes the White-List-CAC TLV, and it MUST provide a multicast bandwidth allocation for each access line by including a Bandwidth-Allocation TLV in a Port Management message.
NAS可以选择在AN启用白名单流的准入控制。为此，它必须发送第4.1节所述的配置消息，其中包括白名单CAC TLV，并且它必须通过在端口管理消息中包括带宽分配TLV，为每条接入线提供多播带宽分配。
The conditional access and admission control with white and black lists capability assumes that IGMP/MLD requests are terminated on the AN. When the AN receives a join request, it MUST check to see whether the requested flow is white-listed or black-listed as described below. Requests for black-listed flows MUST be discarded. If the NAS has enabled admission control on the AN as described in the previous section, but a white-listed flow would cause the amount of committed multicast bandwidth to exceed the provisioned limit, the request MUST be discarded. The AN replicates flows passing these checks to the access line.
具有白名单和黑名单功能的条件接收和接纳控制假定IGMP/MLD请求在AN上终止。当AN接收到加入请求时，它必须检查请求的流是白名单还是黑名单，如下所述。必须放弃对黑名单流的请求。如果NAS如前一节所述在AN上启用了准入控制，但白名单流将导致提交的多播带宽量超过设置的限制，则必须放弃该请求。AN复制将这些检查传递到访问线的流。
To determine if a requested flow is white-listed, the AN searches for a best match to the flow in the applicable multicast service profile. Matching is done on the prefixes specified in the profile, ignoring the address bits of lower order than those in the prefix.
要确定请求的流是否为白名单，AN将在适用的多播服务配置文件中搜索与该流的最佳匹配。在配置文件中指定的前缀上进行匹配，忽略比前缀中的地址位低的地址位。
If the requested multicast flow matches multiple lists associated with the access line, then the most specific match will be considered by the AN. If the most specific match occurs in multiple lists, the black list entry takes precedence over the white list. In this context, the most specific match is defined as:
如果请求的多播流匹配与接入线路相关联的多个列表，则AN将考虑最具体的匹配。如果最具体的匹配出现在多个列表中，则黑名单条目优先于白名单条目。在此上下文中，最具体的匹配定义为：
o first, most specific match (longest prefix length) on the multicast group address (i.e., on G of <S,G>), and
o 首先，在多播组地址（即，在<S，G>的G上）上的最特定匹配（最长前缀长度），以及
o then, most specific match (longest prefix length) on the unicast source address (i.e., on S of <S,G>).
o 然后，在单播源地址（即，在<S，G>的S上）上进行最特定的匹配（最长前缀长度）。
If the requested multicast flow is not part of any list, the join message SHOULD be discarded by the AN. This default behavior can easily be changed by means of a "catch-all" statement in the white list. For instance, adding (<S=*,G=*>) in the white List would make the default behavior to accept join messages for a multicast flow that has no other match on any list.
如果请求的多播流不是任何列表的一部分，则AN应丢弃加入消息。此默认行为可以通过白名单中的“catch all”语句轻松更改。例如，在白名单中添加（<S=*，G=*>）将使默认行为接受任何列表上没有其他匹配项的多播流的加入消息。
When the AN receives a leave request, it terminates replication of the multicast flow.
当AN收到离开请求时，它终止多播流的复制。
If the AN receives a Provisioning message that updates an existing multicast service profile, the AN MUST review the status of active flows on all ports to which the updated profile is currently assigned. Similarly, if a Port Management message assigns a new multicast service profile to a given port, the AN MUST review all active flows on that port. If the most specific match for any flow is a black list entry, the flow MUST be terminated immediately. If any of the remaining flows do not match an entry in the white list, they also MUST be terminated immediately. White-listed flows MUST be allowed to continue.
如果AN接收到更新现有多播服务配置文件的设置消息，则AN必须查看更新的配置文件当前分配到的所有端口上的活动流的状态。类似地，如果端口管理消息将新的多播服务配置文件分配给给定端口，则AN必须查看该端口上的所有活动流。如果任何流的最特定匹配项是黑名单条目，则必须立即终止该流。如果任何剩余流与白名单中的条目不匹配，也必须立即终止。必须允许白名单上的流继续。
6.2.4. Procedures for Conditional Access and Admission Control with Grey Lists
6.2.4. 使用灰色列表的条件接收和接纳控制程序
The NAS provisions named multicast service profiles containing grey lists on the AN using the Provisioning message containing one or more Multicast-Service-Profile TLVs. The NAS MAY update the contents of these profiles from time to time as required by sending additional Provisioning messages with Multicast-Service-Profile TLVs containing incremental modifications to the existing grey lists or replacements for them.
NAS规定使用包含一个或多个多播服务配置文件TLV的设置消息在AN上命名为多播服务配置文件，其中包含灰色列表。NAS可根据需要不时更新这些配置文件的内容，方法是使用多播服务配置文件TLV发送额外的供应消息，其中包含对现有灰色列表的增量修改或替换。
The NAS assigns a specific multicast service profile to an individual access line using the Port Management message containing a Multicast-Service-Profile-Name TLV. The NAS MAY change profiles on the line by sending a subsequent Port Management message identifying a new profile.
NAS使用包含多播服务配置文件名称TLV的端口管理消息将特定多播服务配置文件分配给单个接入线路。NAS可以通过发送标识新配置文件的后续端口管理消息来更改线路上的配置文件。
The NAS MAY perform admission control for grey-listed flows. In that case, the NAS MUST NOT include the MRepCtl-CAC TLV in a Provisioning message sent to the AN. Alternatively, the NAS MAY enable admission control at the AN for grey-listed flows. To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST also provide a Bandwidth-Allocation TLV in a Port Management message for each access line.
NAS可对灰色列表流执行准入控制。在这种情况下，NAS不得将MRepCtl CAC TLV包含在发送到AN的配置消息中。或者，NAS可以在AN处启用灰色列表流的准入控制。为此，它必须在发送到AN的配置消息中包含MRepCtl CAC TLV，并且还必须在每个接入线的端口管理消息中提供带宽分配TLV。
The conditional access and admission control with grey lists capability assumes that IGMP/MLD requests are terminated on the AN. When the AN receives a join request, it MUST determine whether there is a match to the requested flow in the grey list of the multicast service profile provisioned against the given access line. If there is no match, the request is discarded. Otherwise, the AN MUST send a Multicast Admission Control message to the NAS with content identifying the access line and the multicast flow to be added. As indicated in Section 4.4, the AN MAY add information identifying the requesting device.
具有灰名单功能的条件接收和接纳控制假定IGMP/MLD请求在AN上终止。当AN接收到加入请求时，它必须确定在针对给定接入线提供的多播服务配置文件的灰色列表中是否存在与请求流的匹配。如果没有匹配项，则丢弃请求。否则，AN必须向NAS发送一条多播接纳控制消息，其中包含标识接入线路和要添加的多播流的内容。如第4.4节所述，AN可添加识别请求设备的信息。
If the NAS decides to enable the flow, it MUST send a Multicast Replication Control message to the AN to replicate the flow to the access line with the Result field set to Nack (0x1), as described in Section 4.3.1.
如果NAS决定启用流，则必须向AN发送多播复制控制消息，以将流复制到接入线路，结果字段设置为Nack（0x1），如第4.3.1节所述。
When the AN receives the Multicast Replication Control message, it performs admission control if that has been enabled as described in the previous section. If admitting the flow would cause the committed multicast bandwidth at the access line to exceed the provisioned limit, the AN reports an error to the NAS as described in Section 4.3.2. Otherwise, it replicates the multicast flow as requested.
当AN接收到多播复制控制消息时，如果如前一节所述已启用，它将执行准入控制。如果接纳该流会导致接入线路上提交的多播带宽超过规定的限制，则AN会向NAS报告错误，如第4.3.2节所述。否则，它会根据请求复制多播流。
If the NAS decides not to permit the flow, it MAY send a Multicast Replication Control message in response to the Multicast Admission Control message to allow the AN to update its internal records. The content of this message is described in Section 4.4.2.
如果NAS决定不允许该流，它可以发送多播复制控制消息来响应多播许可控制消息，以允许AN更新其内部记录。第4.4.2节描述了该信息的内容。
When the AN receives a leave request, it MUST terminate replication of the flow to the access line. It MUST then send a Multicast Admission Control message to the NAS indicating the deletion. The NAS updates its internal records but MUST NOT respond to the message.
当AN收到请假请求时，它必须终止流到访问线路的复制。然后，它必须向NAS发送一条指示删除的多播接纳控制消息。NAS更新其内部记录，但不得响应该消息。
If the AN receives a Provisioning message that updates an existing multicast service profile, the AN MUST review the status of active flows on all ports to which the updated profile has been assigned. Similarly, if the AN receives a Port Management message that assigns a new profile to a given port, the AN MUST review all active flows on that port. In either case, if any flow does not match an entry in the grey list, it MUST be terminated immediately.
如果AN接收到更新现有多播服务配置文件的设置消息，则AN必须查看已将更新的配置文件分配到的所有端口上的活动流的状态。类似地，如果AN接收到将新配置文件分配给给定端口的端口管理消息，则AN必须查看该端口上的所有活动流。在这两种情况下，如果任何流与灰色列表中的条目不匹配，则必须立即终止。
The NAS SHOULD provision an initial amount of delegated multicast bandwidth for each access line using the Port Management message containing the Bandwidth-Allocation TLV.
NAS应使用包含带宽分配TLV的端口管理消息为每条接入线提供初始委托多播带宽。
Note: If it fails to do so and a value has not been provisioned on the AN by other means, the AN will be forced to request a bandwidth allocation as soon as it receives a join request.
注意：如果未能这样做，并且未通过其他方式在AN上设置值，则AN将在收到加入请求后立即强制请求带宽分配。
The NAS MAY, at any time, force an update of the amount of delegated bandwidth by the same means.
NAS可以在任何时候通过相同的方式强制更新委派带宽的数量。
The bandwidth delegation capability assumes that IGMP/MLD requests are terminated on the AN. When the AN receives a join request, it checks whether it has sufficient remaining uncommitted multicast bandwidth on the access line to accommodate the new multicast flow. If not, it MAY send a request to the NAS for an increased allocation of delegated bandwidth using the Bandwidth Reallocation Request message. The NAS MUST return a Bandwidth Transfer message indicating whether it has granted the request and, if so, the new amount of delegated bandwidth.
带宽委派功能假定IGMP/MLD请求在AN上终止。当AN接收到加入请求时，它会检查接入线上是否有足够的剩余未提交多播带宽来容纳新的多播流。如果没有，它可以使用带宽重新分配请求消息向NAS发送请求，以增加委派带宽的分配。NAS必须返回带宽传输消息，指示其是否已批准请求，如果已批准，则指示新的委派带宽量。
If the AN has sufficient uncommitted multicast capacity to admit the request, either originally or as the result of a successful request to the NAS, it replicates the requested flow to the access line. Otherwise, it discards the request.
如果AN有足够的未提交多播容量来接纳请求，无论是最初还是成功请求NAS的结果，它都会将请求的流复制到接入线路。否则，它将丢弃该请求。
When the AN receives a leave request for an active flow, it ceases replication.
当AN收到活动流的离开请求时，它停止复制。
The NAS or AN MAY, at some point, detect that their respective views of the amount of delegated bandwidth are inconsistent. If so, they can recover using procedures described in Sections 4.5 and 4.6. As a further aid to synchronization, either the NAS or the AN MAY from time to time check the peer's view of the amount of delegated bandwidth using the Delegated Bandwidth Query message.
NAS或AN可能在某一点上检测到其各自对委派带宽量的看法不一致。如果是这样，他们可以使用第4.5节和第4.6节中描述的程序进行恢复。作为对同步的进一步帮助，NAS或AN可不时使用委派带宽查询消息检查对等方对委派带宽量的看法。
The NAS or AN MAY, at any time, release bandwidth to the peer using an autonomous Bandwidth Transfer message. The contents of this message are described in Section 4.6.
NAS或AN可随时使用自主带宽传输消息向对等方释放带宽。第4.6节介绍了该信息的内容。
6.3.1. Combination of Conditional Access and Admission Control with White and Black Lists and Conditional Access and Admission Control with Grey Lists
6.3.1. 将条件接收和接纳控制与白名单和黑名单以及条件接收和接纳控制与灰名单相结合
If conditional access and admission control with white and black lists is combined with conditional access and admission control with grey lists, provisioning of the multicast service profiles is as described in Section 6.2.3.1 except that multicast service profiles will also include grey lists. Admission control is enabled independently on the AN for white lists by including the White-List-CAC TLV in the Provisioning message and for grey lists by including the MRepCtl-CAC TLV in the Provisioning message. The Bandwidth-Allocation TLV provisions an amount that applies to both white- and grey-listed flows if admission control is enabled for both.
如果带有白名单和黑名单的条件接收和接纳控制与带有灰色列表的条件接收和接纳控制相结合，则多播服务配置文件的提供如第6.2.3.1节所述，但多播服务配置文件也将包括灰色列表。通过在设置消息中包含白名单CAC TLV，在AN上独立启用准入控制；对于灰名单，通过在设置消息中包含MRepCtl CAC TLV，在AN上独立启用准入控制。带宽分配TLV规定了一个适用于白名单流和灰名单流的量，前提是两者都启用了准入控制。
With regard to multicast service procedures, one point of difference from the individual capabilities must be noted. This is an interaction during the profile matching procedure. The AN MUST seek the best match among multiple lists as described in Section 6.2.3.2. However, if there are multiple matches of equal precision, the order of priority is black list first, grey list second, and white list last.
关于多播服务过程，必须注意与单个功能的一点差异。这是配置文件匹配过程中的交互。AN必须在第6.2.3.2节所述的多个列表中寻找最佳匹配。但是，如果存在多个精度相同的匹配，则优先级顺序为黑名单第一，灰名单第二，白名单最后。
Once profile matching has been completed, processing of a join request is as described in Section 6.2.3.2 for white- or black-listed flows or Section 6.2.4.2 for grey-listed flows. Requests that do not match any list SHOULD be discarded.
一旦配置文件匹配完成，连接请求的处理如第6.2.3.2节（白名单或黑名单流）或第6.2.4.2节（灰名单流）所述。应丢弃与任何列表不匹配的请求。
When the AN receives a leave request, it MUST terminate replication of the flow to the access line. If the flow was grey-listed, the AN MUST then send a Multicast Admission Control message to the NAS indicating the deletion.
当AN收到请假请求时，它必须终止流到访问线路的复制。如果流为灰色列表，则AN必须随后向NAS发送一条指示删除的多播接纳控制消息。
If the AN receives a Provisioning message that updates an existing multicast service profile, the AN MUST review the status of active flows on all ports to which the updated profile is currently assigned. Similarly, if a Port Management message assigns a new multicast service profile to a given port, the AN MUST review all active flows on that port. If any flow has its most specific match in a black list entry, it MUST be terminated immediately. If any of the remaining flows do not match an entry in the white or grey list, they MUST also be terminated immediately. Finally, if any remaining flows were originally admitted because they were white-listed but after the change they are grey-listed, the AN MUST generate a Multicast Flow Query Response message autonomously as if it were responding to a Multicast Flow Query Request message, listing all
如果AN接收到更新现有多播服务配置文件的设置消息，则AN必须查看更新的配置文件当前分配到的所有端口上的活动流的状态。类似地，如果端口管理消息将新的多播服务配置文件分配给给定端口，则AN必须查看该端口上的所有活动流。如果任何流在黑名单条目中有其最特定的匹配项，则必须立即终止。如果任何剩余流与白名单或灰名单中的条目不匹配，也必须立即终止。最后，如果任何剩余的流最初被允许，因为它们是白名单，但在更改后它们是灰名单，AN必须自动生成一个多播流查询响应消息，就像它在响应一个多播流查询请求消息一样，列出所有流
such flows. These flows MUST be allowed to continue until the NAS or the subscriber terminates them. Flows with their most specific match in the white list MUST be allowed to continue.
这种流动。必须允许这些流继续，直到NAS或订阅服务器终止它们。必须允许白名单中最具体匹配的流继续。
The autonomously generated Multicast Flow Query Response message MUST be formatted as if it were a successful response to a request containing no Target and no Multicast-Flow TLV, as described in Section 4.9.2, with the exception that the Transaction Identifier field MUST be set to all zeroes.
如第4.9.2节所述，自主生成的多播流查询响应消息的格式必须如同它是对不包含目标和多播流TLV的请求的成功响应一样，但事务标识符字段必须设置为全零。
Note: The procedures in the previous paragraphs imply that the AN has to retain a memory of whether an admitted flow was white-listed or grey-listed at the time of its admission/readmission.
注：前几段中的程序意味着AN必须保留一个内存，以记录在接纳/重新接纳时接纳的流量是白名单还是灰名单。
6.3.2. Combination of Conditional Access and Admission Control with Bandwidth Delegation
6.3.2. 带带宽委托的条件接收和接纳控制的组合
The provisioning and bandwidth management procedures of Section 6.2.5 apply in addition to the procedures in Sections 6.2.3, 6.2.4, or 6.3.1 as applicable. Conditional access follows the rules given in those sections in terms of matching flows against white and black and/or grey lists. When admission control is enabled at the AN, the amount of bandwidth used by the AN is negotiable as described in Section 6.2.5.2.
除第6.2.3、6.2.4或6.3.1节（如适用）中的程序外，第6.2.5节中的供应和带宽管理程序也适用。有条件接收遵循这些章节中给出的规则，将流量与白名单、黑名单和/或灰名单进行匹配。当在AN启用准入控制时，AN使用的带宽量可以协商，如第6.2.5.2节所述。
NAS-initiated multicast replication can coexist with the other capabilities, but some means must exist to prevent double replication of flows. The simplest way to do this is to terminate all IGMP/MLD requests on the AN, so that NAS-initiated multicast replication is stimulated only by signaling through other channels. Other arrangements are possible but need not be discussed here.
NAS发起的多播复制可以与其他功能共存，但必须有一些方法来防止流的双重复制。实现这一点的最简单方法是终止AN上的所有IGMP/MLD请求，这样NAS发起的多播复制就只能通过其他通道的信令来刺激。其他安排是可能的，但无需在此讨论。
Assuming the necessary separation of responsibilities, the only point of interaction between NAS-initiated multicast replication and the other multicast capabilities is in the area of admission control. Specifically, if the AN is to do admission control for flows added by Multicast Replication Control messages, regardless of whether they are part of NAS-initiated replication or grey list multicast service processing, the NAS includes the MRepCtl-CAC TLV in a Provisioning message and the Bandwidth-Allocation TLV in a Port Management message. If, instead, the NAS will do admission control for flows added by Multicast Replication Control messages, regardless of whether they are part of NAS-initiated replication or grey list multicast service processing, it does not send the MRepCtl-CAC TLV in
假设有必要的职责分离，NAS启动的多播复制和其他多播功能之间的唯一交互点是在准入控制领域。具体地说，如果AN要对由多播复制控制消息添加的流进行准入控制，不管它们是NAS启动的复制还是灰名单多播服务处理的一部分，NAS都会在供应消息中包括MRepCtl CAC TLV，在端口管理消息中包括带宽分配TLV。相反，如果NAS将对由多播复制控制消息添加的流执行准入控制，无论它们是NAS启动的复制还是灰名单多播服务处理的一部分，NAS都不会发送MRepCtl CAC TLV
a Provisioning message to the AN. The NAS can independently enable admission control for white flows on the AN by including the White-List-CAC TLV in the Provisioning message.
向AN发送的配置消息。NAS可以通过在供应消息中包含白名单CAC TLV，独立地启用AN上白流的准入控制。
6.3.4. Combinations of Committed Bandwidth Reporting with Other Multicast Capabilities
6.3.4. 提交的带宽报告与其他多播功能的组合
Committed bandwidth reporting can take place independently of other multicast capabilities that have been negotiated. However, some combinations do not make sense because of redundancy. In particular, the NAS obtains the same information that committed bandwidth reporting gives if the only other capabilities operating are NAS-initiated replication and/or conditional access and admission control with grey lists.
提交的带宽报告可以独立于已协商的其他多播功能进行。但是，由于冗余，某些组合没有意义。特别是，如果只有NAS启动的复制和/或带有灰色列表的条件访问和许可控制功能在运行，NAS将获得承诺带宽报告提供的相同信息。
This section deals with two sets of considerations. "Report Buffering Considerations" considers requirements for configuration in support of some of the committed bandwidth reporting capability. "Congestion Considerations" is a warning to implementors about the possibility of control-plane congestion, with suggestions for mitigation.
本节讨论两组注意事项。“报告缓冲考虑事项”考虑了支持某些承诺带宽报告功能的配置要求。“拥堵考虑”是对实施者提出的关于控制飞机拥堵可能性的警告，并提出缓解建议。
The committed bandwidth reporting capability allows the provisioning of a report buffering period to reduce the number of messages the AN passes to the NAS. An appropriate value for this period, if buffering is allowed at all, depends first on the effect of delay in reporting bandwidth changes and secondly on the rate at which bandwidth changes are expected to occur.
提交的带宽报告功能允许提供报告缓冲期，以减少向NAS传递的消息数量。如果允许缓冲，则此时间段的适当值首先取决于报告带宽变化时延迟的影响，其次取决于预期发生带宽变化的速率。
Let us assume, in the first instance, that a delay in adjusting hierarchical scheduling at the NAS causes additional bandwidth demand to be served momentarily on a best-effort basis, introducing the possibility of jitter and, more crucially, packet loss. Appendix IV of ITU-T Recommendation G.1080 [ITU-T_G.1080] indicates that the maximum tolerable duration of a loss episode is less than 16 ms. This would more likely apply in the middle of a program rather than when it was starting up but at least gives an (extremely conservative) order of magnitude for setting the buffering period.
让我们假设，在第一个实例中，在NAS处调整分层调度的延迟导致在尽最大努力的基础上瞬时服务额外的带宽需求，从而引入抖动的可能性，更重要的是，引入分组丢失。ITU-T建议G.1080[ITU-TYG，1080 ]的附录IV表明，损失事件的最大可容忍持续时间小于16毫秒。这更可能应用于程序的中间，而不是在启动时，但至少给出了（非常保守的）数量级来设置缓冲周期。
The next question is whether enough messaging is likely to be generated that multiple bandwidth changes would be observed within such an interval. Let us consider a reasonable example in a DSL environment, where during the busiest hour of the day subscribers start watching at the rate of one program per subscriber per hour.
下一个问题是，是否可能生成足够的消息，以便在这样的间隔内观察到多个带宽变化。让我们考虑DSL环境中的一个合理的例子，在一天中最繁忙的时间，用户开始以每小时用户一个节目的速度观看。
Typically, because of program scheduling, the new channel requests might be concentrated within a three-minute period, giving an effective request rate of 1/(3 minutes * 60 seconds * 1000 ms/second) * 16 ms = 0.00009 requests per buffering interval of 16 ms. With these figures, an AN serving 10,000 subscribers will report an average of 0.9 bandwidth changes per 16 ms buffering interval. It appears that buffering is worthwhile only for larger-scale deployments.
通常，由于节目调度，新信道请求可能集中在三分钟内，有效请求率为1/（3分钟*60秒*1000毫秒/秒）*16毫秒=0.00009个请求/16毫秒的缓冲间隔。根据这些数字，为10000个用户提供服务时，平均每16毫秒缓冲间隔将报告0.9个带宽变化。似乎只有在大规模部署中才值得使用缓冲。
Note that simple replacement of one channel with another -- channel surfing -- does not require reporting or adjustment at the NAS end.
请注意，用另一个频道简单地替换一个频道——频道浏览——不需要在NAS端进行报告或调整。
Implementors must beware of the possibility that a single channel-surfing subscriber could generate enough control messaging to overload the AN or the messaging channel between the AN and the NAS. The implementation problem is to strike the right balance between minimizing the processing of requests that have been overtaken by subsequent events and meeting requirements for what is termed "channel zapping delay". Nominally, such a requirement is to be found in Section 8.1 of [ITU-T_G.1080], but unfortunately no quantitative value was available at the time of publication of this document. Implementors will therefore have to base their work on discussions with customers until standardized requirements become available. (It is possible that regional bodies or more specialized bodies have overtaken the ITU-T in this regard.)
实施者必须注意单通道冲浪订阅者可能会生成足够的控制消息，从而使AN或AN与NAS之间的消息通道过载。实现的问题是在最大限度地减少处理被后续事件超过的请求和满足所谓的“通道切换延迟”要求之间取得适当的平衡。名义上，此类要求见[ITU-T_G.1080]第8.1节，但遗憾的是，在本文件发布时，没有可用的定量值。因此，在标准化需求可用之前，实施者必须将其工作建立在与客户讨论的基础上。（在这方面，区域机构或更多专门机构可能已经超过了ITU-T。）
A typical strategy for minimizing the work associated with request processing includes deliberate buffering of join requests for a short period in case matching Release requests are detected, followed by discard of both requests. More generally, processing of requests from individual subscribers may be rate limited, and the global rate of messaging to the NAS can also be limited. If the AN gets overloaded, deliberate dropping of stale requests can be implemented, for some definitions of "stale".
最小化与请求处理相关的工作的典型策略包括在检测到匹配的释放请求的情况下，在短时间内故意缓冲连接请求，然后丢弃两个请求。更一般地说，来自单个订阅者的请求的处理可能是速率受限的，并且到NAS的消息传递的全局速率也可能是受限的。如果AN过载，对于“stale”的某些定义，可以故意删除过时的请求。
The security considerations of ANCP are discussed in [RFC6320] and in [RFC5713]. Multicast does not, in principle, introduce any new security considerations, although it does increase the attractiveness of ANCP as a means of denial of service (e.g., through direction of multicast streams onto the target) or theft of service.
[RFC6320]和[RFC5713]中讨论了ANCP的安全注意事项。原则上，多播不会引入任何新的安全考虑，尽管它确实增加了ANCP作为拒绝服务（例如，通过将多播流定向到目标）或窃取服务手段的吸引力。
As mentioned in Section 4.4, the inclusion of the Request-Source-MAC TLV or Request-Source-IP TLV in the Multicast Admission Control message presents privacy issues. An attacker able to get access to
如第4.4节所述，在多播接纳控制消息中包含请求源MAC TLV或请求源IP TLV会带来隐私问题。能够访问的攻击者
the contents of this message would, like the content provider, be able to track consumption of multicast content to the individual device and potentially to individual persons if they are associated with particular devices. To make the connection between devices and individuals, the attacker needs to get information from sources other than ANCP, of course, but let us assume that this has happened.
与内容提供商一样，该消息的内容将能够跟踪多播内容对单个设备的消费，并且如果多播内容与特定设备相关联，则可能跟踪对个人的多播内容的消费。为了在设备和个人之间建立连接，攻击者当然需要从ANCP以外的来源获取信息，但我们假设已经发生了这种情况。
The protection specified for ANCP in [RFC6320] will apply to the transmission of the Multicast Admission Control message across the access network to the NAS. Hence, the attacker's potential points of access are between the subscriber and the AN, at the AN and at the NAS. Moreover, if the MAC or IP address are transmitted onwards from the NAS to AAA in a request for policy, that whole onward path has to be examined for vulnerability.
[RFC6320]中为ANCP指定的保护将适用于通过接入网络向NAS传输多播接纳控制消息。因此，攻击者的潜在访问点位于订阅服务器和AN之间、AN和NAS上。此外，如果MAC或IP地址在策略请求中从NAS向前传输到AAA，则必须检查整个向前路径是否存在漏洞。
The question is how many of these potential points of attack can be eliminated through operational practice. The segment from the subscriber through the AN itself seems out of the scope of this discussion -- protection of this segment is basic to subscriber privacy in any event and likely a business requirement. The segment from the AN to the NAS is covered by the basic ANCP protection specified in [RFC6320]. This leaves the NAS and the path between the NAS and AAA for consideration.
问题是这些潜在的攻击点中有多少可以通过作战实践消除。从订阅者到AN本身的部分似乎不在本讨论的范围之内——在任何情况下，保护该部分都是订阅者隐私的基础，可能是一项业务需求。从AN到NAS的段由[RFC6320]中规定的基本ANCP保护覆盖。这就需要考虑NAS以及NAS和AAA之间的路径。
The operator can eliminate the path between the NAS and AAA as a point where the attacker can access per-device information by downloading per-device policy to the NAS for all identified user devices for the particular subscriber. The NAS then selects the applicable policy based on the particular device identifier it has received. This is as opposed to the NAS sending the identifier of the device in question to AAA and getting policy just for that device.
操作员可以消除NAS和AAA之间的路径，攻击者可以通过将特定订阅者的所有已识别用户设备的每设备策略下载到NAS来访问每设备信息。然后，NAS根据其接收到的特定设备标识符选择适用的策略。这与NAS将相关设备的标识符发送到AAA并仅获取该设备的策略相反。
The alternative is to protect the path between the NAS and AAA. If Diameter is used as the AAA protocol, Section 2.2 of [RFC6733] mandates use of IPsec, TLS/TCP, or DTLS/SCTP for that purpose. If RADIUS is used, the operator should deploy TLS transport as specified in [RFC6614].
另一种方法是保护NAS和AAA之间的路径。如果使用Diameter作为AAA协议，[RFC6733]第2.2节要求为此目的使用IPsec、TLS/TCP或DTLS/SCTP。如果使用RADIUS，操作员应按照[RFC6614]中的规定部署TLS传输。
This leaves the NAS itself as a point of attack. In theory, the NAS could be eliminated if the AN remapped the requesting MAC or IP address to an identifier known to itself and AAA but not the NAS. This would require local configuration on the AN, which may be possible under some circumstances. The Request-Source-Device-Id TLV specified in Section 5.11 is available to transmit such an identifier in place of the Request-Source-MAC TLV or Request-Source-IP TLV.
这使NAS本身成为攻击点。理论上，如果AN将请求的MAC或IP地址重新映射到其自身和AAA（而非NAS）已知的标识符，则可以消除NAS。这需要在AN上进行本地配置，这在某些情况下是可能的。第5.11节中规定的请求源设备Id TLV可用于传输此类标识符，以代替请求源MAC TLV或请求源IP TLV。
This document defines the following additional values within the "ANCP Message Types" registry:
本文件在“ANCP消息类型”注册表中定义了以下附加值：
+--------------+--------------------------------+-----------+
| Message Type | Message Name | Reference |
+--------------+--------------------------------+-----------+
| 144 | Multicast Replication Control | RFC 7256 |
| | | |
| 145 | Multicast Admission Control | RFC 7256 |
| | | |
| 146 | Bandwidth Reallocation Request | RFC 7256 |
| | | |
| 147 | Bandwidth Transfer | RFC 7256 |
| | | |
| 148 | Delegated Bandwidth Query | RFC 7256 |
| | | |
| 149 | Multicast Flow Query | RFC 7256 |
| | | |
| 150 | Committed Bandwidth Report | RFC 7256 |
+--------------+--------------------------------+-----------+
+--------------+--------------------------------+-----------+
| Message Type | Message Name | Reference |
+--------------+--------------------------------+-----------+
| 144 | Multicast Replication Control | RFC 7256 |
| | | |
| 145 | Multicast Admission Control | RFC 7256 |
| | | |
| 146 | Bandwidth Reallocation Request | RFC 7256 |
| | | |
| 147 | Bandwidth Transfer | RFC 7256 |
| | | |
| 148 | Delegated Bandwidth Query | RFC 7256 |
| | | |
| 149 | Multicast Flow Query | RFC 7256 |
| | | |
| 150 | Committed Bandwidth Report | RFC 7256 |
+--------------+--------------------------------+-----------+
This document defines the following additional values for the "ANCP Result Codes" registry. In support of these assignments, IANA has changed the lower limit of 0x100 specified by [RFC6320] for assignments by IETF Consensus to 0x64.
本文件为“ANCP结果代码”注册表定义了以下附加值。为了支持这些分配，IANA已将[RFC6320]为IETF共识分配指定的0x100下限更改为0x64。
+------------+------------------------------------------+-----------+
| Result | One-Line Description | Reference |
| Code | | |
+------------+------------------------------------------+-----------+
| 0x64 | Command error. | RFC 7256 |
| | | |
| 0x65 | Invalid flow address. | RFC 7256 |
| | | |
| 0x66 | Multicast flow does not exist. | RFC 7256 |
| | | |
| 0x67 | Invalid preferred bandwidth amount. | RFC 7256 |
| | | |
| 0x68 | Inconsistent views of delegated | RFC 7256 |
| | bandwidth amount. | |
| | | |
| 0x69 | Bandwidth request conflict. | RFC 7256 |
+------------+------------------------------------------+-----------+
+------------+------------------------------------------+-----------+
| Result | One-Line Description | Reference |
| Code | | |
+------------+------------------------------------------+-----------+
| 0x64 | Command error. | RFC 7256 |
| | | |
| 0x65 | Invalid flow address. | RFC 7256 |
| | | |
| 0x66 | Multicast flow does not exist. | RFC 7256 |
| | | |
| 0x67 | Invalid preferred bandwidth amount. | RFC 7256 |
| | | |
| 0x68 | Inconsistent views of delegated | RFC 7256 |
| | bandwidth amount. | |
| | | |
| 0x69 | Bandwidth request conflict. | RFC 7256 |
+------------+------------------------------------------+-----------+
This document defines the following additional values for the "ANCP Command Codes" registry:
本文件为“ANCP命令代码”注册表定义了以下附加值：
+----------------+--------------------------------------+-----------+
| Command Code | Command Code Directive Name | Reference |
| Value | | |
+----------------+--------------------------------------+-----------+
| 1 | Add | RFC 7256 |
| | | |
| 2 | Delete | RFC 7256 |
| | | |
| 3 | Delete All | RFC 7256 |
| | | |
| 4 | Admission Control Reject | RFC 7256 |
| | | |
| 5 | Conditional Access Reject | RFC 7256 |
| | | |
| 6 | Admission Control and Conditional | RFC 7256 |
| | Access Reject | |
+----------------+--------------------------------------+-----------+
+----------------+--------------------------------------+-----------+
| Command Code | Command Code Directive Name | Reference |
| Value | | |
+----------------+--------------------------------------+-----------+
| 1 | Add | RFC 7256 |
| | | |
| 2 | Delete | RFC 7256 |
| | | |
| 3 | Delete All | RFC 7256 |
| | | |
| 4 | Admission Control Reject | RFC 7256 |
| | | |
| 5 | Conditional Access Reject | RFC 7256 |
| | | |
| 6 | Admission Control and Conditional | RFC 7256 |
| | Access Reject | |
+----------------+--------------------------------------+-----------+
This document defines the following additional values within the "ANCP TLV Types" registry:
本文件在“ANCP TLV类型”注册表中定义了以下附加值：
+-----------+--------------------------------+-----------+
| Type Code | TLV Name | Reference |
+-----------+--------------------------------+-----------+
| 0x0013 | Multicast-Service-Profile | RFC 7256 |
| | | |
| 0x0015 | Bandwidth-Allocation | RFC 7256 |
| | | |
| 0x0016 | Bandwidth-Request | RFC 7256 |
| | | |
| 0x0018 | Multicast-Service-Profile-Name | RFC 7256 |
| | | |
| 0x0019 | Multicast-Flow | RFC 7256 |
| | | |
| 0x0021 | List-Action | RFC 7256 |
| | | |
| 0x0022 | Sequence-Number | RFC 7256 |
| | | |
| 0x0024 | White-List-CAC | RFC 7256 |
| | | |
| 0x0025 | MRepCtl-CAC | RFC 7256 |
| | | |
| 0x0092 | Request-Source-IP | RFC 7256 |
| | | |
| 0x0093 | Request-Source-MAC | RFC 7256 |
| | | |
| 0x0094 | Report-Buffering-Time | RFC 7256 |
| | | |
| 0x0095 | Committed-Bandwidth | RFC 7256 |
| | | |
| 0x0096 | Request-Source-Device-Id | RFC 7256 |
+-----------+--------------------------------+-----------+
+-----------+--------------------------------+-----------+
| Type Code | TLV Name | Reference |
+-----------+--------------------------------+-----------+
| 0x0013 | Multicast-Service-Profile | RFC 7256 |
| | | |
| 0x0015 | Bandwidth-Allocation | RFC 7256 |
| | | |
| 0x0016 | Bandwidth-Request | RFC 7256 |
| | | |
| 0x0018 | Multicast-Service-Profile-Name | RFC 7256 |
| | | |
| 0x0019 | Multicast-Flow | RFC 7256 |
| | | |
| 0x0021 | List-Action | RFC 7256 |
| | | |
| 0x0022 | Sequence-Number | RFC 7256 |
| | | |
| 0x0024 | White-List-CAC | RFC 7256 |
| | | |
| 0x0025 | MRepCtl-CAC | RFC 7256 |
| | | |
| 0x0092 | Request-Source-IP | RFC 7256 |
| | | |
| 0x0093 | Request-Source-MAC | RFC 7256 |
| | | |
| 0x0094 | Report-Buffering-Time | RFC 7256 |
| | | |
| 0x0095 | Committed-Bandwidth | RFC 7256 |
| | | |
| 0x0096 | Request-Source-Device-Id | RFC 7256 |
+-----------+--------------------------------+-----------+
This document defines the following additional values for the "ANCP Capability Types" registry:
本文件为“ANCP能力类型”注册表定义了以下附加值：
+-------+-------------------------+--------+------------+-----------+
| Value | Capability Type Name | Tech | Capability | Reference |
| | | Type | Data? | |
+-------+-------------------------+--------+------------+-----------+
| 3 | NAS-Initiated Multicast | 0 | No | RFC 7256 |
| | Replication | | | |
| | | | | |
| 5 | Committed Bandwidth | 0 | No | RFC 7256 |
| | Reporting | | | |
| | | | | |
| 6 | Conditional Access and | 0 | No | RFC 7256 |
| | Admission Control with | | | |
| | White and Black Lists | | | |
| | | | | |
| 7 | Conditional Access and | 0 | No | RFC 7256 |
| | Admission Control with | | | |
| | Grey Lists | | | |
| | | | | |
| 8 | Bandwidth Delegation | 0 | No | RFC 7256 |
+-------+-------------------------+--------+------------+-----------+
+-------+-------------------------+--------+------------+-----------+
| Value | Capability Type Name | Tech | Capability | Reference |
| | | Type | Data? | |
+-------+-------------------------+--------+------------+-----------+
| 3 | NAS-Initiated Multicast | 0 | No | RFC 7256 |
| | Replication | | | |
| | | | | |
| 5 | Committed Bandwidth | 0 | No | RFC 7256 |
| | Reporting | | | |
| | | | | |
| 6 | Conditional Access and | 0 | No | RFC 7256 |
| | Admission Control with | | | |
| | White and Black Lists | | | |
| | | | | |
| 7 | Conditional Access and | 0 | No | RFC 7256 |
| | Admission Control with | | | |
| | Grey Lists | | | |
| | | | | |
| 8 | Bandwidth Delegation | 0 | No | RFC 7256 |
+-------+-------------------------+--------+------------+-----------+
The authors would like to acknowledge Wojciech Dec for providing useful input to this document, Robert Rennison for his help in shaping the definition of the Multicast-Service-Profile TLV, Shridhar Rao for his comments and suggestions, and Aniruddha A for his proposal that formed the base of the Multicast Flow Reporting solution. Philippe Champagne, Sanjay Wadhwa, and Stefaan De Cnodder provided substantial contributions on the solution for the NAS-initiated multicast control use case. Kristian Poscic provided the committed bandwidth reporting use case.
作者要感谢Wojciech Dec为本文档提供了有用的输入，感谢Robert Rennison帮助制定了多播服务配置文件TLV的定义，感谢Shridhar Rao的评论和建议，感谢Aniruddha的提议，该提议构成了多播流报告解决方案的基础。Philippe香槟、Sanjay Wadhwa和Stefaan De Cnodder为NAS发起的多播控制用例的解决方案做出了重大贡献。Kristian Poscic提供了承诺带宽报告用例。
Thanks to the Document Shepherd, Matthew Bocci, and Area Director, Ted Lemon, for points raised by their reviews following Working Group Last Call.
感谢Shepherd、Matthew Bocci和区域总监Ted Lemon在工作组最后一次电话会议后的评论中提出的观点。
Further thanks to Dacheng Zhang, Mehmet Ersue, and Christer Holmberg for their reviews on behalf of the Security, Operations, and Gen-Art directorates. Dacheng's comments led to changes at several points in the document, while Mehmet's led to creation of the Miscellaneous Considerations section. Finally, thanks to Brian Haberman for stimulating a review of the architectural assumptions and their relationship to the ability of user devices to obtain access to non-IPTV multicast services. This also led to changes in the document.
进一步感谢张大成、梅米特·厄苏埃和克里斯特·霍姆伯格代表安全、运营和Gen艺术总监所作的评论。大成的评论导致了文件中几个方面的变化，而梅米特的评论则导致了杂项考虑部分的创建。最后，感谢Brian Haberman对体系结构假设及其与用户设备访问非IPTV多播服务的能力之间的关系进行了回顾。这也导致了文档中的更改。
[PIMreg] IANA, "Protocol Independent Multicast (PIM) Parameters", <http://www.iana.org/assignments/pim-parameters>.
[PIMreg]IANA，“协议独立多播（PIM）参数”<http://www.iana.org/assignments/pim-parameters>.
[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月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010.
[RFC5790]Liu，H.，Cao，W.，和H.Asaeda，“轻量级Internet组管理协议版本3（IGMPv3）和多播侦听器发现版本2（MLDv2）协议”，RFC 57902010年2月。
[RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. Taylor, "Protocol for Access Node Control Mechanism in Broadband Networks", RFC 6320, October 2011.
[RFC6320]Wadhwa，S.，Moissand，J.，Haag，T.，Voigt，N.，和T.Taylor，“宽带网络中接入节点控制机制的协议”，RFC 6320，2011年10月。
[IEEE48] IEEE, "Guidelines for 48-Bit Global Identifier", <http://standards.ieee.org/regauth/oui/tutorials/ EUI48.html>.
[IEEE48]IEEE，“48位全局标识符指南”<http://standards.ieee.org/regauth/oui/tutorials/ EUI48.html>。
[IEEE64] IEEE, "Guidelines for 64-Bit Global Identifier", <http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>.
[IEEE64]IEEE，“64位全局标识符指南”<http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>。
[ITU-T_G.1080] ITU-T, "Quality of experience requirements for IPTV services", ITU-T Recommendation G.1080, December 2008.
[ITU-T_G.1080]ITU-T，“IPTV服务的体验质量要求”，ITU-T建议G.1080，2008年12月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[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月。
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", RFC 5713, January 2010.
[RFC5713]Moustafa，H.，Tschofenig，H.，和S.De Cnodder，“接入节点控制协议（ANCP）的安全威胁和安全要求”，RFC 5713，2010年1月。
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", RFC 5851, May 2010.
[RFC5851]Ooghe，S.，Voigt，N.，Platnic，M.，Haag，T.，和S.Wadhwa，“宽带多业务网络中接入节点控制机制的框架和要求”，RFC 58512010年5月。
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012.
[RFC6614]Winter，S.，McCauley，M.，Venaas，S.，和K.Wierenga，“RADIUS的传输层安全（TLS）加密”，RFC 6614，2012年5月。
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.
[RFC6733]Fajardo，V.，Arkko，J.，Loughney，J.，和G.Zorn，“直径基准协议”，RFC 67332012年10月。
This appendix provides an example in which most of the possible message flows for multicast control are illustrated. This appendix is for informational purposes only. In case of discrepancy with text in the body of this document, the text in the body of the document is to be considered as the normative text.
本附录提供了一个示例，其中说明了用于多播控制的大多数可能的消息流。本附录仅供参考。如果与本文件正文中的文本不一致，则本文件正文中的文本应视为规范性文本。
Assume the following, for a given access port:
对于给定的访问端口，假设以下情况：
o The basic subscribed service is white-listed. The AN will be responsible for admission control for this service.
o 基本订阅服务是白名单。AN将负责此服务的准入控制。
o Some premium services are available, but requests for these services must be referred to the Policy Server for proper credit processing. For this reason, they are grey-listed. The NAS will be responsible for admission control for these services.
o 某些高级服务可用，但对这些服务的请求必须提交给策略服务器以进行适当的信用处理。因此，它们被列为灰色列表。NAS将负责这些服务的准入控制。
o The subscriber has asked that certain services be blocked so that his children cannot view them. These services are black-listed.
o 订户要求阻止某些服务，以便其子女无法查看这些服务。这些服务被列入黑名单。
o All of the above services are Source-Specific Multicast (SSM). In addition, by means that bypass the AN, the subscriber can signal intent to join an on-line game service that is Any-Source Multicast (ASM). The NAS is responsible for admission control for this service.
o 以上所有服务都是源特定多播（SSM）。此外，通过绕过AN，订户可以发出加入在线游戏服务的信号，该在线游戏服务是任意源多播（ASM）。NAS负责此服务的准入控制。
o Bandwidth delegation is, in effect, to share video bandwidth between the AN and the NAS.
o 带宽委派实际上是在AN和NAS之间共享视频带宽。
The stated conditions require the use of four of the five capabilities specified in this memo.
所述条件要求使用本备忘录中规定的五种能力中的四种。
Assume that capability negotiation has been completed between the AN and NAS and that the set of negotiated capabilities includes the following four multicast capabilities: NAS-initiated multicast replication, conditional access and admission control with white and black lists, conditional access and admission control with grey lists, and bandwidth delegation. At this point, the NAS can provision the service profiles on the AN and enable admission control at the AN for white-listed flows. To do this, the NAS sends the AN a Provisioning message containing this information. An example message providing the profile for our assumed subscriber is shown in Figure 22. The message has the following contents:
假设AN和NAS之间的能力协商已经完成，协商的能力集包括以下四个多播能力：NAS发起的多播复制、白名单和黑名单的条件接收和接纳控制、灰名单的条件接收和接纳控制，和带宽授权。此时，NAS可以在AN上提供服务配置文件，并在AN上启用白名单流的准入控制。为此，NAS将发送包含此信息的配置消息。图22显示了为假定订户提供概要文件的示例消息。该消息包含以下内容：
o Message Type is 93.
o 消息类型是93。
o The Result and Result Code fields in the header are set to zeroes, as specified [RFC6320].
o 根据[RFC6320]的规定，标题中的结果和结果代码字段设置为零。
o A Transaction Identifier is assigned by the NAS.
o 事务标识符由NAS分配。
o The Multicast-Service-Profile TLV (of which typically there would be multiple instances) contains a Multicast-Service-Profile-Name TLV (with a length of 20 octets assumed for the example) and three List-Action TLVs, one each for the white, grey, and black lists within the profile. The white list flows come in two sets of group addresses: 233.252.0.0/29, coming from a server at 192.0.2.15, and 233.252.0.32/29, coming from a server at 192.0.2.16. The grey-listed flows are in the band 233.252.0.64/29, coming from a server at 192.0.2.21. Finally, the black list flows are two individual flows that happen to overlap with the grey list band: 233.252.0.65 and 233.252.0.69, also with source 192.0.2.21.
o 多播服务配置文件TLV（通常会有多个实例）包含一个多播服务配置文件名TLV（示例中假定长度为20个八位字节）和三个列表操作TLV，分别用于配置文件中的白、灰和黑列表。白名单流有两组组地址：233.252.0.0/29（来自192.0.2.15的服务器）和233.252.0.32/29（来自192.0.2.16的服务器）。灰色列表中的流位于233.252.0.64/29范围内，来自192.0.2.21的服务器。最后，黑名单流是两个单独的流，恰好与灰色列表带重叠：233.252.0.65和233.252.0.69，也与源192.0.2.21重叠。
o The White-List-CAC TLV indicates that the AN does admission control on white-listed flows.
o 白名单CAC TLV表示AN对白名单流进行准入控制。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 132 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 93 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 132 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Service-Profile 0x0013 | TLV Length = 112 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Svc-Profile-Name 0x0018 | Embedded TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile name |
~ = "Cust 0127-53681-0003" ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 132 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 93 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 132 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Service-Profile 0x0013 | TLV Length = 112 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Svc-Profile-Name 0x0018 | Embedded TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile name |
~ = "Cust 0127-53681-0003" ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G PrefLen = 29| S PrefLen = 32| Group prefix = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 233.252.0.0 | Source prefix = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.15 | G PrefLen = 29| S PrefLen = 32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group prefix = 233.252.0.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source prefix = 192.0.2.16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 3 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G PrefLen = 29| S PrefLen = 32| Group prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 233.252.0.64 | Source prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 192.0.2.21 | Padding = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 2 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G PrefLen = 32| S PrefLen = 32| Group prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 233.252.0.65 | Source prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 192.0.2.21 | G PrefLen = 32| S PrefLen = 32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group prefix = 233.252.0.69 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source prefix = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = White-List-CAC 0x0024 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G PrefLen = 29| S PrefLen = 32| Group prefix = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 233.252.0.0 | Source prefix = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.15 | G PrefLen = 29| S PrefLen = 32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group prefix = 233.252.0.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source prefix = 192.0.2.16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 3 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G PrefLen = 29| S PrefLen = 32| Group prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 233.252.0.64 | Source prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 192.0.2.21 | Padding = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 2 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G PrefLen = 32| S PrefLen = 32| Group prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 233.252.0.65 | Source prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 192.0.2.21 | G PrefLen = 32| S PrefLen = 32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group prefix = 233.252.0.69 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source prefix = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = White-List-CAC 0x0024 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Example Provisioning Message
图22：配置消息示例
Note that the padding after the middle List-Action TLV is counted as part of the length of the Multicast-Service-Profile TLV but is not included in the length of that List-Action TLV. Note also that the Length field in the message header, unlike those in the TLVs, includes the message header itself, as required by [RFC6320].
请注意，中间列表操作TLV之后的填充被计算为多播服务配置文件TLV长度的一部分，但不包括在该列表操作TLV的长度中。还请注意，与TLV中的长度字段不同，消息头中的长度字段包括[RFC6320]所要求的消息头本身。
Finally, note that the Provisioning message does not include a MRepCtl-CAC TLV since in our example admission control for grey-listed flows and for NAS-initiated replication is performed by the NAS.
最后，请注意，供应消息不包括MRepCtl CAC TLV，因为在我们的示例中，灰色列表流和NAS启动复制的许可控制由NAS执行。
As soon as the AN port comes up, the AN sends an ANCP PORT_UP message to the NAS specifying the Access Loop Circuit ID. The NAS replies with an ANCP Port Management message that, together with the other parameters, includes the multicast service profile name to be associated to that port along with the initial amount of delegated bandwidth. The corresponding message flow is illustrated in Figure 23.
一旦AN端口出现，AN就会向NAS发送一条ANCP port_up消息，指定接入环路ID。NAS会回复一条ANCP port Management消息，该消息与其他参数一起，包括要与该端口关联的多播服务配置文件名以及初始委派带宽量。相应的消息流如图23所示。
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | | |
| | DSL Synch. | |
| |---------------->| |
| | |(M1)PORT_UP(Port ID) |
| | |-------------------->|
| | | (*)
| | |(M2) PORT_MNGT |
| | | (Port ID, |
| | |Mcast S Profile Name,|
| | |Bandwidth Allocation)|
| | |<--------------------|
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | | |
| | DSL Synch. | |
| |---------------->| |
| | |(M1)PORT_UP(Port ID) |
| | |-------------------->|
| | | (*)
| | |(M2) PORT_MNGT |
| | | (Port ID, |
| | |Mcast S Profile Name,|
| | |Bandwidth Allocation)|
| | |<--------------------|
(*) The NAS may optionally seek direction from an external Authorization/Policy Server
（*）NAS可以选择从外部授权/策略服务器寻求方向
Figure 23: Configuring an AN Port with Multicast Service Profile ID and Delegated Bandwidth Amount
图23：使用多播服务配置文件ID和委派带宽量配置端口
The Port Management message will typically contain other TLVs, but our example (Figure 24) just shows the Target, Multicast-Service-Profile-Name, and Bandwidth-Allocation TLVs. The Target TLV identifies the subscriber line, the Multicast-Service-Profile-Name TLV is identical to the one contained in the Provisioning message, and the Bandwidth-Allocation TLV provides just enough bandwidth (2000 kbits/s) for one channel to start with.
端口管理消息通常包含其他TLV，但我们的示例（图24）只显示了目标、多播服务配置文件名称和带宽分配TLV。目标TLV标识用户线路，多播服务配置文件名称TLV与配置消息中包含的名称相同，带宽分配TLV为一个通道提供刚刚足够的带宽（2000 kbits/s）。
The following fields in the Port Management message header are shown with specific values either as directed by the base protocol document or for the sake of our example:
端口管理消息头中的以下字段以特定值显示，具体值由基本协议文档指示，或者为了我们的示例：
o Message Type is 32.
o 消息类型为32。
o Result is set to Nack (0x1) for this example.
o 对于本例，结果设置为Nack（0x1）。
o Result Code is 0.
o 结果代码为0。
o A Transaction Identifier is assigned by the NAS.
o 事务标识符由NAS分配。
o Port is set to 0.
o 端口设置为0。
o Event Sequence Number, the R flag and the other bits marked x, Duration, the Event Flags, and the Flow Control Flags are all irrelevant for this function and are set to 0.
o 事件序列号、R标志和其他标记为x的位、持续时间、事件标志和流量控制标志均与此函数无关，并设置为0。
o Function is set to "Configure Connection Service Data" (8).
o 功能设置为“配置连接服务数据”（8）。
o X-Function is set to 0.
o X函数设置为0。
o Tech Type is "DSL" (5).
o 技术类型为“DSL”（5）。
o Block lengths are calculated assuming a Circuit-Id length of 4 in our example. Recall that the example Multicast-Service-Profile-Name TLV length is 20.
o 在我们的示例中，假设电路Id长度为4，则计算块长度。回想一下，示例多播服务配置文件名称TLV length是20。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 32 | Res=1 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Duration = 0 | Function = 0x8| X-Function = 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Flow Control Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Msg Type = 32 | Tech Type=5 | Blk Len = 56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs = 3 | Extension Block length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Svc-Profile-Name 0x0018 | TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile name |
~ = "Cust 0127-53681-0003" ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth value = 2000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 32 | Res=1 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Duration = 0 | Function = 0x8| X-Function = 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Flow Control Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Msg Type = 32 | Tech Type=5 | Blk Len = 56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs = 3 | Extension Block length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Svc-Profile-Name 0x0018 | TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile name |
~ = "Cust 0127-53681-0003" ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth value = 2000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Example Port Management Message
图24：端口管理消息示例
Suppose now that the subscriber chooses to watch the premium channel characterized by source 192.0.2.21, group 233.252.0.67. Upon receiving the join request, the AN matches it against the multicast service profile for the port and determines that it is a grey-listed flow. Figure 25 illustrates the resulting ANCP message flow for the case of a simple join and leave, when admission control for grey-listed flows is not activated on the AN.
现在假设订户选择观看由源192.0.2.21、组233.252.0.67表征的高级频道。接收到加入请求后，AN将其与端口的多播服务配置文件进行匹配，并确定它是灰色列表流。图25说明了当AN上未激活灰色列表流的准入控制时，简单加入和离开情况下产生的ANCP消息流。
To start the flow, the AN sends a Multicast Admission Control message (M1) to the NAS. The NAS decides whether the flow can be admitted, applying both policy and bandwidth criteria. It returns its decision (positive in this example) in a Multicast Replication Control message (M2). Later, when the subscriber leaves the flow, the AN informs the NAS by sending another Multicast Admission Control message.
为了启动流，AN向NAS发送多播接纳控制消息（M1）。NAS决定是否可以接纳流，同时应用策略和带宽标准。它在多播复制控制消息（M2）中返回其决定（本例中为肯定）。稍后，当订户离开流时，AN通过发送另一条多播接纳控制消息通知NAS。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast |
| Join(Grey-Fl) | Admission |
|-----------+---------->| Control (M1) |
| | |------------------>|
| | | | (NAS performs
| | | Multicast | admission
| | | Replication (*) control)
| | | Control (M2) |
| Mcast Grey Flow |<------------------|
|<======================+ |
| | | |
~ ~ ~ ~
| | | Multicast |
| Leave(Grey-Fl) | Admission |
|-----------+---------->| Control (M3) |
| | |------------------>|
| | | |
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast |
| Join(Grey-Fl) | Admission |
|-----------+---------->| Control (M1) |
| | |------------------>|
| | | | (NAS performs
| | | Multicast | admission
| | | Replication (*) control)
| | | Control (M2) |
| Mcast Grey Flow |<------------------|
|<======================+ |
| | | |
~ ~ ~ ~
| | | Multicast |
| Leave(Grey-Fl) | Admission |
|-----------+---------->| Control (M3) |
| | |------------------>|
| | | |
Grey-Fl: multicast flow matching an entry in grey list
灰色Fl：与灰色列表中的条目匹配的多播流
(*) The NAS may optionally seek direction from an external Authorization/Policy Server.
（*）NAS可以选择从外部授权/策略服务器寻求指导。
Figure 25: Successful Join/Leave Operations, Grey-Listed Flow
图25：成功加入/离开操作，灰色列表流程
The Multicast Admission Control message M1 contains:
多播接纳控制消息M1包含：
o an ANCP Header with:
o ANCP标头具有：
* Message Type is 145;
* 消息类型为145；
* Result = Ignore (0x0); and
* 结果=忽略（0x0）；和
* a Transaction Identifier assigned by the AN.
* 由AN分配的事务标识符。
o a Target TLV identifying the AN Port
o 识别端口的目标TLV
o a Command TLV containing:
o 包含以下内容的命令TLV：
* Command Code = "Add" (1);
* 命令代码=“添加”（1）；
* Accounting = "No" (0);
* 会计=“否”（0）；
* a Multicast-Flow embedded TLV indicating the multicast flow for which the AN received the IGMP join: flow type "SSM" (2), address family "IPv4" (1), Group address = 233.252.0.67, Source Address = 192.0.2.21; and
* 嵌入TLV的多播流，指示AN接收到IGMP加入的多播流：流类型“SSM”（2），地址族“IPv4”（1），组地址=233.252.0.67，源地址=192.0.2.21；和
* a Request-Source-Device-Id embedded TLV containing the IGMP join source local device identifier value 5.
* 包含IGMP连接源本地设备标识符值5的请求源设备Id嵌入TLV。
The Multicast Admission Control message M1 is illustrated in Figure 26:
多播接纳控制消息M1如图26所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 98 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=145 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 98 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 0 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Request-Source-Device-Id 0x0092| Embedded TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 98 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=145 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 98 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 0 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Request-Source-Device-Id 0x0092| Embedded TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Multicast Admission Control Message Seeking to Add a Flow
图26：寻求添加流的多播接纳控制消息
The Multicast Replication Control message M2 contains:
多播复制控制消息M2包含：
o an ANCP Header with:
o ANCP标头具有：
* Message Type = "Multicast Replication Control" (144);
* 消息类型=“多播复制控制”（144）；
* Result= 0x1 (Nack); and
* 结果=0x1（Nack）；和
* a Transaction Identifier assigned by the NAS;
* NAS分配的事务标识符；
o a Target TLV identifying the AN Port
o 识别端口的目标TLV
o a Command TLV containing:
o 包含以下内容的命令TLV：
* Command Code = "Add" (1);
* 命令代码=“添加”（1）；
* Accounting = "Yes" (1), since in our example the operator wants accounting on this flow; and
* Accounting=“Yes”（1），因为在我们的示例中，操作员希望对此流进行会计处理；和
* a Multicast-Flow embedded TLV indicating the multicast flow that the NAS is admitting for this access line: flow type "SSM" (2), address family "IPv4" (1), Group address = 233.252.0.67, Source Address = 192.0.2.21.
* 嵌入TLV的多播流，指示NAS为此接入线允许的多播流：流类型“SSM”（2），地址系列“IPv4”（1），组地址=233.252.0.67，源地址=192.0.2.21。
The Multicast Admission Control message M2 is illustrated in Figure 27.
多播接纳控制消息M2如图27所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=144 | Res=1 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Type = 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=144 | Res=1 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Type = 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Multicast Replication Control Message Admitting a Flow
图27：允许流的多播复制控制消息
The Multicast Admission Control message M3 advising the NAS that the flow has been terminated contains:
通知NAS流已终止的多播接纳控制消息M3包含：
o an ANCP Header with:
o ANCP标头具有：
* Message Type is 145;
* 消息类型为145；
* Result = Ignore (0x0); and
* 结果=忽略（0x0）；和
* a Transaction Identifier assigned by the AN.
* 由AN分配的事务标识符。
o a Target TLV identifying the access line
o 识别接入线路的目标TLV
o a Command TLV containing:
o 包含以下内容的命令TLV：
* a Command Code = "Delete" (2);
* a命令代码=“删除”（2）；
* Accounting = "No" (0);
* 会计=“否”（0）；
* a Multicast-Flow embedded TLV indicating the multicast flow for which the AN received the IGMP leave: flow type "SSM" (2), address family "IPv4" (1), Group address = 233.252.0.67, Source Address = 192.0.2.21; and
* 嵌入TLV的多播流，指示AN接收到IGMP离开的多播流：流类型“SSM”（2），地址族“IPv4”（1），组地址=233.252.0.67，源地址=192.0.2.21；和
* a Request-Source-Device-Id embedded TLV containing the IGMP leave request source, the device identified by the local value 5.
* 包含IGMP离开请求源的请求源设备Id嵌入TLV，该设备由本地值5标识。
The Multicast Admission Control message M3 is illustrated in Figure 28.
多播接纳控制消息M3如图28所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=145 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 2 | Acctg = 0 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Flow Type = 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Request-Source-Device-Id 0x0092| Embedded TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=145 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 2 | Acctg = 0 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Flow Type = 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Request-Source-Device-Id 0x0092| Embedded TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Multicast Admission Control Message Signaling Flow Termination
图28：多播接纳控制消息信令流终止
The NAS has enabled white list admission control on the AN, and the bandwidth delegation capability has been negotiated. White-listed flows in themselves require no messages to the NAS, either upon admission or upon termination, but the AN may request an increase in the amount of delegated bandwidth if it needs the increase to admit a flow.
NAS已在AN上启用白名单准入控制，并且已协商带宽委派能力。白名单流本身在接纳或终止时都不需要向NAS发送消息，但如果AN需要增加委派带宽以接纳流，则可以请求增加委派带宽。
Consider an example where the AN has already admitted one white-listed flow, thereby using up the initially provisioned amount of delegated bandwidth (2000 kbits/s). A request is received to join a new flow in the white list range. The AN chooses to send a Bandwidth Reallocation Request message to the NAS, requesting that the delegated bandwidth allocation be increased to 4000 kbits/s at a minimum and preferably to 6000 kbits/s.
考虑一个示例，其中AN已经接纳了一个白名单的流，从而使用初始提供的授权带宽量（2000 kBys/s）。接收到加入白名单范围内新流的请求。AN选择向NAS发送带宽重新分配请求消息，请求将委派的带宽分配至少增加到4000 kbits/s，最好增加到6000 kbits/s。
In our example, the NAS is managing bandwidth tightly, as witnessed by its minimal initial allocation of just enough for one flow. It is willing to provide the minimum additional amount only and therefore returns a Bandwidth Transfer message where the delegated bandwidth value is given as 4000 kbits/s. With this amount, the AN is able to admit the second white-listed flow. The AN could send a similar Bandwidth Transfer message back to the NAS bringing the delegated bandwidth amount back down to 2000 kbits/s when one of the flows is terminated, but this shows nothing new and is omitted.
在我们的示例中，NAS严格管理带宽，其最小初始分配仅足以满足一个流。它只愿意提供最小附加量，因此返回带宽传输消息，其中指定的带宽值为4000 kbits/s。有了这个数量，AN就能够接纳第二个白名单流。当其中一个流终止时，AN可以向NAS发送类似的带宽传输消息，将委派的带宽量降低到2000 kbits/s，但这并没有显示任何新内容，因此被忽略。
As one more point of illustration, suppose that the NAS chooses to audit the current amount of delegated bandwidth to ensure it is synchronized with the AN. It sends a Delegated Bandwidth Query Request message to the AN and receives a Delegated Bandwidth Query Response message with the current allocation as the AN sees it.
再举一个例子，假设NAS选择审核当前的委派带宽量，以确保它与AN同步。它向AN发送委派带宽查询请求消息，并接收委派带宽查询响应消息，其中AN看到当前分配。
The complete message flow is shown in Figure 29.
完整的消息流如图29所示。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(White-F1) | |
|-----------+---------->| |
| | |AN performs |
| Mcast White Flow 1 | admission control |
|<======================+ |
| | | |
| Join(White-F2) | |
|-----------+---------->|No bandwidth left |
| | | |
| | |Bandwidth |
| | | Reallocation Req |
| | |------------------>|(M1)
| | | |
| | | (*)
| | |Bandwidth Transfer |
| AN can now |<------------------|(M2)
| admit flow | |
| Mcast White Flow 2 | |
|<======================+ |
| | | |
~ ~ ~ ~
| | |Delegated Bandwidth|
| | | Query request |
| | |<------------------|(M3)
| | | |
| | |Delegated Bandwidth|
| | | Query response |
| | |------------------>|(M4)
| | | |
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(White-F1) | |
|-----------+---------->| |
| | |AN performs |
| Mcast White Flow 1 | admission control |
|<======================+ |
| | | |
| Join(White-F2) | |
|-----------+---------->|No bandwidth left |
| | | |
| | |Bandwidth |
| | | Reallocation Req |
| | |------------------>|(M1)
| | | |
| | | (*)
| | |Bandwidth Transfer |
| AN can now |<------------------|(M2)
| admit flow | |
| Mcast White Flow 2 | |
|<======================+ |
| | | |
~ ~ ~ ~
| | |Delegated Bandwidth|
| | | Query request |
| | |<------------------|(M3)
| | | |
| | |Delegated Bandwidth|
| | | Query response |
| | |------------------>|(M4)
| | | |
(*) The NAS may optionally seek direction from an external Authorization/Policy Server.
（*）NAS可以选择从外部授权/策略服务器寻求指导。
Figure 29: Successful Join/Leave Operations, White-Listed Flow
图29：成功加入/离开操作，白名单流
The Bandwidth Reallocation Request message (M1) is shown in Figure 30. The contents require little explanation. The Message Type for the Bandwidth Reallocation Request is 146. The Result field is set to Ignore (0x0). Besides the Target TLV, the message has one other TLV, the Bandwidth-Request, with a TLV Type of 0x0016. The TLV contains Required Amount and Preferred Amount fields, set to 4000 and 6000 kbits/s respectively.
带宽重新分配请求消息（M1）如图30所示。内容几乎不需要解释。带宽重新分配请求的消息类型为146。结果字段设置为忽略（0x0）。除了目标TLV之外，消息还有一个TLV，即带宽请求，TLV类型为0x0016。TLV包含所需金额和首选金额字段，分别设置为4000和6000 kbits/s。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=146 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Request 0x0016 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Amount = 6000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=146 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Request 0x0016 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Amount = 6000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Bandwidth Reallocation Request Message
图30：带宽重新分配请求消息
The Bandwidth Transfer message (M2) is shown in Figure 31. Again, the contents are easily understood. The Message Type for the Bandwidth Transfer message is 147. The Result field is set to Success (0x3). The message contains the Target TLV and the Bandwidth-Allocation TLV. The latter has a TLV Type of 0x0015 and contains a Delegated Amount field, set to 4000 kbits/s.
带宽传输消息（M2）如图31所示。同样，内容很容易理解。带宽传输消息的消息类型为147。结果字段设置为成功（0x3）。该消息包含目标TLV和带宽分配TLV。后者的TLV类型为0x0015，并包含一个委托金额字段，设置为4000 kbits/s。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=147 | Res=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=147 | Res=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: NAS Response, Bandwidth Transfer Message
图31:NAS响应、带宽传输消息
The Delegated Bandwidth Query Request message (M3) is shown in Figure 32. The Message Type for the Delegated Bandwidth Query request message is 148. The Result field is set to AckAll (0x2). The message contains the Target TLV only.
委派带宽查询请求消息（M3）如图32所示。委派带宽查询请求消息的消息类型为148。结果字段设置为AckAll（0x2）。该消息仅包含目标TLV。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=148 | Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=148 | Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: Delegated Bandwidth Query Request Message
图32：委派带宽查询请求消息
Finally, the Delegated Bandwidth Query Response message (M4) is shown in Figure 33. The Message Type for the Delegated Bandwidth Query response message is 148. The Result field is set to Success (0x3). The message contains the Target TLV and the Bandwidth-Allocation TLV with the Delegated Amount field set to 4000 kbits/s.
最后，委派带宽查询响应消息（M4）如图33所示。委派带宽查询响应消息的消息类型为148。结果字段设置为成功（0x3）。该消息包含目标TLV和带宽分配TLV，委托金额字段设置为4000 kbits/s。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=148 | Res=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier (copied from request) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=148 | Res=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier (copied from request) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33: Delegated Bandwidth Query Response Message
图33：委派带宽查询响应消息
This section introduces no new messages, since requests for flows in the black list are simply ignored. The one thing to point out is the overlap in our example between the set of flows in the grey list and the flows in the black list. This does not create any ambiguity, since not only does the black list have priority for equally good matches, but also the black list entries are more specific (group prefix lengths of 32 versus 29 in the grey list) than the grey list flow prefixes.
本节不介绍新消息，因为黑名单中的流请求将被忽略。需要指出的一点是，在我们的示例中，灰色列表中的流集合与黑名单中的流之间存在重叠。这不会产生任何歧义，因为黑名单不仅具有同等良好匹配的优先级，而且黑名单条目比灰名单流前缀更具体（组前缀长度为32比29）。
The final class of multicast control actions in our example allows the subscriber to enter and leave the on-line game. As described at the beginning of this example, the game uses Any-Source Multicast (ASM). Subscriber signaling bypasses the AN, going directly to the NAS (e.g., through a web interface).
我们示例中的最后一类多播控制操作允许订户进入和离开在线游戏。如本例开头所述，游戏使用任何源多播（ASM）。用户信令绕过AN，直接进入NAS（例如，通过web接口）。
When the subscriber requests to join the game, the NAS (after applying policy and bandwidth checks) sends a Multicast Replication Control message to the AN to enable the flow on the port concerned. The AN knows not to apply admission control, since it has not received an MRepCtl-CAC TLV in the Provisioning message. When the subscriber leaves, the NAS sends another Multicast Replication Control message to delete the flow. This message sequence is shown in Figure 34.
当订户请求加入游戏时，NAS（在应用策略和带宽检查后）向AN发送多播复制控制消息，以启用相关端口上的流。AN知道不应用许可控制，因为它在设置消息中没有收到MRepCtl CAC TLV。订户离开时，NAS会发送另一条多播复制控制消息以删除流。此消息序列如图34所示。
It is possible that the NAS finds that there is not enough bandwidth available to accommodate the subscriber's request. In this case, the NAS could send a Bandwidth Reallocation Request message to the AN, asking it to release some of the bandwidth delegated to it. This is not shown in the present example, since the messages are the same as those already presented with the exception that the Preferred Amount in the request will be *less than* or equal to the Required amount, rather than *greater than* or equal to it.
NAS可能发现没有足够的可用带宽来满足订阅者的请求。在这种情况下，NAS可以向AN发送带宽重新分配请求消息，要求其释放委派给它的部分带宽。这在本示例中未示出，因为消息与已经呈现的消息相同，但请求中的首选量将*小于*或等于所需量，而不是*大于*或等于所需量。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join game | |
|-----------+------------------------------>|
| | | Multicast | NAS performs
| | | Replication (*) admission
| | | Control (M1) | control
| Mcast Game Flow |<------------------|
|<=====================>+ |
| | | |
~ ~ ~ ~
| | | |
| Leave game | |
|-----------+------------------------------>|
| | | Multicast |
| | | Replication |
| | | Control (M2) |
| Mcast Game Flow |<------------------|
| discontinued | |
| | | |
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join game | |
|-----------+------------------------------>|
| | | Multicast | NAS performs
| | | Replication (*) admission
| | | Control (M1) | control
| Mcast Game Flow |<------------------|
|<=====================>+ |
| | | |
~ ~ ~ ~
| | | |
| Leave game | |
|-----------+------------------------------>|
| | | Multicast |
| | | Replication |
| | | Control (M2) |
| Mcast Game Flow |<------------------|
| discontinued | |
| | | |
(*) The NAS may optionally seek direction from an external Authorization/Policy Server.
（*）NAS可以选择从外部授权/策略服务器寻求指导。
Figure 34: NAS-Initiated Flows for On-Line Gaming
图34：NAS启动的在线游戏流程
The Multicast Replication Control message (M1) in Figure 35 looks like the message in Figure 27 with two exceptions. The first is that the NAS has the option to set the Result field to AckAll (0x02) if it needs positive reassurance that the flow has been enabled. This was not done here to save having to depict a response differing only in the Result field. The larger difference in this example is that the flow description in the Multicast-Flow embedded TLV is that of an ASM multicast group (Flow Type = 1) with IPv4 (1) group address 233.252.0.100.
图35中的多播复制控制消息（M1）与图27中的消息类似，但有两个例外。第一个是NAS可以选择将结果字段设置为AckAll（0x02），如果它需要肯定地确保流已启用。在这里这样做并不是为了避免只在结果字段中描述不同的响应。该示例中更大的区别在于，嵌入TLV的多播流中的流描述是具有IPv4（1）组地址233.252.0.100的ASM多播组（流类型=1）的流描述。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=144 | Res=1 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 1 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=144 | Res=1 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 1 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
Figure 35: Enabling the Subscriber to Join an On-Line Game
图35：使订户能够加入在线游戏
Message M2 terminating the flow when the subscriber leaves the game looks the same as the message in Figure 35 with two exceptions: the Command Code becomes "Delete" (2), and Accounting is set to "No" (0) to turn off flow accounting. Of course, the Transaction Identifier values will differ between the two messages.
当订户离开游戏时终止流的消息M2看起来与图35中的消息相同，但有两个例外：命令代码变为“Delete”（2），记帐设置为“No”（0）以关闭流记帐。当然，两条消息之间的事务标识符值会有所不同。
The example in this section is independent of the example in the preceding sections.
本节中的示例独立于前面各节中的示例。
Figure 36 illustrates a message flow in a case where the NAS queries the AN about which multicast flows are active on port 10, port 11, and port 20 of the AN.
图36说明了NAS查询AN的端口10、端口11和端口20上哪些多播流处于活动状态的情况下的消息流。
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast Flow |
| | | Query Request |
| | | (M1) |
| | |<------------------|
| | | |
| | | Multicast Flow |
| | | Query Response |
| | | (M2) |
| | |------------------>|
| | | |
| | | |
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast Flow |
| | | Query Request |
| | | (M1) |
| | |<------------------|
| | | |
| | | Multicast Flow |
| | | Query Response |
| | | (M2) |
| | |------------------>|
| | | |
| | | |
Figure 36: Per-Port Multicast Flow Reporting
图36：每端口多播流报告
The Multicast Flow Query Request message (M1) is illustrated in Figure 37. The Message Type is 149. The Result field is set to AckAll (0x2). Three Target TLVs are present, identifying port 10, port 20, and port 11, respectively.
多播流查询请求消息（M1）如图37所示。消息类型为149。结果字段设置为AckAll（0x2）。存在三个目标TLV，分别标识端口10、端口20和端口11。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 149| Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port10) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port11) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 149| Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port10) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port11) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37: Multicast Flow Query Request Message for Per-Port Multicast Flow Reporting
图37：每端口多播流报告的多播流查询请求消息
The Multicast Flow Query Response message (M2) is illustrated in Figure 38. It indicates that there is one active multicast flow [(192.0.2.1, 233.252.0.4)] on port 10, no active multicast flow on port 20, and two active multicast flows [(192.0.2.1, 233.252.0.4) and (192.0.2.2, 233.252.0.10)] on port 11.
多播流查询响应消息（M2）如图38所示。它表示端口10上有一个活动多播流[（192.0.2.1，233.252.0.4）]，端口20上没有活动多播流，端口11上有两个活动多播流[（192.0.2.1，233.252.0.4）和（192.0.2，233.252.0.10）]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 149|Rslt=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port10) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port11) ~
| |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 149|Rslt=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port10) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port11) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address: 233.252.0.10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address: 233.252.0.10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
Figure 38: Multicast Flow Query Response Message for Per-Port Multicast Flow Reporting
图38：每端口多播流报告的多播流查询响应消息
Authors' Addresses
作者地址
Francois Le Faucheur Cisco Systems 45 Allee des Ormes Mougins 06250 France
Francois Le Faucheur思科系统45 Allee des Ormes Mougins 06250法国
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Roberta Maglione Cisco Systems 181 Bay Street Toronto, ON M5J 2T3 Canada
Roberta Maglione思科系统公司位于加拿大多伦多湾街181号M5J 2T3
EMail: robmgl@cisco.com
EMail: robmgl@cisco.com
Tom Taylor Huawei Technologies Ottawa Canada
加拿大渥太华华为技术有限公司
EMail: tom.taylor.stds@gmail.com
EMail: tom.taylor.stds@gmail.com