draft-ietf-ancp-mc-extensions-14.txt   draft-ietf-ancp-mc-extensions-15.txt 
ANCP F. Le Faucheur ANCP F. Le Faucheur
Internet-Draft Cisco Internet-Draft Cisco
Updates: 6320 (if approved) R. Maglione Updates: 6320 (if approved) R. Maglione
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: July 12, 2014 T. Taylor Expires: August 25, 2014 T. Taylor
Huawei Huawei
January 8, 2014 February 21, 2014
Multicast Control Extensions for ANCP Multicast Control Extensions for ANCP
draft-ietf-ancp-mc-extensions-14.txt draft-ietf-ancp-mc-extensions-15.txt
Abstract Abstract
This document specifies the extensions to the Access Node Control This document specifies the extensions to the Access Node Control
Protocol required for support of the multicast use cases defined in Protocol required for support of the multicast use cases defined in
the Access Node Control Protocol framework document and one the Access Node Control Protocol framework document and one
additional use case described in this document. These use cases are additional use case described in this document. These use cases are
organized into the following ANCP capabilities: organized into the following ANCP capabilities:
o NAS-initiated multicast replication; o NAS-initiated multicast replication;
o conditional access with white and black lists; o conditional access and admission control with white and black
lists;
o conditional access with grey lists; o conditional access and admission control with grey lists;
o bandwidth delegation; o bandwidth delegation;
o committed bandwidth reporting. o committed bandwidth reporting.
These capabilities may be combined according to the rules given in These capabilities may be combined according to the rules given in
this specification. this specification.
This document updates RFC 6320 by assigning capability type 3 to a This document updates RFC 6320 by assigning capability type 3 to a
capability specified in this document and by changing the starting capability specified in this document and by changing the starting
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 12, 2014. This Internet-Draft will expire on August 25, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. A Note On Scope . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 7 3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 7
3.1. NAS Initiated Multicast Replication Control Use Case . . 7 3.1. NAS Initiated Multicast Replication Control Use Case . . 8
3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . 8
3.2. Conditional Access and Admission Control Use Case . . . . 8 3.2. Conditional Access and Admission Control Use Case . . . . 9
3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . 9 3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . 10
3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 10 3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 11
3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . 10 3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . 12
3.4. Committed Bandwidth Reporting Use Case . . . . . . . . . 10 3.4. Committed Bandwidth Reporting Use Case . . . . . . . . . 12
3.4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.2. Message Flow . . . . . . . . . . . . . . . . . . . . 11 3.4.2. Message Flow . . . . . . . . . . . . . . . . . . . . 13
4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 12 4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Provisioning Message . . . . . . . . . . . . . . . . . . 12 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . 14
4.1.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 13 4.1.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 15
4.1.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 13 4.1.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 15
4.2. Port Management Message . . . . . . . . . . . . . . . . . 14 4.2. Port Management Message . . . . . . . . . . . . . . . . . 16
4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 15 4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 17
4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 15 4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 17
4.3. Multicast Replication Control Message . . . . . . . . . . 16 4.3. Multicast Replication Control Message . . . . . . . . . . 18
4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 19 4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 21
4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 20 4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 22
4.4. Multicast Admission Control Message . . . . . . . . . . . 22 4.4. Multicast Admission Control Message . . . . . . . . . . . 24
4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 23 4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 25
4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 25 4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 27
4.5. Bandwidth Reallocation Request Message . . . . . . . . . 26 4.5. Bandwidth Reallocation Request Message . . . . . . . . . 28
4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 26 4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 28
4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 27 4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 29
4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . 30 4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . 32
4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 30 4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 32
4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 31 4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 33
4.7. Delegated Bandwidth Query Request Message . . . . . . . . 32 4.7. Delegated Bandwidth Query Request Message . . . . . . . . 34
4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 32 4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 34
4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 32 4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 34
4.8. Delegated Bandwidth Query Response Message . . . . . . . 33 4.8. Delegated Bandwidth Query Response Message . . . . . . . 35
4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 33 4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 35
4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 33 4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 35
4.9. Multicast Flow Query Request and Response Messages . . . 34 4.9. Multicast Flow Query Request and Response Messages . . . 36
4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 34 4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 36
4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 35 4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 37
4.10. Committed Bandwidth Report Message . . . . . . . . . . . 36 4.10. Committed Bandwidth Report Message . . . . . . . . . . . 38
4.10.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 37 4.10.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 39
4.10.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 37 4.10.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 39
5. ANCP TLVs For Multicast . . . . . . . . . . . . . . . . . . . 37 5. ANCP TLVs For Multicast . . . . . . . . . . . . . . . . . . . 39
5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 37 5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 39
5.2. Multicast-Service-Profile-Name TLV . . . . . . . . . . . 39 5.2. Multicast-Service-Profile-Name TLV . . . . . . . . . . . 41
5.3. List-Action TLV . . . . . . . . . . . . . . . . . . . . . 39 5.3. List-Action TLV . . . . . . . . . . . . . . . . . . . . . 41
5.4. Sequence-Number TLV . . . . . . . . . . . . . . . . . . . 42 5.4. Sequence-Number TLV . . . . . . . . . . . . . . . . . . . 44
5.5. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . 42 5.5. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . 44
5.6. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . 43 5.6. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . 45
5.7. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 43 5.7. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 45
5.8. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 44 5.8. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 46
5.9. Request-Source-IP TLV . . . . . . . . . . . . . . . . . . 45 5.9. Request-Source-IP TLV . . . . . . . . . . . . . . . . . . 47
5.10. Request-Source-MAC TLV . . . . . . . . . . . . . . . . . 45 5.10. Request-Source-MAC TLV . . . . . . . . . . . . . . . . . 47
5.11. Request-Source-Device-Id TLV . . . . . . . . . . . . . . 46 5.11. Request-Source-Device-Id TLV . . . . . . . . . . . . . . 48
5.12. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . 47 5.12. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . 49
5.13. Report-Buffering-Time TLV . . . . . . . . . . . . . . . . 48 5.13. Report-Buffering-Time TLV . . . . . . . . . . . . . . . . 50
5.14. Committed-Bandwidth TLV . . . . . . . . . . . . . . . . . 48 5.14. Committed-Bandwidth TLV . . . . . . . . . . . . . . . . . 50
6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . 49 6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . 51
6.1. Required Protocol Support . . . . . . . . . . . . . . . . 50 6.1. Required Protocol Support . . . . . . . . . . . . . . . . 52
6.1.1. Protocol Requirements For NAS-Initiated Replication . 50 6.1.1. Protocol Requirements For NAS-Initiated Replication . 52
6.1.2. Protocol Requirements For Committed Multicast 6.1.2. Protocol Requirements For Committed Multicast
Bandwidth Reporting . . . . . . . . . . . . . . . . . 51 Bandwidth Reporting . . . . . . . . . . . . . . . . . 53
6.1.3. Protocol Requirements For Conditional Access With 6.1.3. Protocol Requirements For Conditional Access and
White and Black Lists . . . . . . . . . . . . . . . . 52 Admission Control With White and Black Lists . . . . 54
6.1.4. Protocol Requirements For Conditional Access With 6.1.4. Protocol Requirements For Conditional Access and
Grey Lists . . . . . . . . . . . . . . . . . . . . . 53 Admission Control With Grey Lists . . . . . . . . . . 55
6.1.5. Protocol Requirements For Delegated Bandwidth . . . . 54 6.1.5. Protocol Requirements For Delegated Bandwidth . . . . 56
6.2. Capability-Specific Procedures for Providing Multicast 6.2. Capability-Specific Procedures for Providing Multicast
Service . . . . . . . . . . . . . . . . . . . . . . . . . 55 Service . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.1. Procedures For NAS-Initiated Replication . . . . . . 55 6.2.1. Procedures For NAS-Initiated Replication . . . . . . 57
6.2.2. Procedures For Committed Bandwidth Reporting . . . . 56 6.2.2. Procedures For Committed Bandwidth Reporting . . . . 58
6.2.3. Procedures For Conditional Access With Black and 6.2.3. Procedures For Conditional Access and Admission
White Lists . . . . . . . . . . . . . . . . . . . . . 57 Control With Black and White Lists . . . . . . . . . 59
6.2.4. Procedures For Conditional Access With Grey Lists . . 59 6.2.4. Procedures For Conditional Access and Admission
6.2.5. Procedures For Delegated Bandwidth . . . . . . . . . 60 Control With Grey Lists . . . . . . . . . . . . . . 61
6.3. Combinations of Multicast Capabilities . . . . . . . . . 61 6.2.5. Procedures For Delegated Bandwidth . . . . . . . . . 62
6.3.1. Combination of Conditional Access With White and 6.3. Combinations of Multicast Capabilities . . . . . . . . . 63
Black Lists and Conditional Access With Grey Lists . 61 6.3.1. Combination of Conditional Access and Admission
6.3.2. Combination of Conditional Access With Delegated Control With White and Black Lists and Conditional
Bandwidth . . . . . . . . . . . . . . . . . . . . . . 63 Access and Admission Control With Grey Lists . . . . 63
6.3.2. Combination of Conditional Access and Admission
Control With Delegated Bandwidth . . . . . . . . . . 65
6.3.3. Combination of NAS-Initiated Replication with Other 6.3.3. Combination of NAS-Initiated Replication with Other
Capabilities . . . . . . . . . . . . . . . . . . . . 63 Capabilities . . . . . . . . . . . . . . . . . . . . 65
6.3.4. Combinations of Committed Bandwidth Reporting with 6.3.4. Combinations of Committed Bandwidth Reporting with
Other Multicast Capabilities . . . . . . . . . . . . 63 Other Multicast Capabilities . . . . . . . . . . . . 65
7. Security Considerations . . . . . . . . . . . . . . . . . . . 64 7. Miscellaneous Considerations . . . . . . . . . . . . . . . . 66
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 7.1. Report Buffering Considerations . . . . . . . . . . . . . 66
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68 7.2. Congestion Considerations . . . . . . . . . . . . . . . . 67
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 67
10.1. Normative References . . . . . . . . . . . . . . . . . . 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68
10.2. Informative References . . . . . . . . . . . . . . . . . 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72
Appendix A. Example of Messages and Message Flows . . . . . . . 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.1. Provisioning Phase . . . . . . . . . . . . . . . . . . . 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 73
A.2. Handling a Grey-Listed Flow . . . . . . . . . . . . . . . 76 11.2. Informative References . . . . . . . . . . . . . . . . . 73
A.3. Handling White-Listed Flows . . . . . . . . . . . . . . . 81 Appendix A. Example of Messages and Message Flows . . . . . . . 74
A.4. Handling Of Black-Listed Join Requests . . . . . . . . . 86 A.1. Provisioning Phase . . . . . . . . . . . . . . . . . . . 75
A.5. Handling Of Requests To Join and Leave the On-Line Game . 86 A.2. Handling a Grey-Listed Flow . . . . . . . . . . . . . . . 81
A.6. Example Flow For Multicast Flow Reporting . . . . . . . . 89 A.3. Handling White-Listed Flows . . . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92 A.4. Handling Of Black-Listed Join Requests . . . . . . . . . 91
A.5. Handling Of Requests To Join and Leave the On-Line Game . 91
A.6. Example Flow For Multicast Flow Reporting . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97
1. Introduction 1. Introduction
[RFC5851] defines a framework and requirements for an Access Node [RFC5851] defines a framework and requirements for an Access Node
control mechanism between a Network Access Server (NAS) and an Access control mechanism between a Network Access Server (NAS) and an Access
Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a
multi-service reference architecture in order to perform QoS-related, multi-service reference architecture in order to perform QoS-related,
service-related and subscriber-related operations. [RFC6320] service-related and subscriber-related operations. [RFC6320]
specifies a protocol for Access Node Control in broadband networks in specifies a protocol for Access Node Control in broadband networks in
line with this framework. line with this framework.
skipping to change at page 5, line 9 skipping to change at page 5, line 17
Configuration use case and the DSL Remote Connectivity Test use case. Configuration use case and the DSL Remote Connectivity Test use case.
However, it does not support the multicast use cases defined in However, it does not support the multicast use cases defined in
[RFC5851]. The present document specifies the extensions to the [RFC5851]. The present document specifies the extensions to the
Access Node Control Protocol required for support of these multicast Access Node Control Protocol required for support of these multicast
use cases. In addition, it supports the Committed Bandwidth use cases. In addition, it supports the Committed Bandwidth
Reporting use case, described below. In terms of the ANCP protocol, Reporting use case, described below. In terms of the ANCP protocol,
these use cases are organized into five capabilities: these use cases are organized into five capabilities:
o NAS-initiated multicast replication; o NAS-initiated multicast replication;
o conditional access with white and black lists; o conditional access and admission control with white and black
lists;
o conditional access with grey lists; o conditional access and admission control with grey lists;
o bandwidth delegation; o bandwidth delegation;
o committed bandwidth reporting. o committed bandwidth reporting.
NAS-initiated multicast replication assumes that multicast "join" and NAS-initiated multicast replication assumes that multicast "join" and
"leave" requests are terminated on the NAS, or that the NAS receives "leave" requests are terminated on the NAS, or that the NAS receives
requests to establish multicast sessions through other means (e.g., requests to establish multicast sessions through other means (e.g.,
application-level signalling). The NAS sends commands to the AN to application-level signalling). The NAS sends commands to the AN to
start or stop replication of specific multicast flows on specific start or stop replication of specific multicast flows on specific
subscriber ports. This use case is described briefly in the next-to- subscriber ports. This use case is described briefly in the next-to-
last paragraph of Section 3.4 of [RFC5851]. last paragraph of Section 3.4 of [RFC5851].
Conditional access is described in Section 3.4.1 and Section 3.4.2.3 Conditional access is described in Section 3.4.1 of [RFC5851].
of [RFC5851], with the latter section particularly applicable to Section 3.4.2.2 mentions a way in which conditional access can be
operation with white and black lists only. In case of "conditional combined with admission control to allow best effort multicast flows.
access with white and black lists", multicast join and leave requests Section 3.4.2.3 points out the necessary conditions for using both
are terminated at the AN and accepted or ignored in accordance with conditional access and admission control.
the direction 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 enable admission control of
white-listed flows by appropriate provisioning.
Conditional access with grey lists is similar to conditional access In the case of "conditional access and admission control with white
with white lists, except that before accepting any request matching a and black lists", multicast join and leave requests are terminated at
grey list entry, the AN sends a request to the NAS for permission to the AN and accepted or ignored in accordance with the direction
replicate the flow. Again, the NAS can enable admission control of provided by white and black lists respectively. The white and black
grey-listed flows at the AN. 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.
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.
Bandwidth delegation is described in Section 3.4.2.1 of [RFC5851]. Bandwidth delegation is described in Section 3.4.2.1 of [RFC5851].
It allows flexible sharing of total video bandwidth on an access line It allows flexible sharing of total video bandwidth on an access line
between the AN and the NAS. One application of such bandwidth between the AN and the NAS. One application of such bandwidth
sharing is where the AN does multicast admission control, while the sharing is where the AN does multicast admission control, while the
NAS or Policy Server does unicast admission control. In that case, NAS or Policy Server does unicast admission control. In that case,
bandwidth delegation allows dynamic sharing of bandwidth between bandwidth delegation allows dynamic sharing of bandwidth between
unicast and multicast video traffic on each access line. unicast and multicast video traffic on each access line.
Committed bandwidth reporting is described below, in Section 3.4. Committed bandwidth reporting is described below, in Section 3.4.
skipping to change at page 6, line 26 skipping to change at page 6, line 41
specified in this document are merged into a single non-redundant specified in this document are merged into a single non-redundant
narrative. Tables in Section 6 then indicate the specific sub- narrative. Tables in Section 6 then indicate the specific sub-
sections of the protocol description that have to be implemented to sections of the protocol description that have to be implemented to
support each capability. support each capability.
This document updates RFC 6320 by assigning capability type 3 to the This document updates RFC 6320 by assigning capability type 3 to the
NAS-initiated multicast replication capability and by changing the NAS-initiated multicast replication capability and by changing the
starting point for IANA allocation of result codes determined by IETF starting point for IANA allocation of result codes determined by IETF
Consensus from 0x100 to 0x64. Consensus from 0x100 to 0x64.
1.1. A Note On Scope
The requirements in [RFC5851] were formulated with the IPTV
application in mind. Two basic assumptions underlie the use case
descriptions:
o that the Home Gateway operates in bridged mode, and
o that multicast signalling uses IGMP ([RFC2236] or [RFC3376]) or
MLD [RFC3810] rather than 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 monitor for PIM
signalling. The capabilities described in the present document do
not depend explicitly on what type of multicast signalling is used,
but the multiple phases of PIM setup could add complexity to their
implementation.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Within this document, the term "conditional access and admission This document reuses the terms "connection admission control" ("CAC"
control (CAC)" refers to the complete decision process for allowing or simply "admission control") and "conditional access" as they are
or disallowing a subscriber request for a new flow. This process used in [RFC5851].
consists of two parts: policy-based admission control and resource-
based admission control. The NAS can delegate policy-based admission
control to the Access Node if both devices support conditional access
with white and black lists. It can delegate resource-based admission
control to the Access Node if both devices support any of the
capabilities described in this document besides or other than
committed bandwidth reporting. The delegation is performed on a per-
subscriber basis using the Provisioning (Section 4.1) and Port
Management (Section 4.2) messages.
The expression "delegated bandwidth" is used as a shorter way of The expression "delegated bandwidth" is used as a shorter way of
saying: "the total amount of video bandwidth delegated to the AN for saying: "the total amount of video bandwidth delegated to the AN for
multicast resource-based admission control". multicast admission control".
3. Multicast Use Cases 3. Multicast Use Cases
Quoting from [RFC5851]: Quoting from [RFC5851]:
"... the Access Node, aggregation node(s) and the NAS must all be "... the Access Node, aggregation node(s) and the NAS must all be
involved in the multicast replication process. This avoids that involved in the multicast replication process. This avoids that
several copies of the same stream are sent within the access/ several copies of the same stream are sent within the access/
aggregation network. In case of an Ethernet-based access/aggregation aggregation network. In case of an Ethernet-based access/aggregation
network, this may, for example, be achieved by means of IGMP snooping network, this may, for example, be achieved by means of IGMP snooping
skipping to change at page 7, line 34 skipping to change at page 8, line 10
Node and the NAS." Node and the NAS."
[RFC5851] describes the use cases for ANCP associated with such [RFC5851] describes the use cases for ANCP associated with such
multicast operations, and identifies the associated ANCP multicast operations, and identifies the associated ANCP
requirements. The present section describes a subset of these use requirements. The present section describes a subset of these use
cases as background to facilitate reading of this document, but the cases as background to facilitate reading of this document, but the
reader is referred to [RFC5851] for a more exhaustive description of reader is referred to [RFC5851] for a more exhaustive description of
the ANCP multicast use cases. Detailed example message flows can the ANCP multicast use cases. Detailed example message flows can
also be found in Appendix A. also be found in Appendix 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.
3.1. NAS Initiated Multicast Replication Control Use Case 3.1. NAS Initiated Multicast Replication Control Use Case
3.1.1. Goals 3.1.1. Goals
One option for multicast handling is for the subscriber to One option for multicast handling is for the subscriber to
communicate the "join/leave" information to the NAS. This can be communicate the "join/leave" information to the NAS. This can be
done for instance by terminating all subscriber IGMP ([RFC3376]) or done for instance by terminating all subscriber IGMP ([RFC3376]) or
MLD ([RFC2710], [RFC3810]) signaling on the NAS. Another example MLD ([RFC2710], [RFC3810]) signaling on the NAS. Another example
could be a subscriber using some form of application level signaling, could be a subscriber using some form of application level signaling,
which is redirected to the NAS. In any case, this option is which is redirected to the NAS. In any case, this option is
skipping to change at page 8, line 15 skipping to change at page 9, line 6
3.1.2. Message Flow 3.1.2. Message Flow
With the NAS-initiated use case, a Multicast Replication Control 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 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 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 flow, the AN uses a Generic Response message to convey the outcome of
the directive. Figure 1 illustrates such an ANCP message exchange as the directive. Figure 1 illustrates such an ANCP message exchange as
well as the associated AN behavior. well as the associated AN behavior.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<-------------------->| NAS | |Subscriber| | Home | | AN |<-------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | (*) | | | (*)
| | | Multicast-Replication-Ctl | | | | Multicast-Replication-Ctl |
| | | (Target,add, Flow 1) | | | | (Target, add, Flow 1) |
| | |<--------------------------| | | |<--------------------------|
| Mcast Flow 1 | | | Mcast Flow 1 | |
|<==========================+ | |<===========+==============+ |
| | | Generic Response | | | | Generic Response |
| | |-------------------------->| | | |-------------------------->|
| | | | | | | |
| | | | | | | |
~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | |
| | | Multicast-Replication-Ctl | | | | Multicast-Replication-Ctl |
| | | (Target,delete, Flow 1) | | | | (Target,delete, Flow 1) |
| | |<--------------------------| | | |<--------------------------|
| | | | | | | |
skipping to change at page 9, line 20 skipping to change at page 11, line 6
on detection of an IGMP/MLD Join, the AN sends an Admission Control on detection of an IGMP/MLD Join, the AN sends an Admission Control
message to the NAS to request a conditional access and admission message to the NAS to request a conditional access and admission
control check. In the case of a positive outcome, the NAS sends a control check. In the case of a positive outcome, the NAS sends a
Multicast Replication Control Message to the AN with a directive to Multicast Replication Control Message to the AN with a directive to
replicate the multicast flow to the corresponding user. Similarly on replicate the multicast flow to the corresponding user. Similarly on
detection of an IGMP/MLD leave, an Admission Control message is sent detection of an IGMP/MLD leave, an Admission Control message is sent
by the AN to the NAS to keep the NAS aware of user departure for the 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. flow. This message flow is illustrated in Figure 2.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<------------------->| NAS | |Subscriber| | Home | | AN |<------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | | | | | |
| Join(Gr-Flow1) | Admission-Control | | Join(Gr-Flow1) | Admission-Control |
|------------+---------->| (Target,add,Gr-Flow1) | |------------+---------->| (Target,add,Gr-Flow1) |
| | |-------------------------->| | | |-------------------------->|
| | | (*) | | | (*)
| | | Multicast-Replication-Crl | | | | Multicast-Replication-Crl |
| | | (Target,add,Gr-Flow1) | | | | (Target,add,Gr-Flow1) |
| | |<--------------------------| | | |<--------------------------|
| Mcast Gr-Flow1 | | | Mcast Gr-Flow1 | |
|<=======================+ | |<===========+===========+ |
| | | | | | | |
~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | |
| Leave(Gr-Flow1) | Admission-Control | | Leave(Gr-Flow1) | Admission-Control |
|------------+---------->| (Target,delete,Gr-Flow1) | |------------+---------->| (Target,delete,Gr-Flow1) |
| | |-------------------------->| | | |-------------------------->|
| <Stop Replication of X | | <Stop Replication of X |
| Mcast Gr-Flow1> | | | Mcast Gr-Flow1> | |
| | | | | | | |
Gr-Flow1: a multicast flow matching the grey list for that port Gr-Flow1: a multicast flow matching the grey list for that port
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Authorization/Policy Server before admitting the flow. Authorization/Policy Server before admitting the flow.
Figure 2: Multicast Conditional Access and Admission Control Figure 2: Multicast Conditional Access and Admission Control
skipping to change at page 11, line 20 skipping to change at page 13, line 20
+-----+ +-------+ +-----+ ANCP +-----+ +-----+ +-------+ +-----+ ANCP +-----+
|Subs |+ | Home |+ | AN |<---------->| NAS | |Subs |+ | Home |+ | AN |<---------->| NAS |
|1,2 || |GW 1,2 || +-----+ +-----+ |1,2 || |GW 1,2 || +-----+ +-----+
+-----+| +-------+| | | +-----+| +-------+| | |
+|----+ +|------+ | | +|----+ +|------+ | |
| | | | | | | | | | | |
| |Join(Subs1, Ch1) | | | |Join(Subs1, Ch1) | |
|----------+--------------->| Start buffering | |----------+--------------->| Start buffering |
| | | Multicast flow | timer. Create | | | | Multicast flow | timer. Create |
|<==========================| message with | |<======+===================| message with |
| | | | | initial contents | | | | | | initial contents |
| | | | | reporting new | | | | | | reporting new |
| | | | | Subs1 bandwidth. | | | | | | Subs1 bandwidth. |
| | Join(Subs2, Ch2) | | | | Join(Subs2, Ch2) | |
| |----------+------------->| Add report for | | |----------+------------->| Add report for |
| | | Multicast flow | new Subs2 b/w. | | | | Multicast flow | new Subs2 b/w. |
| |<========================| | | |<======+=================| |
| | | | | | | | | | | |
| |Leave(Subs1, Ch1) | | | |Leave(Subs1, Ch1) | |
|----------+--------------->| Replace report | |----------+--------------->| Replace report |
| | | | | for Subs1 with | | | | | | for Subs1 with |
| | Stop replication X new value (which | | | Stop replication X new value (which |
| | | | | happens to be | | | | | | happens to be |
| | | | | the same as the | | | | | | the same as the |
| | | | | starting value. | | | | | | starting value. |
| | | | | | | | | | | |
| | | | >|< TIMER expires | | | | | >|< TIMER expires |
skipping to change at page 12, line 35 skipping to change at page 14, line 35
o one or more instances of the Multicast-Service-Profile TLV. The o one or more instances of the Multicast-Service-Profile TLV. The
Multicast-Service-Profile TLV is defined in the present document Multicast-Service-Profile TLV is defined in the present document
in Section 5.1. Each instance of the Multicast-Service-Profile in Section 5.1. Each instance of the Multicast-Service-Profile
TLV contains a multicast service profile name and one or more list TLV contains a multicast service profile name and one or more list
actions. A list action consists of an action (add, delete, actions. A list action consists of an action (add, delete,
replace), a list type (white, black, or grey), and list content replace), a list type (white, black, or grey), and list content
(multicast source and group addresses). (multicast source and group addresses).
o an instance of the White-List-CAC TLV. The White-List-CAC TLV is 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 defined in Section 5.6. If present, this TLV indicates that the
AN is required to do resource-based admission control before AN is required to do admission control before replicating white-
replicating white-listed flows. listed flows.
o an instance of the MRepCtl-CAC TLV. The MRepCtl-CAC TLV is 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 defined in Section 5.7. If present, this TLV indicates that the
AN is required to do resource-based admission control before AN is required to do admission control before replicating flows
replicating flows specified in Multicast Replication Control specified in Multicast Replication Control messages.
messages.
o an instance of the Report-Buffering-Time TLV. The Report- o an instance of the Report-Buffering-Time TLV. The Report-
Buffering-Time TLV is defined in Section 5.13. If present, this Buffering- Time TLV is defined in Section 5.13. If present, this
TLV indicates Committed Bandwidth Report messages should be TLV indicates Committed Bandwidth Report messages should be
buffered for the amount of time given by the TLV before being buffered for the amount of time given by the TLV before being
transmitted to the NAS. transmitted to the NAS.
See Section 6 for information on which multicast capabilities require See Section 6 for information on which multicast capabilities require
support of these TLVs in the Provisioning message. support of these TLVs in the Provisioning message.
4.1.1. Sender Behaviour 4.1.1. Sender Behaviour
When directed by the Policy Server or by management action, the NAS When directed by the Policy Server or by management action, the NAS
sends the Provisioning message to initially provision or to update sends the Provisioning message to initially provision or to update
the white, black, and/or grey multicast channel lists associated with the white, black, and/or grey multicast channel lists associated with
a set of named multicast service profiles, or to direct the AN to a set of named multicast service profiles, or to direct the AN to
perform resource-based admission control for specific classes of perform admission control for specific classes of flows.
flows.
To provision or update a multicast service profile, the NAS MUST To provision or update a multicast service profile, the NAS MUST
include within the message one or more instances of the Multicast- include within the message one or more instances of the Multicast-
Service-Profile TLV specifying the content to be provisioned or Service-Profile TLV specifying the content to be provisioned or
updated. The NAS SHOULD NOT include any list type (white, black, or updated. The NAS MUST NOT include any list type (white, black, or
grey) that is not supported by the set of multicast capabilities grey) that is not supported by the set of multicast capabilities
negotiated between the NAS and the AN. The NAS MUST NOT use the negotiated between the NAS and the AN. The NAS MUST NOT use the
Provisioning message to send instances of the Multicast-Service- Provisioning message to send instances of the Multicast-Service-
Profile TLV to the AN unless the Multicast-Service-Profile TLV is Profile TLV to the AN unless the Multicast-Service-Profile TLV is
supported by the set of multicast capabilities negotiated between the supported by the set of multicast capabilities negotiated between the
NAS and the AN. NAS and the AN.
To require resource-based admission control to be performed at the AN To require admission control to be performed at the AN on white-
on white-listed flows, the NAS MUST include a copy of the White-List- listed flows, the NAS MUST include a copy of the White-List-CAC TLV
CAC TLV in the Provisioning message. The White-List-CAC TLV MUST NOT in the Provisioning message. The White-List-CAC TLV MUST NOT be
be provided unless the negotiated set of capabilities includes provided unless the negotiated set of capabilities includes
conditional access with white and black lists. conditional access and admission control with white and black lists.
To require resource-based admission control to be performed at the AN To require admission control to be performed at the AN on grey-listed
on grey-listed flows or on NAS-initiated flows, the NAS MUST include flows or on NAS-initiated flows, the NAS MUST include a copy of the
a copy of the MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV
MRepCtl-CAC TLV MUST NOT be provided unless the negotiated set of MUST NOT be provided unless the negotiated set of capabilities
capabilities includes NAS-initiated replication control or includes NAS-initiated replication control or conditional access and
conditional access with grey lists. admission control with grey lists.
To require buffering of Committed Bandwidth Report messages so that To require buffering of Committed Bandwidth Report messages so that
reports for multiple access lines can be included in the same reports for multiple access lines can be included in the same
message, the NAS MUST include a copy of the Report-Buffering-Time TLV 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 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 AN. The Report-Buffering-Time TLV MUST NOT be provided unless
the negotiated set of capabilities includes committed bandwidth the negotiated set of capabilities includes committed bandwidth
reporting. reporting.
4.1.2. Receiver Behaviour 4.1.2. Receiver Behaviour
skipping to change at page 14, line 23 skipping to change at page 16, line 22
capabilities is empty until changed by the contents of Multicast- capabilities is empty until changed by the contents of Multicast-
Service-Profile TLVs. Service-Profile TLVs.
The receipt of a Provisioning message containing updates to an The receipt of a Provisioning message containing updates to an
existing multicast service profile subsequent to startup will cause existing multicast service profile subsequent to startup will cause
the AN to review the status of active flows on all ports to which 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. that profile has been assigned. For further details, see Section 6.
If the White-List-CAC and/or MRepCtl-CAC TLV is present in the If the White-List-CAC and/or MRepCtl-CAC TLV is present in the
Provisioning message and the respective associated capabilities have Provisioning message and the respective associated capabilities have
been negotiated, the AN prepares (or continues) to do resource-based been negotiated, the AN prepares (or continues) to do admission
admission control on the indicated class(es) of flow. If one or both control on the indicated class(es) of flow. If one or both of these
of these TLVs was present in an earlier Provisioning message but is TLVs was present in an earlier Provisioning message but is absent in
absent in the latest message received, the AN ceases to do resource- the latest message received, the AN ceases to do admission control on
based admission control on the indicated class(es) of flow. the indicated class(es) of flow.
The buffering time specified in an instance of the Report-Buffering- The buffering time specified in an instance of the Report-Buffering-
Time TLV applies only to Committed Bandwidth Report messages Time TLV will not be applied until the current accumulation process
initiated after the new buffering time is received at the AN, not to of Committed Bandwidth Report messages finishes.
any message already in the process of accumulation.
As indicated in [RFC6320], the AN MUST NOT reply to the Provisioning As indicated in [RFC6320], the AN MUST NOT reply to the Provisioning
message if it processed it successfully. If an error prevents message if it processed it successfully. If an error prevents
successful processing of the message content, the AN MUST return a successful processing of the message content, the AN MUST return a
Generic Response message as defined in [RFC6320], containing a Generic Response message as defined in [RFC6320], containing a
Status-Info TLV with the appropriate content describing the error. Status-Info TLV with the appropriate content describing the error.
For this purpose, the presence of a list type in a Multicast-Service- 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 Profile TLV which was ignored because it was not supported by the
negotiated set of capabilities is not considered to be an error. negotiated set of capabilities is not considered to be an error.
skipping to change at page 15, line 8 skipping to change at page 17, line 8
information to the AN ("ANCP based DSL Line Configuration" use case) information to the AN ("ANCP based DSL Line Configuration" use case)
using ANCP Port Management messages. See Section 7.3 of [RFC6320] using ANCP Port Management messages. See Section 7.3 of [RFC6320]
for the format of the Port Management message in that usage. for the format of the Port Management message in that usage.
This document specifies that the Port Management message MAY be used This document specifies that the Port Management message MAY be used
to convey either or both of the following TLVs: to convey either or both of the following TLVs:
o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This
TLV associates a Multicast Service Profile with the access line TLV associates a Multicast Service Profile with the access line
specified by the extension block, and in the case of white and specified by the extension block, and in the case of white and
black lists, delegates policy-based admission control to the AN black lists, delegates conditional access to the AN for the
for the specified access line and channels. specified access line and channels.
o Bandwidth-Allocation TLV (defined in Section 5.5). This TLV o Bandwidth-Allocation TLV (defined in Section 5.5). This TLV
specifies the total multicast bandwidth available to the AN for specifies the total multicast bandwidth available to the AN for
resource-based admission control at the access line. admission control at the access line.
When the Port Management message is used for this purpose: When the Port Management message is used for this purpose:
o the Function field in the Port Management message MUST be set to o the Function field in the Port Management message MUST be set to
8, "Configure Connection Service Data". 8, "Configure Connection Service Data".
o the message MUST include TLV(s) to identify the access line o the message MUST include TLV(s) to identify the access line
concerned. If the access line is a DSL loop, the line-identifying 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 TLV(s) MUST be as specified in Section 5.1.2 of [RFC6320]. For
non-DSL access lines, the appropriate alternative line-identifying non-DSL access lines, the appropriate alternative line-identifying
skipping to change at page 20, line 43 skipping to change at page 22, line 43
of the accounting feature to what is set in the final command of the accounting feature to what is set in the final command
received, but all other features are unaffected by the second received, but all other features are unaffected by the second
message. message.
If more than one Command TLV is present in a Multicast Replication 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 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 which they are presented in the message. The AN SHALL assign a
sequence number to each command in a given Multicast Replication sequence number to each command in a given Multicast Replication
Control message, starting from 1 for the first command. Control message, starting from 1 for the first command.
If a Command TLV adds a flow and the AN is performing resource-based If a Command TLV adds one or more flows and the AN is performing
admission control for Multicast Replication Control messages, then admission control for Multicast Replication Control messages, then
the AN MUST perform admission control before replicating the flow. the AN MUST perform admission control before replicating the flows.
If the admission control check fails, the AN MUST treat the failure If the admission control check fails, the AN MUST treat the failure
as an error as described below. The appropriate Result Code value as an error as described below. The appropriate Result Code value
for the response is 0x13 "Out of resources". for the response is 0x13 "Out of resources".
If the AN processes the complete Multicast Replication Control If the AN processes the complete Multicast Replication Control
message successfully and the Result field of the Multicast message successfully and the Result field of the Multicast
Replication Control message was set to AckAll (0x2), the AN MUST Replication Control message was set to AckAll (0x2), the AN MUST
respond with a Generic Response message where the Result field is set 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 to Success (0x3), the Result Code field is set to 0, and the
Transaction Identifier field is copied from the Multicast Replication Transaction Identifier field is copied from the Multicast Replication
skipping to change at page 21, line 18 skipping to change at page 23, line 18
copied from the Multicast Replication Control message. copied from the Multicast Replication Control message.
If the AN processes the complete Multicast Replication Control If the AN processes the complete Multicast Replication Control
message successfully and the Result field of the Multicast message successfully and the Result field of the Multicast
Replication Control message was set to Nack (0x1), the AN MUST NOT Replication Control message was set to Nack (0x1), the AN MUST NOT
respond to the message. respond to the message.
The processing/execution of multiple commands contained in a single The processing/execution of multiple commands contained in a single
Multicast Control message MUST be interrupted at the first error Multicast Control message MUST be interrupted at the first error
encountered, and the remaining commands in the Multicast Replication encountered, and the remaining commands in the Multicast Replication
Control message discarded. Control message discarded. Similarly, if a given command specifies
multiple Single-Source Multicast (SSM) flows and a error occurs,
processing MUST be interrupted at that point and the remainder of the
Command TLV discarded.
If the AN detects an error in a received Multicast Replication If the AN detects an error in a received Multicast Replication
Control message and the Result field in that message was set to Nack 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 (0x1) or AckAll(0x2), the AN MUST generate a Generic Response message
providing error information to the NAS. This specification providing error information to the NAS. This specification
identifies the following new Result Code values beyond those identifies the following new Result Code values beyond those
specified in [RFC6320], which MAY be used in a Generic Response sent specified in [RFC6320], which MAY be used in a Generic Response sent
in reply to a Multicast Replication Control message: in reply to a Multicast Replication Control message:
0x64 Command error. 0x64 Command error.
skipping to change at page 23, line 25 skipping to change at page 25, line 28
Note: Note:
In the future, the specification of the Admission Control message In the future, the specification of the Admission Control message
may be extended to allow transport of more than a single directive 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 (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 group for the same Target). It is expected that this would
support a similar notion of strict sequenced processing as support a similar notion of strict sequenced processing as
currently defined for handling multiple directives in the currently defined for handling multiple directives in the
Multicast Replication Control message whereby all directives Multicast Replication Control message whereby all directives
following the first directive that can not be executed are not following the first directive that cannot be executed are not
executed either. When the strict sequenced processing of the executed either. When the strict sequenced processing of the
directives is not required the directives are distributed across directives is not required the directives are distributed across
separate messages. separate messages.
The Command TLV has the same contents as were described above for the The Command TLV has the same contents as were described above for the
Multicast Replication Control message, with the following additions: Multicast Replication Control message, with the following additions:
o a Request-Source-IP TLV MAY be appended to the Command TLV as an o a Request-Source-IP TLV MAY be appended to the Command TLV as an
additional embedded TLV; additional embedded TLV;
skipping to change at page 24, line 48 skipping to change at page 26, line 51
first instance is considered meaningful and the other instances first instance is considered meaningful and the other instances
are ignored. are ignored.
The inclusion of Request-Source-IP or Request-Source-MAC in the The inclusion of Request-Source-IP or Request-Source-MAC in the
Multicast Admission Control message is typically done to allow the Multicast Admission Control message is typically done to allow the
application of policies applicable to specific devices within the application of policies applicable to specific devices within the
customer's network. However, transmission of either of these fields customer's network. However, transmission of either of these fields
beyond the AN introduces potential privacy issues. Instead of beyond the AN introduces potential privacy issues. Instead of
transmitting either of these identifiers, it is RECOMMENDED that the transmitting either of these identifiers, it is RECOMMENDED that the
AN map the required identifier to a local value known to the AN and AN map the required identifier to a local value known to the AN and
AAA but not to the NAS, as discussed in Section 7. The local AAA but not to the NAS, as discussed in Section 8. The local
identifier is transmitted using the Request-Source-Device-Id TLV. identifier is transmitted using the Request-Source-Device-Id TLV.
4.4.2. Receiver Behaviour 4.4.2. Receiver Behaviour
On receipt of an Multicast Admission Control message, the NAS: On receipt of an Multicast Admission Control message, the NAS:
o MUST ignore the Result field; o MUST ignore the Result field;
o if the directive in the Multicast Admission Control message is o if the directive in the Multicast Admission Control message is
"Delete" (2) or "Delete All" (3) and is processed correctly by the "Delete" (2) or "Delete All" (3) and is processed correctly by the
skipping to change at page 25, line 31 skipping to change at page 27, line 31
* MUST contain a Result set to Nack (0x1); * MUST contain a Result set to Nack (0x1);
* MUST contain a Transaction ID with a unique value, as described * MUST contain a Transaction ID with a unique value, as described
in Section 3.6.1.6 of [RFC6320]; in Section 3.6.1.6 of [RFC6320];
* MUST contain the directive as accepted by the NAS. The NAS MAY * MUST contain the directive as accepted by the NAS. The NAS MAY
modify the Accounting field if flow accounting is required. modify the Accounting field if flow accounting is required.
o if the directive in the Multicast Admission Control message is o if the directive in the Multicast Admission Control message is
"Add" (1), is processed correctly but not accepted by the NAS "Add" (1) and is processed correctly but not accepted by the NAS
(i.e., it does not pass the conditional access and admission (i.e., it does not pass the conditional access and admission
control check), the NAS MAY generate a Multicast Replication control check), the NAS MAY generate a Multicast Replication
Control message in response to the Multicast Admission Control Control message in response to the Multicast Admission Control
message. This optional message can be used by the AN to maintain message. This optional message can be used by the AN to maintain
statistics about admission control rejections. When used in this statistics about admission control rejections. When used in this
situation, the Multicast Replication Control message: situation, the Multicast Replication Control message:
* MUST contain a Result set to 0x0; * MUST contain a Result set to 0x0;
* MUST contain a Transaction ID with a unique value, as described * MUST contain a Transaction ID with a unique value, as described
skipping to change at page 30, line 39 skipping to change at page 32, line 39
This allows the receiver to distinguish between an autonomous This allows the receiver to distinguish between an autonomous
transfer and a response to a previous Bandwidth Reallocation transfer and a response to a previous Bandwidth Reallocation
Request, for purposes of validation. Request, for purposes of validation.
The Message Type for the Bandwidth Transfer message is 147. The The Message Type for the Bandwidth Transfer message is 147. The
Bandwidth Transfer message contains the following TLVs: Bandwidth Transfer message contains the following TLVs:
o the Target TLV, designating the access line concerned; o the Target TLV, designating the access line concerned;
o an instance of the Bandwidth-Allocation TLV (Section 5.5). The o an instance of the Bandwidth-Allocation TLV (Section 5.5). The
bandwidth value in the Bandwidth-Allocation TLV is the new amount bandwidth value in the Bandwidth- Allocation TLV is the new amount
of delegated bandwidth allocated to the target. of delegated bandwidth allocated to the target.
4.6.1. Sender Behaviour 4.6.1. Sender Behaviour
When sending a Bandwidth Transfer message where the Result value is When sending a Bandwidth Transfer message where the Result value is
Ignore (0x0) or Success (0x3), the following relationships MUST hold: Ignore (0x0) or Success (0x3), the following relationships MUST hold:
o if the message is sent by the NAS, the bandwidth value in the 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 Bandwidth-Allocation TLV MUST be greater than or equal to the
sender's view of the current amount of delegated bandwidth for the sender's view of the current amount of delegated bandwidth for the
skipping to change at page 32, line 46 skipping to change at page 34, line 46
value MUST be set to 0. The sender MUST populate the ANCP value MUST be set to 0. The sender MUST populate the ANCP
Transaction Identifier field with a unique value, as described in Transaction Identifier field with a unique value, as described in
Section 3.6.1.6 of [RFC6320]. Section 3.6.1.6 of [RFC6320].
4.7.2. Receiver Behaviour 4.7.2. Receiver Behaviour
If the AN or NAS receives a valid Delegated Bandwidth Query Request If the AN or NAS receives a valid Delegated Bandwidth Query Request
message, it MUST respond with a Delegated Bandwidth Query Response message, it MUST respond with a Delegated Bandwidth Query Response
message. The Result field in the header of the response MUST be set 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 to Success (0x3). The Result Code field MUST be set to 0. The
Transaction-Id field MUST be copied from the request message. The Transaction- Id field MUST be copied from the request message. The
body of the response MUST contain the Target TLV, copied from the body of the response MUST contain the Target TLV, copied from the
request message. Finally, the body of the response MUST contain a request message. Finally, the body of the response MUST contain a
Bandwidth-Allocation TLV, containing the current amount of delegated Bandwidth-Allocation TLV, containing the current amount of delegated
bandwidth from the point of view of the receiver of the request. bandwidth from the point of view of the receiver of the request.
If the contents of the Delegated Bandwidth Query Request message are If the contents of the Delegated Bandwidth Query Request message are
in error, the receiver MUST return a Delegated Bandwidth Query in error, the receiver MUST return a Delegated Bandwidth Query
Response message with the Result field in the header set to Failure 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 (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 the nature of the error (e.g., 0x500 "One or more of the specified
skipping to change at page 35, line 39 skipping to change at page 37, line 39
active on each port of the AN, the NAS MUST send a Multicast Flow active on each port of the AN, the NAS MUST send a Multicast Flow
Query Request which does not contain any instance of the Target TLV Query Request which does not contain any instance of the Target TLV
or the Multicast-Flow TLV. or the Multicast-Flow TLV.
4.9.2. Receiver Behaviour 4.9.2. Receiver Behaviour
The AN MUST respond to a Multicast Flow Query Request message that 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 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 Response message. The Result field in the response MUST be set to
Success (0x3). The Result Code field MUST be set to 0. The Success (0x3). The Result Code field MUST be set to 0. The
Transaction-Id field MUST be copied from the request. Transaction- Id field MUST be copied from the request.
If the Multicast Flow Query Request contained one (or more) Target If the Multicast Flow Query Request contained one (or more) Target
TLVs, the AN MUST include, for each of these Target TLVs, the TLVs, the AN MUST include, for each of these Target TLVs, the
following set of TLVs: following set of TLVs:
o Target TLV. This MUST be identical to the Target TLV in the o Target TLV. This MUST be identical to the Target TLV in the
received Multicast Flow Query Request message. received Multicast Flow Query Request message.
o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once
per multicast flow that is currently active on the AN port per multicast flow that is currently active on the AN port
skipping to change at page 46, line 46 skipping to change at page 48, line 46
multicast channel. The TLV is illustrated in Figure 17. multicast channel. The TLV is illustrated in Figure 17.
1 2 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 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 | | Request-Source-Device-Id | TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier value | | Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Request-Source-Device-Id TLV Figure 17: Request-Source-Device- Id TLV
The Request-Source-Device-Id TLV contains the following fields: The Request-Source-Device-Id TLV contains the following fields:
o The Request-Source-IP TLV Type is 0x0096. o The Request-Source-IP TLV Type is 0x0096.
o TLV length is 4. o TLV length is 4.
o Local device identifier value, known to the AN and AAA. Given o Local device identifier value, known to the AN and AAA. Given
that the scope of the identifier is a single customer network, 32 that the scope of the identifier is a single customer network, 32
bits is a more than sufficient numbering space. bits is a more than sufficient numbering space.
5.12. Multicast-Flow TLV 5.12. Multicast-Flow TLV
The Multicast-Flow TLV specifies a multicast flow in terms of its IGMPv3 [RFC3376] and MLDv2 [RFC3801] allow multicast listeners to
multicast group address and, if applicable, its unicast source specify multiple source addresses for the same multicast group.
address. It is illustrated in Figure 18. 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 18.
1 2 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 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 | | Type = Multicast-Flow 0x0019 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Addr Family | Reserved | | Flow Type | Addr Family | Number of source addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address | | Multicast Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Unicast Source Address (for SSM flows only) | | Unicast Source Address (for SSM flows only) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Multicast-Flow TLV Figure 18: Multicast-Flow TLV
The Multicast-Flow TLV has the following fields: The Multicast-Flow TLV has the following fields:
o The Multicast-Flow TLV Type is 0x0019. o The Multicast-Flow TLV Type is 0x0019.
o TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow) to o TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow)
36 (for an IPv6 SSM 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 Flow Type: 1 "Any Source Multicast (ASM)", 2 "Source-Specific o Flow Type: 1 "Any Source Multicast (ASM)", 2 "Source-Specific
Multicast (SSM)". Multicast (SSM)".
o Addr Family: address family of the multicast source and group o Addr Family: address family of the multicast source and group
addresses, encoded in accordance with the IANA PIM Address Family addresses, encoded in accordance with the IANA PIM Address Family
registry ([PIMreg]). 1 indicates IPv4, 2 indicates IPv6. registry ([PIMreg]). 1 indicates IPv4, 2 indicates IPv6.
o Reserved: MUST be set to zeroes by the sender and MUST be ignored o Number of Source Addresses: 0 for ASM, 1 or more for SSM.
by the receiver.
One possible use for this field in the future is to indicate
the presence of PIM Join attributes attached to the source
address (see [RFC5384]). The applicability of PIM attributes
in the context of ANCP is for further study.
o Multicast Group Address: a multicast group address within the o Multicast Group Address: a multicast group address within the
given address family. The group address MUST always be present. given address family. The group address MUST always be present.
o Unicast Source Address: unicast address within the given address o Unicast Source Address: unicast address within the given address
family. If the Flow Type is "ASM" (1), a source address MUST NOT family. If the Flow Type is "ASM" (1), a source address MUST NOT
be present. If the Flow Type is "SSM" (2), a source address MUST be present. If the Flow Type is "SSM" (2), the number of source
be present. addresses given by the Number of Source Addresses field MUST be
present.
5.13. Report-Buffering-Time TLV 5.13. Report-Buffering-Time TLV
The Report-Buffering-Time TLV provides the time for which a Committed The Report-Buffering-Time TLV provides the time for which a Committed
Bandwidth Report message must be held with the intention of Bandwidth Report message must be held with the intention of
accumulating multiple reports of changed committed multicast accumulating multiple reports of changed committed multicast
bandwidth in one report, to reduce the volume of messages sent to the 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 NAS. For further information see Section 6.2.2. The TLV is
illustrated in Figure 19. illustrated in Figure 19.
skipping to change at page 49, line 42 skipping to change at page 51, line 42
6. Multicast Capabilities 6. Multicast Capabilities
Section 3.5 of [RFC6320] defines a capability negotiation mechanism Section 3.5 of [RFC6320] defines a capability negotiation mechanism
as well as a number of capabilities. This section defines five new as well as a number of capabilities. This section defines five new
capabilities in support of different modes of multicast operation: capabilities in support of different modes of multicast operation:
o NAS-initiated replication (capability type 3); o NAS-initiated replication (capability type 3);
o committed multicast bandwidth reporting (capability type 5); o committed multicast bandwidth reporting (capability type 5);
o conditional access with white and black lists (capability type 6); o conditional access and admission control with white and black
lists (capability type 6);
o conditional access with grey lists (capability type 7); o conditional access and admission control with grey lists
(capability type 7);
o bandwidth delegation (capability type 8). o bandwidth delegation (capability type 8).
The "Capability Data" field within the Capability TLV for all of The "Capability Data" field within the Capability TLV for all of
these capabilities is empty. All of these capabilities are these capabilities is empty. All of these capabilities are
independent of the access technology. independent of the access technology.
The remainder of this section consists of three sub-sections. The remainder of this section consists of three sub-sections.
Section 6.1 specifies the protocol elements that must be implemented Section 6.1 specifies the protocol elements that must be implemented
in order to support each capability. Section 6.2 specifies the in order to support each capability. Section 6.2 specifies the
skipping to change at page 51, line 8 skipping to change at page 53, line 8
Table 1 specifies the protocol elements within Section 4 and Table 1 specifies the protocol elements within Section 4 and
Section 5 that MUST be implemented to support the NAS-initiated Section 5 that MUST be implemented to support the NAS-initiated
replication multicast capability. Additionally, implementation of replication multicast capability. Additionally, implementation of
the Multicast Replication Control message requires implementation of the Multicast Replication Control message requires implementation of
the Command TLV (Section 4.4 of [RFC6320] with additional details in the Command TLV (Section 4.4 of [RFC6320] with additional details in
Section 4.3 of this document). Section 4.3 of this document).
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Reference | Protocol Element | | Reference | Protocol Element |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with MRepCtl-CAC TLV | | Section 4.1 | Provisioning message with MRepCtl-CAC TLV; |
| | | | | |
| Section 4.2 | Port Management message with Bandwidth-Allocation | | Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV. | | | TLV; |
| | | | | |
| Section 4.3 | Multicast Replication Control message | | Section 4.3 | Multicast Replication Control message; |
| | | | | |
| Section 4.9 | Multicast Flow Query Request and Response messages | | Section 4.9 | Multicast Flow Query Request and Response |
| | messages; |
| | | | | |
| Section 5.4 | Sequence Number TLV | | Section 5.4 | Sequence Number TLV; |
| | | | | |
| Section 5.5 | Bandwidth-Allocation TLV | | Section 5.5 | Bandwidth-Allocation TLV; |
| | | | | |
| Section 5.7 | MRepCtl-CAC TLV | | Section 5.7 | MRepCtl-CAC TLV; |
| | | | | |
| Section 5.12 | Multicast-Flow TLV | | Section 5.12 | Multicast-Flow TLV. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 1: Protocol Requirements For NAS-Initiated Replication Table 1: Protocol Requirements For NAS-Initiated Replication
6.1.2. Protocol Requirements For Committed Multicast Bandwidth 6.1.2. Protocol Requirements For Committed Multicast Bandwidth
Reporting Reporting
Table 2 specifies the protocol elements within Section 4 and Table 2 specifies the protocol elements within Section 4 and
Section 5 that MUST be implemented to support the committed multicast Section 5 that MUST be implemented to support the committed multicast
bandwidth reporting capability. bandwidth reporting capability.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Reference | Protocol Element | | Reference | Protocol Element |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Report-Buffering-Time | | Section 4.1 | Provisioning message with Report-Buffering-Time |
| | TLV | | | TLV; |
| | | | | |
| Section 4.10 | Committed Bandwidth Report message | | Section 4.10 | Committed Bandwidth Report message; |
| | | | | |
| Section 4.9 | Multicast Flow Query Request and Response messages | | Section 4.9 | Multicast Flow Query Request and Response |
| | messages; |
| | | | | |
| Section 5.13 | Report-Buffering-Timer TLV | | Section 5.13 | Report-Buffering-Timer TLV; |
| | | | | |
| Section 5.14 | Committed-Bandwidth TLV | | Section 5.14 | Committed-Bandwidth TLV; |
| | | | | |
| Section 5.12 | Multicast-Flow TLV | | Section 5.12 | Multicast-Flow TLV. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 2: Protocol Requirements For Committed Multicast Bandwidth Table 2: Protocol Requirements For Committed Multicast Bandwidth
Reporting Reporting
6.1.3. Protocol Requirements For Conditional Access With White and 6.1.3. Protocol Requirements For Conditional Access and Admission
Black Lists Control With White and Black Lists
Table 3 specifies the protocol elements within Section 4 and Table 3 specifies the protocol elements within Section 4 and
Section 5 that MUST be implemented to support the conditional access Section 5 that MUST be implemented to support the conditional access
with white and black lists multicast capability. and admission control with white and black lists multicast
capability.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Reference | Protocol Element | | Reference | Protocol Element |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Multicast-Service- | | Section 4.1 | Provisioning message with Multicast-Service- |
| | Profile TLV, white and black lists only, and | | | Profile TLV, white and black lists only, and |
| | White-List-CAC TLV | | | White-List-CAC TLV; |
| | | | | |
| Section 4.2 | Port Management message with Multicast-Service- | | Section 4.2 | Port Management message with Multicast-Service- |
| | Profile-Name and Bandwidth-Allocation TLVs. | | | Profile-Name and Bandwidth-Allocation TLVs; |
| | | | | |
| Section 4.9 | Multicast Flow Query Request and Response messages | | Section 4.9 | Multicast Flow Query Request and Response |
| | messages; |
| | | | | |
| Section 5.1 | Multicast-Service-Profile TLV | | Section 5.1 | Multicast-Service-Profile TLV; |
| | | | | |
| Section 5.2 | Multicast-Service-Profile-Name TLV | | Section 5.2 | Multicast-Service-Profile-Name TLV; |
| | | | | |
| Section 5.3 | List-Action TLV, white and black lists only | | Section 5.3 | List-Action TLV, white and black lists only; |
| | | | | |
| Section 5.5 | Bandwidth-Allocation TLV | | Section 5.5 | Bandwidth-Allocation TLV; |
| | | | | |
| Section 5.6 | White-List-CAC TLV | | Section 5.6 | White-List-CAC TLV; |
| | | | | |
| Section 5.12 | Multicast-Flow TLV | | Section 5.12 | Multicast-Flow TLV. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 3: Protocol Requirements For Conditional Access with White and Table 3: Protocol Requirements For Conditional Access and Admission
Black Lists Control with White and Black Lists
6.1.4. Protocol Requirements For Conditional Access With Grey Lists 6.1.4. Protocol Requirements For Conditional Access and Admission
Control With Grey Lists
Table 4 specifies the protocol elements within Section 4 and Table 4 specifies the protocol elements within Section 4 and
Section 5 that MUST be implemented to support the conditional access Section 5 that MUST be implemented to support the conditional access
with grey lists multicast capability. Additionally, implementation and admission control with grey lists multicast capability.
of the Multicast Replication Control message requires implementation Additionally, implementation of the Multicast Replication Control
of the Command TLV (Section 4.4 of [RFC6320] with additional details message requires implementation of the Command TLV (Section 4.4 of
in Section 4.3 of this document). [RFC6320] with additional details in Section 4.3 of this document).
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Reference | Protocol Element | | Reference | Protocol Element |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Multicast-Service- | | Section 4.1 | Provisioning message with Multicast-Service- |
| | Profile TLV, grey lists only, and MRepCtl-CAC TLV | | | Profile TLV, grey lists only, and MRepCtl-CAC TLV; |
| | | | | |
| Section 4.2 | Port Management message with Multicast-Service- | | Section 4.2 | Port Management message with Multicast-Service- |
| | Profile-Name and Bandwidth-Allocation TLVs. | | | Profile-Name and Bandwidth-Allocation TLVs; |
| | | | | |
| Section 4.3 | Multicast Replication Control message | | Section 4.3 | Multicast Replication Control message; |
| | | | | |
| Section 4.4 | Multicast Admission Control Message | | Section 4.4 | Multicast Admission Control message; |
| | | | | |
| Section 4.9 | Multicast Flow Query Request and Response messages | | Section 4.9 | Multicast Flow Query Request and Response |
| | messages; |
| | | | | |
| Section 5.1 | Multicast-Service-Profile TLV, grey lists only | | Section 5.1 | Multicast-Service-Profile TLV, grey lists only; |
| | | | | |
| Section 5.2 | Multicast-Service-Profile-Name TLV | | Section 5.2 | Multicast-Service-Profile-Name TLV; |
| | | | | |
| Section 5.3 | List-Action TLV, grey lists only | | Section 5.3 | List-Action TLV, grey lists only; |
| | | | | |
| Section 5.4 | Sequence Number TLV | | Section 5.4 | Sequence Number TLV; |
| | | | | |
| Section 5.5 | Bandwidth-Allocation TLV | | Section 5.5 | Bandwidth-Allocation TLV; |
| | | | | |
| Section 5.7 | MRepCtl-CAC TLV | | Section 5.7 | MRepCtl-CAC TLV; |
| | | | | |
| Section 5.9 | Request-Source-IP TLV | | Section 5.9 | Request-Source-IP TLV; |
| | | | | |
| Section 5.10 | Request-Source-MAC TLV | | Section 5.10 | Request-Source-MAC TLV; |
| | | | | |
| Section 5.11 | Request-Source-Device-Id TLV | | Section 5.11 | Request-Source-Device-Id TLV; |
| | | | | |
| Section 5.12 | Multicast-Flow TLV | | Section 5.12 | Multicast-Flow TLV. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 4: Protocol Requirements For Conditional Access with Grey Lists Table 4: Protocol Requirements For Conditional Access and Admission
Control with Grey Lists
6.1.5. Protocol Requirements For Delegated Bandwidth 6.1.5. Protocol Requirements For Delegated Bandwidth
Table 5 specifies the protocol elements within Section 4 and Table 5 specifies the protocol elements within Section 4 and
Section 5 that MUST be implemented to support the delegated bandwidth Section 5 that MUST be implemented to support the delegated bandwidth
multicast capability. multicast capability.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Reference | Protocol Element | | Reference | Protocol Element |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Section 4.2 | Port Management message with Bandwidth-Allocation | | Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV. | | | TLV; |
| | | | | |
| Section 4.5 | Bandwidth Reallocation Request Message | | Section 4.5 | Bandwidth Reallocation Request message; |
| | | | | |
| Section 4.6 | Bandwidth Transfer Message | | Section 4.6 | Bandwidth Transfer message; |
| | | | | |
| Section 4.7 | Delegated Bandwidth Query Request Message | | Section 4.7 | Delegated Bandwidth Query Request message; |
| | | | | |
| Section 4.8 | Delegated Bandwidth Query Response Message | | Section 4.8 | Delegated Bandwidth Query Response message |
| | | | | |
| Section 4.9 | Multicast Flow Query Request and Response messages | | Section 4.9 | Multicast Flow Query Request and Response |
| | messages; |
| | | | | |
| Section 5.5 | Bandwidth-Allocation TLV | | Section 5.5 | Bandwidth-Allocation TLV; |
| | | | | |
| Section 5.8 | Bandwidth-Request TLV | | Section 5.8 | Bandwidth-Request TLV; |
| | | | | |
| Section 5.12 | Multicast-Flow TLV | | Section 5.12 | Multicast-Flow TLV. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 5: Protocol Requirements For Delegated Bandwidth Table 5: Protocol Requirements For Delegated Bandwidth
6.2. Capability-Specific Procedures for Providing Multicast Service 6.2. Capability-Specific Procedures for Providing Multicast Service
This section describes multicast service procedures for each This section describes multicast service procedures for each
capability as if it were the only multicast capability within the capability as if it were the only multicast capability within the
negotiated set. Procedures involving combinations of multicast negotiated set. Procedures involving combinations of multicast
capabilities are described in Section 6.3. capabilities are described in Section 6.3.
skipping to change at page 56, line 7 skipping to change at page 58, line 7
NAS-initiated replication may be negotiated to support a mode of NAS-initiated replication may be negotiated to support a mode of
operation where IGMP/MLD requests are terminated on the NAS. operation where IGMP/MLD requests are terminated on the NAS.
Alternatively, it may be negotiated to allow the NAS to respond to Alternatively, it may be negotiated to allow the NAS to respond to
requests sent by other means (e.g., through application signalling) requests sent by other means (e.g., through application signalling)
that require the replication of multicast channels to a given access that require the replication of multicast channels to a given access
line. line.
6.2.1.1. Provisioning 6.2.1.1. Provisioning
The NAS MAY perform resource-based admission control for NAS- The NAS MAY perform admission control for NAS-initiated replication.
initiated replication. In this case, it MUST NOT include the In this case, it MUST NOT include the MRepCtl-CAC TLV in a
MRepCtl-CAC TLV in a Provisioning message sent to the AN. Provisioning message sent to the AN. Alternatively, the NAS MAY
Alternatively, the NAS MAY enable resource-based admission control at enable admission control at the AN for NAS-initiated replication. To
the AN for NAS-initiated replication. To do this, it MUST include do this, it MUST include the MRepCtl-CAC TLV in a Provisioning
the MRepCtl-CAC TLV in a Provisioning message sent to the AN and it message sent to the AN and it MUST also include a Bandwidth-
MUST also include a Bandwidth-Allocation TLV in a Port Management Allocation TLV in a Port Management message for each access line.
message for each access line.
6.2.1.2. Multicast Service Procedures 6.2.1.2. Multicast Service Procedures
The procedures associated with NAS-initiated replication are The procedures associated with NAS-initiated replication are
straightforward. To initiate replication, the NAS MUST send a straightforward. To initiate replication, the NAS MUST send a
Multicast Replication Control message to the AN, containing one or Multicast Replication Control message to the AN, containing one or
more commands adding flows, as described in Section 4.3.1. To more commands adding flows, as described in Section 4.3.1. To
terminate replication the NAS MUST send a Multicast Replication terminate replication the NAS MUST send a Multicast Replication
Control message where the commands delete instead of adding the Control message where the commands delete instead of adding the
flows. The AN acts upon these messages as specified in flows. The AN acts upon these messages as specified in
skipping to change at page 57, line 23 skipping to change at page 59, line 23
a line for which a Committed-Bandwidth TLV is already present in the a line for which a Committed-Bandwidth TLV is already present in the
buffered report, the AN MUST update the corresponding Committed- buffered report, the AN MUST update the corresponding Committed-
Bandwidth TLV to contain the new bandwidth value, rather than adding Bandwidth TLV to contain the new bandwidth value, rather than adding
another Committed-Bandwidth TLV for the same access line. another Committed-Bandwidth TLV for the same access line.
The buffering timer expires after the period provided by the Report- The buffering timer expires after the period provided by the Report-
Buffering-Time TLV. When it expires, the AN MUST send the Committed Buffering-Time TLV. When it expires, the AN MUST send the Committed
Bandwidth Report message that it has been accumulating to the NAS. Bandwidth Report message that it has been accumulating to the NAS.
Exceptionally, the AN MAY choose to send the message before the timer Exceptionally, the AN MAY choose to send the message before the timer
expires, in which case it MUST clear the buffering timer when the expires, in which case it MUST clear the buffering timer when the
message is sent. In either case, the AN enters the not-buffering message is sent. In either case, the AN enters the not- buffering
state as a result. state as a result.
Report buffering implies that NAS reaction to changes in multicast Report buffering implies that NAS reaction to changes in multicast
bandwidth usage is delayed by the amount of the buffering period. bandwidth usage is delayed by the amount of the buffering period.
The choice of buffering period must take this into consideration. The choice of buffering period must take this into consideration.
6.2.3. Procedures For Conditional Access With Black and White Lists 6.2.3. Procedures For Conditional Access and Admission Control With
Black and White Lists
6.2.3.1. Provisioning 6.2.3.1. Provisioning
The NAS provisions named multicast service profiles containing white The NAS provisions named multicast service profiles containing white
and black lists on the AN using the Provisioning message containing and black lists on the AN using the Provisioning message containing
one or more Multicast-Service-Profile TLVs. The NAS MAY update the one or more Multicast-Service-Profile TLVs. The NAS MAY update the
contents of these profiles from time to time as required, by sending contents of these profiles from time to time as required, by sending
additional Provisioning messages with Multicast-Service-Profile TLVs additional Provisioning messages with Multicast-Service-Profile TLVs
containing incremental modifications to the existing white and black containing incremental modifications to the existing white and black
lists or replacements for them. lists or replacements for them.
The NAS assigns a specific multicast service profile to an individual The NAS assigns a specific multicast service profile to an individual
access line using the Port Management message containing a Multicast- access line using the Port Management message containing a Multicast-
Service-Profile-Name TLV. The NAS MAY change the multicast service Service-Profile-Name TLV. The NAS MAY change the multicast service
profile for a given access line at any time by sending a Port profile for a given access line at any time by sending a Port
Management message identifying a new multicast service profile. Management message identifying a new multicast service profile.
The NAS MAY choose to enable resource-based admission control at the The NAS MAY choose to enable admission control at the AN for white-
AN for white-listed flows. To do this, it MUST send a Provisioning listed flows. To do this, it MUST send a Provisioning message as
message as described in Section 4.1, which includes the White-List- described in Section 4.1, which includes the White-List-CAC TLV and
CAC TLV and it MUST provide a multicast bandwidth allocation for each it MUST provide a multicast bandwidth allocation for each access line
access line by including a Bandwidth-Allocation TLV in a Port by including a Bandwidth-Allocation TLV in a Port Management message.
Management message.
6.2.3.2. Multicast Service Procedures 6.2.3.2. Multicast Service Procedures
The conditional access with white and black lists capability assumes The conditional access with white and black lists capability assumes
that IGMP/MLD requests are terminated on the AN. When the AN that IGMP/MLD requests are terminated on the AN. When the AN
receives a "join" request, it MUST check to see whether the requested receives a "join" request, it MUST check to see whether the requested
flow is white-listed or black-listed as described below. Requests flow is white-listed or black-listed as described below. Requests
for black-listed flows MUST be discarded. If the NAS has enabled for black-listed flows MUST be discarded. If the NAS has enabled
resource-based admission control on the AN as described in the admission control on the AN as described in the previous section, but
previous section, but a white-listed flow would cause the amount of a white-listed flow would cause the amount of committed multicast
committed multicast bandwidth to exceed the provisioned limit, the bandwidth to exceed the provisioned limit, the request MUST be
request MUST be discarded. The AN replicates flows passing these discarded. The AN replicates flows passing these checks to the
checks to the access line. access line.
To determine if a requested flow is white-listed, the AN searches for 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. a best match to the flow in the applicable multicast service profile.
Matching is done on the prefixes specified in the profile, ignoring Matching is done on the prefixes specified in the profile, ignoring
the address bits of lower order than those in the prefix. the address bits of lower order than those in the prefix.
If the requested multicast flow matches multiple lists associated If the requested multicast flow matches multiple lists associated
with the access line, then the most specific match will be considered 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 by the AN. If the most specific match occurs in multiple lists, the
black list entry takes precedence over the white list. In this black list entry takes precedence over the white list. In this
skipping to change at page 59, line 10 skipping to change at page 61, line 10
multicast service profile, the AN MUST review the status of active multicast service profile, the AN MUST review the status of active
flows on all ports to which the updated profile is currently flows on all ports to which the updated profile is currently
assigned. Similarly, if a Port Management message assigns a new assigned. Similarly, if a Port Management message assigns a new
multicast service profile to a given port, the AN MUST review all 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 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 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, 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 they also MUST be terminated immediately. White listed flows MUST be
allowed to continue. allowed to continue.
6.2.4. Procedures For Conditional Access With Grey Lists 6.2.4. Procedures For Conditional Access and Admission Control With
Grey Lists
6.2.4.1. Provisioning 6.2.4.1. Provisioning
The NAS provisions named multicast service profiles containing grey The NAS provisions named multicast service profiles containing grey
lists on the AN using the Provisioning message containing one or more lists on the AN using the Provisioning message containing one or more
Multicast-Service-Profile TLVs. The NAS MAY update the contents of Multicast-Service-Profile TLVs. The NAS MAY update the contents of
these profiles from time to time as required, by sending additional these profiles from time to time as required, by sending additional
Provisioning messages with Multicast-Service-Profile TLVs containing Provisioning messages with Multicast-Service-Profile TLVs containing
incremental modifications to the existing grey lists or replacements incremental modifications to the existing grey lists or replacements
for them. for them.
The NAS assigns a specific multicast service profile to an individual The NAS assigns a specific multicast service profile to an individual
access line using the Port Management message containing a Multicast- access line using the Port Management message containing a Multicast-
Service-Profile-Name TLV. The NAS MAY change profiles on the line by Service-Profile-Name TLV. The NAS MAY change profiles on the line by
sending a subsequent Port Management message identifying a new sending a subsequent Port Management message identifying a new
profile. profile.
The NAS MAY perform resource-based admission control for grey-listed The NAS MAY perform admission control for grey-listed flows. In that
flows. In that case, the NAS MUST NOT include the MRepCtl-CAC TLV in case, the NAS MUST NOT include the MRepCtl-CAC TLV in a Provisioning
a Provisioning message sent to the AN. Alternatively, the NAS MAY message sent to the AN. Alternatively, the NAS MAY enable admission
enable resource-based admission control at the AN for grey-listed control at the AN for grey-listed flows. To do this, it MUST include
flows. To do this, it MUST include the MRepCtl-CAC TLV in a the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST
Provisioning message sent to the AN and MUST also provide a also provide a Bandwidth-Allocation TLV in a Port Management message
Bandwidth-Allocation TLV in a Port Management message for each access for each access line.
line.
6.2.4.2. Multicast Service Procedures 6.2.4.2. Multicast Service Procedures
The conditional access with grey lists capability assumes that IGMP/ The conditional access and admission control with grey lists
MLD requests are terminated on the AN. When the AN receives a "join" capability assumes that IGMP/MLD requests are terminated on the AN.
request, it MUST determine whether there is a match to the requested When the AN receives a "join" request, it MUST determine whether
flow in the grey list of the multicast service profile provisioned there is a match to the requested flow in the grey list of the
against the given access line. If there is no match, the request is multicast service profile provisioned against the given access line.
discarded. Otherwise, the AN MUST send a Multicast Admission Control If there is no match, the request is discarded. Otherwise, the AN
message to the NAS with content identifying the access line and the MUST send a Multicast Admission Control message to the NAS with
multicast flow to be added. As indicated in Section 4.4, the AN MAY content identifying the access line and the multicast flow to be
add information identifying the requesting device. added. As indicated in Section 4.4, the AN MAY add information
identifying the requesting device.
If the NAS decides to enable the flow, it MUST send a Multicast If the NAS decides to enable the flow, it MUST send a Multicast
Replication Control request to the AN to replicate the flow to the Replication Control request to the AN to replicate the flow to the
access line with the Result field set to Nack (0x1), as described in access line with the Result field set to Nack (0x1), as described in
Section 4.3.1. Section 4.3.1.
When the AN receives the Multicast Replication Control request, it When the AN receives the Multicast Replication Control request, it
performs resource-based admission control if that has been enabled as performs admission control if that has been enabled as described in
described in the previous section. If admitting the flow would cause the previous section. If admitting the flow would cause the
the committed multicast bandwidth at the access line to exceed the committed multicast bandwidth at the access line to exceed the
provisioned limit, the AN reports an error to the NAS as described in provisioned limit, the AN reports an error to the NAS as described in
Section 4.3.2. Otherwise it replicates the multicast flow as Section 4.3.2. Otherwise it replicates the multicast flow as
requested. requested.
If the NAS decides not to permit the flow, it MAY send a Multicast If the NAS decides not to permit the flow, it MAY send a Multicast
Replication Control message in response to the Multicast Admission Replication Control message in response to the Multicast Admission
Control message to allow the AN to update its internal records. The Control message to allow the AN to update its internal records. The
content of this message is described in Section 4.4.2. content of this message is described in Section 4.4.2.
When the AN receives a "leave" request, it MUST terminate replication When the AN receives a "leave" request, it MUST terminate replication
of the flow to the access line. It MUST then send a Multicast of the flow to the access line. It MUST then send a Multicast
Admission Control message to the NAS indicating the deletion. The Admission Control message to the NAS indicating the deletion. The
NAS updates its internal records but MUST NOT respond to the message. NAS updates its internal records but MUST NOT respond to the message.
If the AN receives a Provisioning message which updates an existing If the AN receives a Provisioning message which updates an existing
multicast service profile, the AN MUST review the status of active multicast service profile, the AN MUST review the status of active
flows on all ports to which the updated profile has been assigned. flows on all ports to which the updated profile has been assigned.
Similarly, if a Port Management message that assigns a new profile to Similarly, if the AN receives a Port Management message that assigns
a given port, the AN MUST review all active flows on that port. In a new profile to a given port, the AN MUST review all active flows on
either case, if any flow does not match an entry in the grey list, it that port. In either case, if any flow does not match an entry in
MUST be terminated immediately. the grey list, it MUST be terminated immediately.
6.2.5. Procedures For Delegated Bandwidth 6.2.5. Procedures For Delegated Bandwidth
6.2.5.1. Provisioning 6.2.5.1. Provisioning
The NAS SHOULD provision an initial amount of delegated multicast The NAS SHOULD provision an initial amount of delegated multicast
bandwidth for each access line using the Port Management message bandwidth for each access line using the Port Management message
containing the Bandwidth-Allocation TLV. containing the Bandwidth-Allocation TLV.
If it fails to do so and a value has not been provisioned on the If it fails to do so and a value has not been provisioned on the
skipping to change at page 61, line 38 skipping to change at page 63, line 38
As a further aid to synchronization, either the NAS or the AN MAY 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 from time to time check the peer's view of the amount of delegated
bandwidth using the Delegated Bandwidth Query message. bandwidth using the Delegated Bandwidth Query message.
The NAS or AN MAY at any time release bandwidth to the peer using 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 autonomous Bandwidth Transfer message. The contents of this message
are described in Section 4.6. are described in Section 4.6.
6.3. Combinations of Multicast Capabilities 6.3. Combinations of Multicast Capabilities
6.3.1. Combination of Conditional Access With White and Black Lists and 6.3.1. Combination of Conditional Access and Admission Control With
Conditional Access With Grey Lists White and Black Lists and Conditional Access and Admission
Control With Grey Lists
If conditional access with white and black lists is combined with If conditional access with white and black lists is combined with
conditional access with grey lists, provisioning of the multicast conditional access with grey lists, provisioning of the multicast
service profiles is as described in Section 6.2.3.1 except that service profiles is as described in Section 6.2.3.1 except that
multicast service profiles will also include grey lists. Resource- multicast service profiles will also include grey lists. Admission
based admission control is enabled independently on the AN for white control is enabled independently on the AN for white lists by
lists by including the White-List-CAC TLV in the Provisioning message including the White-List-CAC TLV in the Provisioning message and for
and for grey lists by including the MRepCtl-CAC TLV in the grey lists by including the MRepCtl-CAC TLV in the Provisioning
Provisioning message. The Bandwidth-Allocation TLV provisions an message. The Bandwidth-Allocation TLV provisions an amount that
amount that applies to both white- and grey- listed flows if applies to both white- and grey- listed flows if admission control is
resource-based admission control is enabled for both. enabled for both.
With regard to multicast service procedures, one point of difference With regard to multicast service procedures, one point of difference
from the individual capabilities must be noted. This is an from the individual capabilities must be noted. This is an
interaction during the profile matching procedure. The AN MUST seek interaction during the profile matching procedure. The AN MUST seek
the best match amongst multiple lists as described in the best match amongst multiple lists as described in
Section 6.2.3.2. However, if there are multiple matches of equal Section 6.2.3.2. However, if there are multiple matches of equal
precision, the order of priority is black list first, grey list precision, the order of priority is black list first, grey list
second, and white list last. second, and white list last.
Once profile matching has been completed, processing of a "join" Once profile matching has been completed, processing of a "join"
skipping to change at page 63, line 5 skipping to change at page 65, line 5
The autonomously-generated Multicast Flow Query response message MUST The autonomously-generated Multicast Flow Query response message MUST
be formatted as if it were a successful response to a request be formatted as if it were a successful response to a request
containing no Target and no Multicast-Flow TLV, as described in containing no Target and no Multicast-Flow TLV, as described in
Section 4.9.2, with the exception that the Transaction-Id MUST be set Section 4.9.2, with the exception that the Transaction-Id MUST be set
to all zeroes. to all zeroes.
The procedures in the previous paragraphs imply that the AN has to The procedures in the previous paragraphs imply that the AN has to
retain a memory of whether an admitted flow was white-listed or retain a memory of whether an admitted flow was white-listed or
grey-listed at the time of its admission/readmission. grey-listed at the time of its admission/readmission.
6.3.2. Combination of Conditional Access With Delegated Bandwidth 6.3.2. Combination of Conditional Access and Admission Control With
Delegated Bandwidth
The provisioning and bandwidth management procedures of Section 6.2.5 The provisioning and bandwidth management procedures of Section 6.2.5
apply in addition to the procedures in Section 6.2.3, Section 6.2.4, apply in addition to the procedures in Section 6.2.3, Section 6.2.4,
or Section 6.3.1 as applicable. Admission control follows the rules or Section 6.3.1 as applicable. Conditional access follows the rules
for conditional access in terms of matching flows against white and given in those sections in terms of matching flows against white and
black and/or grey lists and performing or not performing bandwidth black and/or grey lists. When admission control is enabled at the
checks at the AN, but the amount of bandwidth used by the AN to AN, the amount of bandwidth used by the AN is negotiable as described
perform resource-based admission control is negotiable as described
in Section 6.2.5.2. in Section 6.2.5.2.
6.3.3. Combination of NAS-Initiated Replication with Other Capabilities 6.3.3. Combination of NAS-Initiated Replication with Other Capabilities
NAS-initiated replication can coexist with the other capabilities, NAS-initiated replication can coexist with the other capabilities,
but some means must exist to prevent double replication of flows. 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 simplest way to do this is to terminate all IGMP/MLD requests on
the AN, so that NAS-initiated replication is stimulated only by the AN, so that NAS-initiated replication is stimulated only by
signalling through other channels. Other arrangements are possible, signalling through other channels. Other arrangements are possible,
but need not be discussed here. but need not be discussed here.
Assuming the necessary separation of responsibilities, the only point Assuming the necessary separation of responsibilities, the only point
of interaction between NAS-initiated replication and the other of interaction between NAS-initiated replication and the other
multicast capabilities is in the area of resource-based admission multicast capabilities is in the area of admission control.
control. Specifically, if the AN is to do resource-based admission Specifically, if the AN is to do admission control for flows added by
control for flows added by Multicast Replication Control messages, Multicast Replication Control messages, regardless of whether they
regardless of whether they are part of NAS-initiated replication or are part of NAS-initiated replication or grey list multicast service
grey list multicast service processing, the NAS includes the MRepCtl- processing, the NAS includes the MRepCtl-CAC TLV in a Provisioning
CAC TLV in a Provisioning message and the Bandwidth-Allocation TLV in message and the Bandwidth-Allocation TLV in a Port Management
a Port Management message. If instead the NAS will do resource-based message. If instead the NAS will do admission control for flows
admission control for flows added by Multicast Replication Control added by Multicast Replication Control messages, regardless of
messages, regardless of whether they are part of NAS-initiated whether they are part of NAS-initiated replication or grey list
replication or grey list multicast service processing, it does not multicast service processing, it does not send the MRepCtl-CAC TLV in
send the MRepCtl-CAC TLV in a Provisioning messages to the AN. The a Provisioning messages to the AN. The NAS can independently enable
NAS can independently enable resource-based admission control for admission control for white flows on the AN by including the White-
white flows on the AN by including the White-List-CAC TLV in the List-CAC TLV in the Provisioning message.
Provisioning message.
6.3.4. Combinations of Committed Bandwidth Reporting with Other 6.3.4. Combinations of Committed Bandwidth Reporting with Other
Multicast Capabilities Multicast Capabilities
Committed bandwidth reporting can take place independently of which Committed bandwidth reporting can take place independently of which
other multicast capabilities have been negotiated. However, some other multicast capabilities have been negotiated. However, some
combinations do not make sense because of redundancy. In particular, combinations do not make sense because of redundancy. In particular,
the NAS obtains the same information that committed bandwidth the NAS obtains the same information that committed bandwidth
reporting gives if the only other capabilities operating are NAS- reporting gives if the only other capabilities operating are NAS-
initiated replication and/or conditional access with grey lists. initiated replication and/or conditional access and admission control
with grey lists.
7. Security Considerations 7. Miscellaneous Considerations
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.
7.1. Report Buffering Considerations
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.
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. ITU-T
Recommendation G.1080 [ITU-T_G.1080] Appendix IV 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 programme rather than
when it was starting up, but at least gives an (extremely
conservative) order of magnitude for setting the buffering period.
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 programme per subscriber per hour.
Typically, because of programme 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.
Note that simple replacement of one channel with another -- channel
surfing -- does not require reporting or adjustment at the NAS end.
7.2. Congestion Considerations
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 [ITU-T_G.1080] Section 8.1, 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 do become available.
(It is possible that regional bodies or more specialized bodies have
overtaken the ITU-T in this regard.)
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 definition of "stale".
8. Security Considerations
The security considerations of ANCP are discussed in [RFC6320] and in The security considerations of ANCP are discussed in [RFC6320] and in
[RFC5713]. Multicast does not in principle introduce any new [RFC5713]. Multicast does not in principle introduce any new
security considerations, although it does increase the attractiveness security considerations, although it does increase the attractiveness
of the ANCP protocol as a means of denial of service (e.g., through of the ANCP protocol as a means of denial of service (e.g., through
direction of multicast streams onto the target) or theft of service. direction of multicast streams onto the target) or theft of service.
As mentioned in Section 4.4, the inclusion of the Request-Source-MAC As mentioned in Section 4.4, the inclusion of the Request-Source-MAC
or Request-Source-IP TLV in the Multicast Admission Control message or Request-Source-IP TLV in the Multicast Admission Control message
presents privacy issues. An attacker able to to get access to the presents privacy issues. An attacker able to get access to the
contents of this message would, like the content provider, be able to contents of this message would, like the content provider, be able to
track consumption of multicast content to the individual device and track consumption of multicast content to the individual device and
potentially to individual persons if they are associated with potentially to individual persons if they are associated with
particular devices. To make the connection between devices and particular devices. To make the connection between devices and
individuals, the attacker needs to get information from sources other individuals, the attacker needs to get information from sources other
than ANCP, of course, but let us assume that this has happened. than ANCP, of course, but let us assume that this has happened.
The protection specified for ANCP in [RFC6320] will apply to the The protection specified for ANCP in [RFC6320] will apply to the
transmission of the Multicast Admission Control message across the transmission of the Multicast Admission Control message across the
access network to the NAS. Hence the attacker's potential points of access network to the NAS. Hence the attacker's potential points of
skipping to change at page 64, line 42 skipping to change at page 68, line 18
eliminated through operational practice. The segment from the eliminated through operational practice. The segment from the
subscriber through the AN itself seems out of scope of this subscriber through the AN itself seems out of scope of this
discussion -- protection of this segment is basic to subscriber discussion -- protection of this segment is basic to subscriber
privacy in any event, and likely a business requirement. The segment privacy in any event, and likely a business requirement. The segment
from the AN to the NAS is covered by the basic ANCP protection from the AN to the NAS is covered by the basic ANCP protection
specified in RFC 6320. This leaves the NAS and the path between the specified in RFC 6320. This leaves the NAS and the path between the
NAS and AAA for consideration. NAS and AAA for consideration.
The operator can eliminate the path between the NAS and AAA as a The operator can eliminate the path between the NAS and AAA as a
point where the attacker can access per-device information by point where the attacker can access per-device information by
downloading per- device policy to the NAS for all identified user downloading per-device policy to the NAS for all identified user
devices for the particular subscriber. The NAS then selects the devices for the particular subscriber. The NAS then selects the
applicable policy based on the particular device identifier it has applicable policy based on the particular device identifier it has
received. This is as opposed to the NAS sending the identifier of received. This is as opposed to the NAS sending the identifier of
the device in question to AAA and getting policy just for that the device in question to AAA and getting policy just for that
device. device.
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].
This leaves the NAS itself as a point of attack. In theory the NAS 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 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. address to an identifier known to itself and AAA, but not the NAS.
This would require local configuration on the AN, which may be This would require local configuration on the AN, which may be
possible under some circumstances. The Request-Source-Device-Id TLV possible under some circumstances. The Request-Source-Device-Id TLV
specified in Section 5.11 is available to transmit such an identifier specified in Section 5.11 is available to transmit such an identifier
in place of the Request-Source-MAC or Request-Source-IP. in place of the Request-Source-MAC or Request-Source-IP.
8. IANA Considerations 9. IANA Considerations
IANA NOTE: Please replace XXXX with the RFC number of this document. IANA NOTE: Please replace XXXX with the RFC number of this document.
This document defines the following additional values within the ANCP This document defines the following additional values within the ANCP
Message Type Name Space registry: Message Type Name Space registry:
+--------------+--------------------------------+-----------+ +--------------+--------------------------------+-----------+
| Message Type | Message Name | Reference | | Message Type | Message Name | Reference |
+--------------+--------------------------------+-----------+ +--------------+--------------------------------+-----------+
| 144 | Multicast Replication Control | RFC XXXX | | 144 | Multicast Replication Control | RFC XXXX |
skipping to change at page 68, line 24 skipping to change at page 72, line 24
| | | | | | | | | | | |
| 6 | Conditional Access With | 0 | No | RFC XXXX | | 6 | Conditional Access With | 0 | No | RFC XXXX |
| | White and Black Lists | | | | | | White and Black Lists | | | |
| | | | | | | | | | | |
| 7 | Conditional Access With | 0 | No | RFC XXXX | | 7 | Conditional Access With | 0 | No | RFC XXXX |
| | Grey Lists | | | | | | Grey Lists | | | |
| | | | | | | | | | | |
| 8 | Bandwidth Delegation | 0 | No | RFC XXXX | | 8 | Bandwidth Delegation | 0 | No | RFC XXXX |
+-------+-------------------------+--------+------------+-----------+ +-------+-------------------------+--------+------------+-----------+
9. Acknowledgements 10. Acknowledgements
The authors would like to acknowledge Wojciech Dec for providing The authors would like to acknowledge Wojciech Dec for providing
useful input to this document, Robert Rennison for his help in useful input to this document, Robert Rennison for his help in
shaping the definition of the Multicast-Service-Profile TLV, Shridhar shaping the definition of the Multicast-Service-Profile TLV, Shridhar
Rao for his comments and suggestions and Aniruddha A for his proposal Rao for his comments and suggestions and Aniruddha A for his proposal
that formed the base of the Multicast Flow Reporting solution. that formed the base of the Multicast Flow Reporting solution.
Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided
substantial contributions on the solution for the NAS initiated substantial contributions on the solution for the NAS initiated
multicast control use case. Kristian Poscic provided the committed multicast control use case. Kristian Poscic provided the committed
bandwidth reporting use case. bandwidth reporting use case.
Thanks to the Document Shepherd, Matthew Bocci, and Area Director, Thanks to the Document Shepherd, Matthew Bocci, and Area Director,
Ted Lemon, for points raised by their reviews following Working Group Ted Lemon, for points raised by their reviews following Working Group
Last Call. Last Call.
10. References 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 draft, 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 draft.
10.1. Normative References 11. References
[PIMreg] IANA, "http://www.iana.org/assignments/pim-parameters/ 11.1. Normative References
pim-parameters.xhtml", 2005.
[PIMreg] IANA, "http://www.iana.org/assignments/pim-parameters/pim-
parameters.xhtml", 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October Listener Discovery (MLD) for IPv6", RFC 2710, October
1999. 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. [RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T.
Taylor, "Protocol for Access Node Control Mechanism in Taylor, "Protocol for Access Node Control Mechanism in
Broadband Networks", RFC 6320, October 2011. Broadband Networks", RFC 6320, October 2011.
10.2. Informative References 11.2. Informative References
[IEEE48] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ [IEEE48] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/
EUI48.html", 2010. EUI48.html", 2010.
[IEEE64] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ [IEEE64] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html", 2010. EUI64.html", 2010.
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol [ITU-T_G.1080]
Independent Multicast (PIM) Join Attribute Format", RFC ITU-T, "ITU-T Recommendation G.1080: Quality of experience
5384, November 2008. requirements for IPTV services", December 2008.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
Threats and Security Requirements for the Access Node Threats and Security Requirements for the Access Node
Control Protocol (ANCP)", RFC 5713, January 2010. Control Protocol (ANCP)", RFC 5713, January 2010.
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks", Control Mechanism in Broadband Multi-Service Networks",
RFC 5851, May 2010. RFC 5851, May 2010.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, May 2012.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
Appendix A. Example of Messages and Message Flows Appendix A. Example of Messages and Message Flows
This appendix provides an example in which most of the possible This appendix provides an example in which most of the possible
message flows for multicast control are illustrated. This appendix message flows for multicast control are illustrated. This appendix
is for informational purposes only. In case of discrepancy with text is for informational purposes only. In case of discrepancy with text
of the body of this document, the text in the body of the document is of the body of this document, the text in the body of the document is
to be considered as the normative text. to be considered as the normative text.
Assume the following, for a given access port: Assume the following, for a given access port:
skipping to change at page 72, line 36 skipping to change at page 77, line 18
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Example Provisioning Message Figure 21: Example Provisioning Message
Note that the padding after the middle List-Action TLV is counted as Note that the padding after the middle List-Action TLV is counted as
part of length of the Multicast-Service-Profile TLV, but is not part of length of the Multicast-Service-Profile TLV, but is not
included in the length of that List-Action TLV. Note also that the included in the length of that List-Action TLV. Note also that the
Length field in the message header, unlike those in the TLVs, Length field in the message header, unlike those in the TLVs,
includes the message header itself, as required by [RFC6320]. includes the message header itself, as required by [RFC6320].
Finally, note that the Provisioning message does not include a Finally, note that the Provisioning message does not include a
MRepCtl-CAC TLV since in our example resource-based admission control MRepCtl-CAC TLV since in our example admission control for grey
for grey listed flows and for NAS-initiated replication is performed listed flows and for NAS-initiated replication is performed by the
by the NAS. NAS.
As soon as the AN port comes up, the AN sends an ANCP PORT_UP message 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 to the NAS specifying the Access Loop Circuit ID. The NAS replies
with an ANCP Port Management message that, together with the other with an ANCP Port Management message that, together with the other
parameters, includes the multicast service profile name to be parameters, includes the multicast service profile name to be
associated to that port along with the initial amount of delegated associated to that port along with the initial amount of delegated
bandwidth. The corresponding message flow is illustrated in bandwidth. The corresponding message flow is illustrated in
Figure 22. Figure 22.
+----------+ +---------+ +-----+ +-----+ +----------+ +---------+ +-----+ +-----+
skipping to change at page 76, line 12 skipping to change at page 81, line 12
Figure 23: Example Port Management Message Figure 23: Example Port Management Message
A.2. Handling a Grey-Listed Flow A.2. Handling a Grey-Listed Flow
Suppose now that the subscriber chooses to watch the premium channel Suppose now that the subscriber chooses to watch the premium channel
characterized by source 192.0.2.21, group 233.252.0.67. Upon characterized by source 192.0.2.21, group 233.252.0.67. Upon
receiving the Join request, the AN matches it against the multicast receiving the Join request, the AN matches it against the multicast
service profile for the port and determines that it is a grey-listed service profile for the port and determines that it is a grey-listed
flow. Figure 24 illustrates the resulting ANCP message flow for the flow. Figure 24 illustrates the resulting ANCP message flow for the
case of a simple join and leave, when resource-based admission case of a simple join and leave, when admission control for grey-
control for grey-listed flows is not activated on the AN. listed flows is not activated on the AN.
To start the flow, the AN sends a Multicast Admission Control request To start the flow, the AN sends a Multicast Admission Control request
(M1) to the NAS. The NAS decides whether flow can be admitted, (M1) to the NAS. The NAS decides whether flow can be admitted,
applying both policy and bandwidth criteria. It returns its decision applying both policy and bandwidth criteria. It returns its decision
(positive in this example) in a Multicast Replication Control message (positive in this example) in a Multicast Replication Control message
(M2). Later, when the subscriber leaves the flow, the AN informs the (M2). Later, when the subscriber leaves the flow, the AN informs the
NAS by sending another Multicast Admission Control message. NAS by sending another Multicast Admission Control message.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS | |Subscriber| | Home | | AN |<---------->| NAS |
skipping to change at page 92, line 13 skipping to change at page 97, line 13
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 | | Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address: 233.252.0.10 | | Multicast Group Address: 233.252.0.10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.2 | | Unicast Source Address = 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
Figure 37: Multicast Flow Query Response message For Per-Port Figure 37: Multicast Flow Query Response message For Per- Port
Multicast Flow Reporting Multicast Flow Reporting
Authors' Addresses Authors' Addresses
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
 End of changes. 148 change blocks. 
346 lines changed or deleted 503 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/