draft-ietf-ancp-mc-extensions-16.txt   rfc7256.txt 
ANCP F. Le Faucheur Internet Engineering Task Force (IETF) F. Le Faucheur
Internet-Draft Cisco Request for Comments: 7256 R. Maglione
Updates: 6320 (if approved) R. Maglione Updates: 6320 Cisco
Intended status: Standards Track Cisco Systems Category: Standards Track T. Taylor
Expires: August 29, 2014 T. Taylor ISSN: 2070-1721 Huawei
Huawei July 2014
February 25, 2014
Multicast Control Extensions for ANCP Multicast Control Extensions for the Access Node Control Protocol (ANCP)
draft-ietf-ancp-mc-extensions-16.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 (ANCP) (RFC 6320) required for support of the multicast use
the Access Node Control Protocol framework document and one cases defined in the Access Node Control Protocol framework document
additional use case described in this document. These use cases are (RFC 5851) and one additional use case described in this document.
organized into the following ANCP capabilities: These use cases are organized into the following ANCP capabilities:
o NAS-initiated multicast replication; o multicast replication initiated by the Network Access Server
(NAS);
o conditional access and admission control with white and black o conditional access and admission control with white and black
lists; lists;
o conditional access and admission control with grey lists; o conditional access and admission control with grey lists;
o bandwidth delegation; o bandwidth delegation; and
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
point for IANA allocation of result codes determined by IETF point for IANA allocation of result codes determined by IETF
Consensus from 0x100 to 0x64. Consensus from 0x100 to 0x64.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2014. This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7256.
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 ....................................................5
1.1. A Note On Scope . . . . . . . . . . . . . . . . . . . . . 6 1.1. A Note on Scope ............................................7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology .....................................................7
3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 7 3. Multicast Use Cases .............................................7
3.1. NAS Initiated Multicast Replication Control Use Case . . 8 3.1. NAS-Initiated Multicast Replication Control Use Case .......8
3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Goals ...............................................8
3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Message Flow ........................................9
3.2. Conditional Access and Admission Control Use Case . . . . 9 3.2. Conditional Access and Admission Control Use Case ..........9
3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Goals ...............................................9
3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Message Flow .......................................10
3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 11 3.3. Multicast Flow Reporting Use Case .........................11
3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.1. Goals ..............................................11
3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . 12 3.3.2. Message Flow .......................................11
3.4. Committed Bandwidth Reporting Use Case . . . . . . . . . 12 3.4. Committed Bandwidth Reporting Use Case ....................11
3.4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4.1. Goals ..............................................11
3.4.2. Message Flow . . . . . . . . . . . . . . . . . . . . 13 3.4.2. Message Flow .......................................12
4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 4. ANCP Messages ..................................................13
4.1. Provisioning Message . . . . . . . . . . . . . . . . . . 14 4.1. Provisioning Message ......................................13
4.1.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 15 4.1.1. Sender Behavior ....................................14
4.1.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 15 4.1.2. Receiver Behavior ..................................14
4.2. Port Management Message . . . . . . . . . . . . . . . . . 16 4.2. Port Management Message ...................................15
4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 17 4.2.1. Sender Behavior ....................................16
4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 17 4.2.2. Receiver Behavior ..................................16
4.3. Multicast Replication Control Message . . . . . . . . . . 18 4.3. Multicast Replication Control Message .....................17
4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 21 4.3.1. Sender Behavior ....................................21
4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 22 4.3.2. Receiver Behavior ..................................21
4.4. Multicast Admission Control Message . . . . . . . . . . . 24 4.4. Multicast Admission Control Message .......................24
4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 25 4.4.1. Sender Behavior ....................................25
4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 27 4.4.2. Receiver Behavior ..................................26
4.5. Bandwidth Reallocation Request Message . . . . . . . . . 28 4.5. Bandwidth Reallocation Request Message ....................27
4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 28 4.5.1. Sender Behavior ....................................28
4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 29 4.5.2. Receiver Behavior ..................................28
4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . 32 4.6. Bandwidth Transfer Message ................................31
4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 32 4.6.1. Sender Behavior ....................................32
4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 33 4.6.2. Receiver Behavior ..................................32
4.7. Delegated Bandwidth Query Request Message . . . . . . . . 34 4.7. Delegated Bandwidth Query Request Message .................34
4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 34 4.7.1. Sender Behavior ....................................34
4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 34 4.7.2. Receiver Behavior ..................................34
4.8. Delegated Bandwidth Query Response Message . . . . . . . 35 4.8. Delegated Bandwidth Query Response Message ................34
4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 35 4.8.1. Sender Behavior ....................................35
4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 35 4.8.2. Receiver Behavior ..................................35
4.9. Multicast Flow Query Request and Response Messages . . . 36 4.9. Multicast Flow Query Request and Response Messages ........36
4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 36 4.9.1. Sender Behavior ....................................36
4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 37 4.9.2. Receiver Behavior ..................................37
4.10. Committed Bandwidth Report Message . . . . . . . . . . . 38 4.10. Committed Bandwidth Report Message .......................38
4.10.1. Sender Behaviour . . . . . . . . . . . . . . . . . . 39 4.10.1. Sender Behavior ...................................38
4.10.2. Receiver Behaviour . . . . . . . . . . . . . . . . . 39 4.10.2. Receiver Behavior .................................39
5. ANCP TLVs For Multicast . . . . . . . . . . . . . . . . . . . 39 5. ANCP TLVs For Multicast ........................................39
5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 39 5.1. Multicast-Service-Profile TLV .............................39
5.2. Multicast-Service-Profile-Name TLV . . . . . . . . . . . 41 5.2. Multicast-Service-Profile-Name TLV ........................41
5.3. List-Action TLV . . . . . . . . . . . . . . . . . . . . . 41 5.3. List-Action TLV ...........................................41
5.4. Sequence-Number TLV . . . . . . . . . . . . . . . . . . . 44 5.4. Sequence-Number TLV .......................................44
5.5. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . 44 5.5. Bandwidth-Allocation TLV ..................................45
5.6. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . 45 5.6. White-List-CAC TLV ........................................45
5.7. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 45 5.7. MRepCtl-CAC TLV ...........................................46
5.8. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 46 5.8. Bandwidth-Request TLV .....................................46
5.9. Request-Source-IP TLV . . . . . . . . . . . . . . . . . . 47 5.9. Request-Source-IP TLV .....................................47
5.10. Request-Source-MAC TLV . . . . . . . . . . . . . . . . . 47 5.10. Request-Source-MAC TLV ...................................48
5.11. Request-Source-Device-Id TLV . . . . . . . . . . . . . . 48 5.11. Request-Source-Device-Id TLV .............................48
5.12. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . 49 5.12. Multicast-Flow TLV .......................................49
5.13. Report-Buffering-Time TLV . . . . . . . . . . . . . . . . 50 5.13. Report-Buffering-Time TLV ................................50
5.14. Committed-Bandwidth TLV . . . . . . . . . . . . . . . . . 50 5.14. Committed-Bandwidth TLV ..................................51
6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . 51 6. Multicast Capabilities .........................................51
6.1. Required Protocol Support . . . . . . . . . . . . . . . . 52 6.1. Required Protocol Support .................................52
6.1.1. Protocol Requirements For NAS-Initiated Replication . 52 6.1.1. Protocol Requirements for NAS-Initiated
6.1.2. Protocol Requirements For Committed Multicast Multicast Replication ..............................52
Bandwidth Reporting . . . . . . . . . . . . . . . . . 53
6.1.3. Protocol Requirements For Conditional Access and
Admission Control With White and Black Lists . . . . 54
6.1.4. Protocol Requirements For Conditional Access and
Admission Control With Grey Lists . . . . . . . . . . 55
6.1.5. Protocol Requirements For Delegated Bandwidth . . . . 56
6.2. Capability-Specific Procedures for Providing Multicast 6.1.2. Protocol Requirements for Committed
Service . . . . . . . . . . . . . . . . . . . . . . . . . 57 Multicast Bandwidth Reporting ......................54
6.2.1. Procedures For NAS-Initiated Replication . . . . . . 57 6.1.3. Protocol Requirements for Conditional
6.2.2. Procedures For Committed Bandwidth Reporting . . . . 58 Access and Admission Control with White
6.2.3. Procedures For Conditional Access and Admission and Black Lists ....................................55
Control With Black and White Lists . . . . . . . . . 59 6.1.4. Protocol Requirements for Conditional
6.2.4. Procedures For Conditional Access and Admission Access and Admission Control with Grey Lists .......56
Control With Grey Lists . . . . . . . . . . . . . . . 61 6.1.5. Protocol Requirements for Bandwidth Delegation .....57
6.2.5. Procedures For Delegated Bandwidth . . . . . . . . . 62 6.2. Capability-Specific Procedures for Providing
6.3. Combinations of Multicast Capabilities . . . . . . . . . 63 Multicast Service .........................................57
6.3.1. Combination of Conditional Access and Admission 6.2.1. Procedures for NAS-Initiated Multicast
Control With White and Black Lists and Conditional Replication ........................................58
Access and Admission Control With Grey Lists . . . . 63 6.2.2. Procedures for Committed Bandwidth Reporting .......58
6.3.2. Combination of Conditional Access and Admission 6.2.3. Procedures for Conditional Access and
Control With Delegated Bandwidth . . . . . . . . . . 65 Admission Control with Black and White Lists .......59
6.3.3. Combination of NAS-Initiated Replication with Other 6.2.4. Procedures for Conditional Access and
Capabilities . . . . . . . . . . . . . . . . . . . . 65 Admission Control with Grey Lists ..................61
6.3.4. Combinations of Committed Bandwidth Reporting with 6.2.5. Procedures for Bandwidth Delegation ................63
Other Multicast Capabilities . . . . . . . . . . . . 65 6.3. Combinations of Multicast Capabilities ....................64
7. Miscellaneous Considerations . . . . . . . . . . . . . . . . 66 6.3.1. Combination of Conditional Access and
7.1. Report Buffering Considerations . . . . . . . . . . . . . 66 Admission Control with White and Black Lists
7.2. Congestion Considerations . . . . . . . . . . . . . . . . 67 and Conditional Access and Admission Control
8. Security Considerations . . . . . . . . . . . . . . . . . . . 67 with Grey Lists ....................................64
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68 6.3.2. Combination of Conditional Access and
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72 Admission Control with Bandwidth Delegation ........65
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 6.3.3. Combination of NAS-Initiated Replication
11.1. Normative References . . . . . . . . . . . . . . . . . . 73 with Other Capabilities ............................65
11.2. Informative References . . . . . . . . . . . . . . . . . 73 6.3.4. Combinations of Committed Bandwidth
Appendix A. Example of Messages and Message Flows . . . . . . . 74 Reporting with Other Multicast Capabilities ........66
A.1. Provisioning Phase . . . . . . . . . . . . . . . . . . . 75 7. Miscellaneous Considerations ...................................66
A.2. Handling a Grey-Listed Flow . . . . . . . . . . . . . . . 81 7.1. Report Buffering Considerations ...........................66
A.3. Handling White-Listed Flows . . . . . . . . . . . . . . . 86 7.2. Congestion Considerations .................................67
A.4. Handling Of Black-Listed Join Requests . . . . . . . . . 91 8. Security Considerations ........................................67
A.5. Handling Of Requests To Join and Leave the On-Line Game . 91 9. IANA Considerations ............................................69
A.6. Example Flow For Multicast Flow Reporting . . . . . . . . 94 10. Acknowledgements ..............................................72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97 11. References ....................................................73
11.1. Normative References .....................................73
11.2. Informative References ...................................73
Appendix A. Example of Messages and Message Flows ................75
A.1. Provisioning Phase ........................................75
A.2. Handling Grey-Listed Flows ................................81
A.3. Handling White-Listed Flows ...............................87
A.4. Handling of Black-Listed Join Requests ....................92
A.5. Handling of Requests to Join and Leave the On-Line Game ...92
A.6. Example Flow for Multicast Flow Reporting .................95
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 (AN) control mechanism between a Network Access Server (NAS) and an
Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a Access Node (e.g., a Digital Subscriber Line Access Multiplexer
multi-service reference architecture in order to perform QoS-related, (DSLAM)) in a multi-service reference architecture in order to
service-related and subscriber-related operations. [RFC6320] perform QoS-related, service-related, and subscriber-related
specifies a protocol for Access Node Control in broadband networks in operations. [RFC6320] specifies a protocol for Access Node Control
line with this framework. in broadband networks in line with this framework.
[RFC6320] supports three use cases defined in [RFC5851], specifically [RFC6320] supports, specifically for DSL access, three use cases
for DSL access: the DSL Topology Discovery use case, the DSL Line defined in [RFC5851]: the Topology Discovery use case, the Line
Configuration use case and the DSL Remote Connectivity Test use case. Configuration use case, and the 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 ANCP, these use
these use cases are organized into five capabilities: cases are organized into five capabilities:
o NAS-initiated multicast replication; o NAS-initiated multicast replication;
o conditional access and admission control with white and black o conditional access and admission control with white and black
lists; lists;
o conditional access and admission control with grey lists; o conditional access and admission control with grey lists;
o bandwidth delegation; o bandwidth delegation; and
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 signaling). 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 of [RFC5851]. Conditional access is described in Section 3.4.1 of [RFC5851].
Section 3.4.2.2 mentions a way in which conditional access can be Section 3.4.2.2 of [RFC5851] mentions a way in which conditional
combined with admission control to allow best effort multicast flows. access can be combined with admission control to allow best-effort
Section 3.4.2.3 points out the necessary conditions for using both multicast flows, and Section 3.4.2.3 points out the necessary
conditional access and admission control. conditions for using both conditional access and admission control.
In the case of "conditional access and admission control with white In the case of "conditional access and admission control with white
and black lists", multicast join and leave requests are terminated at and black lists", multicast join and leave requests are terminated at
the AN and accepted or ignored in accordance with the direction the AN and accepted or ignored in accordance with the direction
provided by white and black lists respectively. The white and black provided by white and black lists, respectively. The white and black
lists are provisioned per port at startup time and may be modified lists are provisioned per port at startup time and may be modified
thereafter. The NAS may combine conditional access with admission thereafter. The NAS may combine conditional access with admission
control of white-listed flows by appropriate provisioning. control of white-listed flows by appropriate provisioning.
Conditional access and admission control with grey lists is similar Conditional access and admission control with grey lists is similar
to conditional access and admission control with white lists, except to conditional access and admission control with white lists, except
that before accepting any request matching a grey list entry, the AN that before accepting any request matching a grey list entry, the AN
sends a request to the NAS for permission to replicate the flow. sends a request to the NAS for permission to replicate the flow.
Again, the NAS can enable admission control of grey-listed flows at Again, the NAS can enable admission control of grey-listed flows at
the AN. 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.
skipping to change at page 6, line 16 skipping to change at page 6, line 24
the AN. 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 in Section 3.4. The AN
The AN reports the amount of multicast bandwidth it has granted to a reports the amount of multicast bandwidth it has granted to a given
given access line each time that value changes. These reports may be access line each time that value changes. These reports may be
buffered for a NAS-provisionable interval so that reports for buffered for a NAS-provisionable interval so that reports for
multiple access lines can be bundled into the same message. multiple access lines can be bundled into the same message.
The formal specification of the behaviours associated with each of The formal specification of the behaviors associated with each of
these capabilities, singly and in combination, is given in Section 6. these capabilities, singly and in combination, is given in Section 6.
In addition to the multicast service processing behaviour just In addition to the multicast service processing behavior just
sketched, the definition of each capability includes support for the sketched, the definition of each capability includes support for the
multicast accounting and reporting services described in multicast accounting and reporting services described in
Section 3.4.3 of [RFC5851]. Because of this common content and Section 3.4.3 of [RFC5851]. Because of this common content and
because of other protocol overlaps between the different because of other protocol overlaps between the different
capabilities, the protocol descriptions for the multicast extensions capabilities, the protocol descriptions for the multicast extensions
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 1.1. A Note on Scope
The requirements in [RFC5851] were formulated with the IPTV The requirements in [RFC5851] were formulated with the IPTV
application in mind. Two basic assumptions underlie the use case application in mind. Two basic assumptions underlie the use case
descriptions: descriptions:
o that the Home Gateway operates in bridged mode, and o that the Home Gateway operates in bridged mode, and
o that multicast signalling uses IGMP ([RFC2236] or [RFC3376]) or o that multicast signaling uses IGMP ([RFC2236] [RFC3376]) or
MLD [RFC3810] rather than PIM [RFC4601]. Multicast Listener Discovery (MLD) [RFC3810] rather than PIM
[RFC4601].
Without the first assumption the AN may lose sight of individual Without the first assumption the AN may lose sight of individual
subscriber devices making requests for multicast service. This has a subscriber devices making requests for multicast service. This has a
very minor effect on the capabilities described below, but prevents very minor effect on the capabilities described below but prevents
the application of per-device policies at the NAS. Changing the the application of per-device policies at the NAS. Changing the
second assumption would require that, in applications where the AN is second assumption would require that, in applications where the AN is
responsible for snooping IGMP and MLD, it now also monitor for PIM responsible for snooping IGMP and MLD, it now also monitors for PIM
signalling. The capabilities described in the present document do signaling. The capabilities described in the present document do not
not depend explicitly on what type of multicast signalling is used, depend explicitly on what type of multicast signaling is used, but
but the multiple phases of PIM setup could add complexity to their the multiple phases of PIM setup could add complexity to their
implementation. 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].
This document reuses the terms "connection admission control" ("CAC" This document uses the terms "connection admission control" ("CAC" or
or simply "admission control") and "conditional access" as they are simply "admission control") and "conditional access" as they are used
used in [RFC5851]. in [RFC5851].
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 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 prevents
several copies of the same stream are sent within the access/ several copies of the same stream from being sent within the
aggregation network. In case of an Ethernet-based access/aggregation access/aggregation network. In case of an Ethernet-based access/
network, this may, for example, be achieved by means of IGMP snooping aggregation network, this may, for example, be achieved by means
or IGMP proxy in the Access Node and aggregation node(s). By of IGMP snooping or IGMP proxy in the Access Node and aggregation
introducing IGMP processing in the access/aggregation nodes, the node(s).
multicast replication process is now divided between the NAS, the
aggregation node(s) and Access Nodes. In order to ensure backward By introducing IGMP processing in the access/aggregation nodes,
compatibility with the ATM-based model, the NAS, aggregation node and the multicast replication process is now divided between the NAS,
Access Node need to behave as a single logical device. This logical the aggregation node(s), and Access Nodes. In order to ensure
device must have exactly the same functionality as the NAS in the ATM backward compatibility with the ATM-based model, the NAS,
access/aggregation network. The Access Node Control Mechanism can be aggregation node, and Access Node need to behave as a single
used to make sure that this logical/functional equivalence is logical device. This logical device must have exactly the same
achieved by exchanging the necessary information between the Access functionality as the NAS in the ATM access/aggregation network.
Node and the NAS." The Access Node Control Mechanism can be used to make sure that
this logical/functional equivalence is achieved by exchanging the
necessary information between the Access Node and the NAS.
[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.
requirements. The present section describes a subset of these use This section describes a subset of these use cases as background to
cases as background to facilitate reading of this document, but the facilitate reading of this document, but the reader is referred to
reader is referred to [RFC5851] for a more exhaustive description of [RFC5851] for a more exhaustive description of the ANCP multicast use
the ANCP multicast use cases. Detailed example message flows can cases. Detailed example message flows can also be found in
also be found in Appendix A. Appendix A.
In the diagrams below, participation of the Home Gateway is optional, In the diagrams below, participation of the Home Gateway is optional,
depending on whether it is operating in bridged or routed mode. Note depending on whether it is operating in bridged or routed mode. Note
that devices behind the Home Gateway may require the Home Gateway to 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- operate in routed mode to ensure that they can obtain access to non-
IPTV multicast services. 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,
done for instance by terminating all subscriber IGMP ([RFC3376]) or for instance, by terminating all subscriber IGMP ([RFC3376]) or MLD
MLD ([RFC2710], [RFC3810]) signaling on the NAS. Another example ([RFC2710] [RFC3810]) signaling on the NAS. Another example could be
could be a subscriber using some form of application level signaling, a subscriber using some form of application-level signaling, which is
which is redirected to the NAS. In any case, this option is redirected to the NAS. In any case, this option is transparent to
transparent to the access and aggregation network. In this scenario, the access and aggregation network. In this scenario, the NAS uses
the NAS uses ANCP to create and remove replication state in the AN ANCP to create and remove replication state in the AN for efficient
for efficient multicast replication. Thus, the NAS only sends a multicast replication. Thus, the NAS only sends a single copy of the
single copy of the multicast stream towards the AN, which in turn multicast stream towards the AN, which, in turn, performs replication
performs replication to multiple subscribers as instructed by the NAS to multiple subscribers as instructed by the NAS via ANCP. The NAS
via ANCP. The NAS performs conditional access and admission control performs conditional access and admission control when processing
when processing multicast join requests, and only creates replication multicast join requests and only creates replication state in the AN
state in the AN if admission succeeds. if admission succeeds.
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 |
| | |-------------------------->| | | |-------------------------->|
| | | | | | | |
| | | | | | | |
skipping to change at page 9, line 34 skipping to change at page 9, line 41
| | | (Target,delete, Flow 1) | | | | (Target,delete, Flow 1) |
| | |<--------------------------| | | |<--------------------------|
| | | | | | | |
| <Stop Replication of X | | <Stop Replication of X |
| Mcast Flow 1> | Generic Response | | Mcast Flow 1> | Generic Response |
| | |-------------------------->| | | |-------------------------->|
(*) 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 1: NAS Initiated Multicast Replication Control Figure 1: NAS-Initiated Multicast Replication Control
3.2. Conditional Access and Admission Control Use Case 3.2. Conditional Access and Admission Control Use Case
3.2.1. Goals 3.2.1. Goals
One option for multicast handling is for the access/aggregation nodes One option for multicast handling is for the access/aggregation nodes
to participate in IGMP/MLD processing (e.g. via IGMP/MLD snooping). to participate in IGMP/MLD processing (e.g., via IGMP/MLD snooping).
In this scenario, on detecting a join/leave request from an end user In this scenario, on detecting a join/leave request from an end user
for a multicast flow (in the grey list), the AN uses ANCP to request for a multicast flow (in the grey list), the AN uses ANCP to request
a conditional access and admission control decision from the NAS. In a conditional access and admission control decision from the NAS. In
turn, after conditional access and admission control checks, the NAS turn, after conditional access and admission control checks, the NAS
uses ANCP to instruct the AN to change the replication states uses ANCP to instruct the AN to change the replication states
accordingly. accordingly.
3.2.2. Message Flow 3.2.2. Message Flow
For support of the conditional access and admission control use case, For support of the conditional access and admission control use case,
on detection of an IGMP/MLD Join, the AN sends an Admission Control on detection of an IGMP/MLD join request, the AN sends a Multicast
message to the NAS to request a conditional access and admission Admission Control message to the NAS to request a conditional access
control check. In the case of a positive outcome, the NAS sends a and admission control check. In the case of a positive outcome, the
Multicast Replication Control Message to the AN with a directive to NAS sends a Multicast Replication Control message to the AN with a
replicate the multicast flow to the corresponding user. Similarly on directive to replicate the multicast flow to the corresponding user.
detection of an IGMP/MLD leave, an Admission Control message is sent Similarly, on detection of an IGMP/MLD leave, a Multicast Admission
by the AN to the NAS to keep the NAS aware of user departure for the Control message is sent by the AN to the NAS to keep the NAS aware of
flow. This message flow is illustrated in Figure 2. user departure for the flow. This message flow is illustrated in
Figure 2.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<------------------->| NAS | |Subscriber| | Home | | AN |<------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | | | | | |
| Join(Gr-Flow1) | Multicast-Admission-Crl |
| 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) | Multicast-Admission-Crl |
|------------+---------->| (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 12, line 4 skipping to change at page 11, line 6
| | | | | | | |
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
3.3. Multicast Flow Reporting Use Case 3.3. Multicast Flow Reporting Use Case
3.3.1. Goals 3.3.1. Goals
The Multicast flow reporting use case allows the NAS to The multicast flow reporting use case allows the NAS to
asynchronously query the AN to obtain an instantaneous status report asynchronously query the AN to obtain an instantaneous status report
related to multicast flows currently replicated by the AN. related to multicast flows currently replicated by the AN.
3.3.2. Message Flow 3.3.2. Message Flow
The NAS sends a Multicast Flow Query Request message to the AN in The NAS sends a Multicast Flow Query Request message to the AN in
order to query the AN about information such as which multicast flows order to query the AN about information such as which multicast flows
are currently active on a given AN port or which ports are currently are currently active on a given AN port or which ports are currently
replicating a given multicast flow. The AN conveys the requested replicating a given multicast flow. The AN conveys the requested
information to the NAS in a Multicast Flow Query Response message. information to the NAS in a Multicast Flow Query Response message.
skipping to change at page 13, line 20 skipping to change at page 12, 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 |
| | | | | | | | | | | |
| | | | |Committed | | | | | |Committed |
| | | | | Bandwidth Report | | | | | | Bandwidth Report |
| | | | |------------------>| | | | | |------------------>|
| | | | | (for latest | | | | | | (for latest |
| | | | | Subs1 and Subs2 | | | | | | Subs1 and Subs2 |
| | | | | bandwidth) | | | | | | bandwidth) |
| | | | | | | | | | | |
Figure 4: Message Flow For Committed Bandwidth Reporting Figure 4: Message Flow for Committed Bandwidth Reporting
4. ANCP Messages 4. ANCP Messages
This section defines new ANCP messages and new usage of existing ANCP This section defines new ANCP messages and new usage of existing ANCP
messages as well as procedures associated with the use of these messages as well as procedures associated with the use of these
messages. messages.
Unless stated otherwise, receivers MUST ignore message contents that Unless stated otherwise, receivers MUST ignore message contents that
are not supported by the set of capabilities negotiated between the are not supported by the set of capabilities negotiated between the
NAS and the Access Node. NAS and the Access Node.
skipping to change at page 14, line 44 skipping to change at page 13, line 44
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 admission control before replicating white- AN is required to do admission control before 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 admission control before replicating flows AN is required to do admission control before replicating flows
specified in Multicast Replication Control messages. specified in Multicast Replication Control 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 Behavior
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 admission control for specific classes of flows. perform admission control for specific classes of 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 MUST 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
skipping to change at page 15, line 34 skipping to change at page 14, line 34
To require admission control to be performed at the AN on white- To require admission control to be performed at the AN on white-
listed flows, the NAS MUST include a copy of the White-List-CAC TLV listed flows, the NAS MUST include a copy of the White-List-CAC TLV
in the Provisioning message. The White-List-CAC TLV MUST NOT be in the Provisioning message. The White-List-CAC TLV MUST NOT be
provided unless the negotiated set of capabilities includes provided unless the negotiated set of capabilities includes
conditional access and admission control with white and black lists. conditional access and admission control with white and black lists.
To require admission control to be performed at the AN on grey-listed To require admission control to be performed at the AN on grey-listed
flows or on NAS-initiated flows, the NAS MUST include a copy of the flows or on NAS-initiated flows, the NAS MUST include a copy of the
MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV
MUST NOT be provided unless the negotiated set of capabilities MUST NOT be provided unless the negotiated set of capabilities
includes NAS-initiated replication control or conditional access and includes NAS-initiated multicast replication or conditional access
admission control with grey lists. and 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 Behavior
The receiving AN provisions/updates the white, black, and/or grey The receiving AN provisions/updates the white, black, and/or grey
lists associated with the multicast service profile names contained lists associated with the multicast service profile names contained
in the Multicast-Service-Profile TLV instances within the message in the Multicast-Service-Profile TLV instances within the message
according to the contents of the associated List-Action TLVs. The AN according to the contents of the associated List-Action TLVs. The AN
MUST process List-Action TLVs in the order in which they appear MUST process List-Action TLVs in the order in which they appear
within the message. In keeping with the general rule stated in within the message. In keeping with the general rule stated in
Section 4, the AN MUST ignore instances of the List-Action TLV Section 4, the AN MUST ignore instances of the List-Action TLV
referring to any list type (white, black, or grey) that is not referring to any list type (white, black, or grey) that is not
supported by the set of multicast capabilities negotiated between the supported by the set of multicast capabilities negotiated between the
skipping to change at page 16, line 38 skipping to change at page 15, line 38
The buffering time specified in an instance of the Report-Buffering- The buffering time specified in an instance of the Report-Buffering-
Time TLV will not be applied until the current accumulation process Time TLV will not be applied until the current accumulation process
of Committed Bandwidth Report messages finishes. of Committed Bandwidth Report messages finishes.
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.
4.2. Port Management Message 4.2. Port Management Message
As specified in [RFC6320], the NAS may send DSL line configuration As specified in [RFC6320], the NAS may send DSL line configuration
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 conditional access to the AN for the black lists, delegates conditional access to the AN 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
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
TLV(s) MUST be present. Line configuration data other than the TLV(s) MUST be present. Line configuration data other than the
two TLVs listed in the previous paragraph MAY be present. two TLVs listed in the previous paragraph MAY be present.
4.2.1. Sender Behaviour 4.2.1. Sender Behavior
The NAS sends the Port Management message at startup time to The NAS sends the Port Management message at startup time to
initialize parameters associated with the access line specified in initialize parameters associated with the access line specified in
the message and with the multicast capabilities negotiated between the message and with the multicast capabilities negotiated between
the NAS and the AN. The NAS MAY send additional Port Management the NAS and the AN. The NAS MAY send additional Port Management
messages subsequent to startup, to update or, in the case of the messages subsequent to startup, to update or, in the case of the
Bandwidth-Allocation TLV, reset these parameters. If the NAS Bandwidth-Allocation TLV, reset these parameters. If the NAS
includes a Multicast-Service-Profile-Name TLV in the Port Management includes a Multicast-Service-Profile-Name TLV in the Port Management
message, the name MUST match a profile name provided in a Multicast- message, the name MUST match a profile name provided in a Multicast-
Service-Profile TLV in a prior Provisioning message. The NAS MUST Service-Profile TLV in a prior Provisioning message. The NAS MUST
NOT include a TLV unless it is supported by the set of multicast NOT include a TLV unless it is supported by the set of multicast
capabilities negotiated between the NAS and the AN. See Section 6 capabilities negotiated between the NAS and the AN. See Section 6
for further information. for further information.
4.2.2. Receiver Behaviour 4.2.2. Receiver Behavior
If the Port Management message contains a Multicast-Service-Profile- If the Port Management message contains a Multicast-Service-Profile-
Name TLV, the AN associates the named profile with the specified Name TLV, the AN associates the named profile with the specified
access line. This association replaces any previous association. access line. This association replaces any previous association.
That is, a given access line is associated with at most one multicast That is, a given access line is associated with at most one multicast
service profile. The replacement of one multicast service profile service profile. The replacement of one multicast service profile
with another will cause the AN to review the status of all active with another will cause the AN to review the status of all active
flows on the target port. For further details see Section 6. flows on the target port. For further details see Section 6.
If the Port Management message contains a Bandwidth-Allocation TLV, If the Port Management message contains a Bandwidth-Allocation TLV,
skipping to change at page 19, line 4 skipping to change at page 18, line 7
o Target TLV: The Target TLV is defined in Section 4.3 of [RFC6320]. o Target TLV: The Target TLV is defined in Section 4.3 of [RFC6320].
It MUST appear once and only once. It is encoded as specified in It MUST appear once and only once. It is encoded as specified in
[RFC6320] or extensions and identifies the AN port subject to the [RFC6320] or extensions and identifies the AN port subject to the
request for admission or release. request for admission or release.
o Command TLV: The Command TLV is defined in Section 4.4 of o Command TLV: The Command TLV is defined in Section 4.4 of
[RFC6320]. It MUST be present. It MAY appear multiple times. [RFC6320]. It MUST be present. It MAY appear multiple times.
As [RFC6320] indicates, the contents of the Command Info field within As [RFC6320] indicates, the contents of the Command Info field within
the Command TLV are specific to the message in which the TLV occurs. the Command TLV are specific to the message in which the TLV occurs.
For the Multicast Replication Control message, these contents consist
For the Multicast Replication Control Message, these contents consist
of: of:
o a Command Code field; o a Command Code field;
o an Accounting field; o an Accounting field; and
o an instance of the Multicast-Flow TLV. o an instance of the Multicast-Flow TLV.
Figure 5 illustrates the complete Command TLV with the contents Figure 5 illustrates the complete Command TLV with the contents
specific to the Multicast Replication Control message. specific to the Multicast Replication Control message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | Command TLV Length | | TLV Type = Command 0x0011 | Command TLV Length |
skipping to change at page 19, line 37 skipping to change at page 19, line 5
| Other embedded TLV Type | Other embedded TLV Length | | Other embedded TLV Type | Other embedded TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Other embedded TLV data ~ ~ Other embedded TLV data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Contents of the Command TLV in the Multicast Replication Figure 5: Contents of the Command TLV in the Multicast Replication
Control Message Control Message
Command Code: o Command Code: One of the following command directives:
Command directive:
1 "Add"; 1 "Add"
2 "Delete"; 2 "Delete"
3 "Delete All"; 3 "Delete All"
4 "Admission Control Reject"; 4 "Admission Control Reject"
5 "Conditional Access Reject"; 5 "Conditional Access Reject"
6 "Admission Control and Conditional Access Reject". 6 "Admission Control and Conditional Access Reject"
Directives 4 through 6 are used as described in Directives 4 through 6 are used as described in Section 4.4.2.
Section 4.4.2.
Accounting: o Accounting: Meaningful only when the Command Code is "Add" (1).
Meaningful only when the Command Code is "Add" (1). In In that case, 0 indicates flow accounting is disabled, and 1
that case, 0 indicates flow accounting is disabled, 1 indicates that octet accounting for the flow is requested. The
indicates that octet accounting for the flow is requested. sender MUST set the Accounting field to 0, and the receiver MUST
The sender MUST set the Accounting field to 0 and the ignore the Accounting field for other Command Code values.
receiver MUST ignore the Accounting field for other Command
Code values.
Reserved: o Reserved: Reserved for future use. MUST be set to zeroes by the
Reserved for future use. MUST be set to zeroes by the sender and ignored by the receiver.
sender and ignored by the receiver.
Multicast-Flow TLV: o Multicast-Flow TLV: An instance of the Multicast-Flow TLV
An instance of the Multicast-Flow TLV (Section 5.12) (Section 5.12) specifying the flow to be added or deleted. The
specifying the flow to be added or deleted. The Multicast- Multicast-Flow TLV is omitted if the Command Code has value
Flow TLV is omitted if the Command Code has value "Delete "Delete All" (3).
All" (3).
Other embedded TLV: o Other embedded TLV data: No other embedded TLVs are currently
No other embedded TLVs are currently specified within the specified within the Multicast Replication Control message and
Multicast Replication Control message/Command TLV. Command TLV. However, see the description of the Multicast
However, see the description of the Multicast Admission Admission Control message (Section 4.4). Unrecognized embedded
Control message (Section 4.4). Unrecognized embedded TLVs TLVs SHOULD be silently discarded.
SHOULD be silently discarded.
The figure below is an example of a Multicast Replication Control The figure below is an example of a Multicast Replication Control
message that would result in a swap from multicast Source-Specific message that would result in a swap from multicast Source-Specific
Multicast (SSM) flows 2001:DB8::1, FF34::2, to 2001:DB8::2, FF34::3 Multicast (SSM) flows 2001:DB8::1, FF34::2 to 2001:DB8::2, FF34::3 on
on the Target identified by the "Access Loop Circuit ID": the target identified by the Access Loop Circuit ID:
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 (0x880C) | Length | | Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MsgType=144 | Res=2 | Result Code = 0 | | Version | MsgType=144 | Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 18 | | Partition ID | Transaction Identifier = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 41 skipping to change at page 21, line 10
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Multicast Group Address ~ ~ Multicast Group Address ~
| = FF34::3 | | = FF34::3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Source Address ~ ~ Source Address ~
| = 2001:DB8::2 | | = 2001:DB8::2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.1. Sender Behaviour Figure 6: Example Change of Source Flow Using Multicast Replication
Control Message
4.3.1. Sender Behavior
The NAS MAY issue a Multicast Replication Control message to the AN The NAS MAY issue a Multicast Replication Control message to the AN
to convey one or more directives to add (join) or delete (leave) one to convey one or more directives to add (join) or delete (leave) one
or more multicast flows. or more multicast flows.
The NAS MAY send this message on its own initiative to support the The NAS MAY send this message on its own initiative to support the
NAS initiated Multicast Control use case presented in [RFC5851] and NAS-initiated multicast control use case presented in [RFC5851] and
summarized in Section 3.1. In that case, the NAS MUST set the Result summarized in Section 3.1. In that case, the NAS MUST set the Result
field to AckAll (0x2) or Nack (0x1) according to its requirements. field to AckAll (0x2) or Nack (0x1) according to its requirements.
The NAS MAY also send this message in response to a Multicast The NAS MAY also send this message in response to a Multicast
Admission Control message (defined in Section 4.4) received from the Admission Control message (defined in Section 4.4) received from the
AN to support the conditional access and admission control use case AN to support the conditional access and admission control use case
presented in [RFC5851] and summarized in Section 3.2. In that case, presented in [RFC5851] and summarized in Section 3.2. In that case,
the NAS MUST set the Result field to NAck (0x1). the NAS MUST set the Result field to Nack (0x1).
In either case, the sender MUST populate the Result Code field with In either case, the sender MUST populate the Result Code field with
the value 0 and the ANCP Transaction Identifier field with a unique the value 0 and the ANCP Transaction Identifier field with a unique
value, as described in Section 3.6.1.6 of [RFC6320]. value, as described in Section 3.6.1.6 of [RFC6320].
Each Multicast Replication Control Message MUST contain one or more Each Multicast Replication Control message MUST contain one or more
commands, each encapsulated in its own Command TLV. The sender MUST commands, each encapsulated in its own Command TLV. The sender MUST
use a separate Command TLV for each distinct multicast flow. use a separate Command TLV for each distinct multicast flow.
When the order of processing of two commands does not matter, the When the order of processing of two commands does not matter, the
commands MUST be transmitted in separate Multicast Replication commands MUST be transmitted in separate Multicast Replication
Control messages. Control messages.
4.3.2. Receiver Behaviour 4.3.2. Receiver Behavior
When successive commands (in the same or different messages) relate When successive commands (in the same or different messages) relate
to the same Target and multicast flow, the state of each feature to the same target and multicast flow, the state of each feature
controlled or affected by attributes received in the Multicast controlled or affected by attributes received in the Multicast
Replication Control message, SHALL be as set by the last command or Replication Control message SHALL be as set by the last command or
message referring to that target and flow and containing the message referring to that target and flow and containing the
controlling attribute. As an example, successive Multicast controlling attribute. As an example, successive Multicast
Replication Control messages containing add commands for a given port Replication Control messages containing add commands for a given port
and flow but differing only in the Accounting field, update the state and flow but differing only in the Accounting field update the state
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.
skipping to change at page 23, line 16 skipping to change at page 22, line 36
Transaction Identifier field is copied from the Multicast Replication Transaction Identifier field is copied from the Multicast Replication
Control message. The body of the response MAY be empty or MAY be Control message. The body of the response MAY be empty or MAY be
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 Replication Control message MUST be interrupted at the
encountered, and the remaining commands in the Multicast Replication first error encountered and the remaining commands in the Multicast
Control message discarded. Similarly, if a given command specifies Replication Control message discarded. Similarly, if a given command
multiple Single-Source Multicast (SSM) flows and a error occurs, specifies multiple Single-Source Multicast (SSM) flows and an error
processing MUST be interrupted at that point and the remainder of the occurs, processing MUST be interrupted at that point, and the
Command TLV discarded. 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 24, line 30 skipping to change at page 24, line 7
Required additional information in the message: see below. Required additional information in the message: see below.
Target: control application at the NAS. Target: control application at the NAS.
Action RECOMMENDED for the receiving ANCP agent: report the Action RECOMMENDED for the receiving ANCP agent: report the
error to the control application with an indication of the error to the control application with an indication of the
erroneous information associated with the invalid TLV(s). erroneous information associated with the invalid TLV(s).
A Generic Response message responding to the Multicast Replication A Generic Response message responding to the Multicast Replication
Control message and containing one of the above Result Code values Control message and containing one of the above Result Code values
MUST include a Status-Info TLV which includes one or two embedded MUST include a Status-Info TLV, which includes one or two embedded
TLVs as follows: TLVs as follows:
o a Sequence-Number TLV as described in Section 5.4, giving the o a Sequence-Number TLV as described in Section 5.4, giving the
sequence number of the failed command, MUST be included; sequence number of the failed command, MUST be included; and
o the failed Command TLV itself SHOULD be included. o the failed Command TLV itself SHOULD be included.
Note that the Error Message field of the Status-Info TLV MAY be Note: The Error Message field of the Status-Info TLV MAY be used
used to report more details than implied by the Result Code value to report more details than implied by the Result Code value in
in the message header. For example, the Result Code value could the message header. For example, the Result Code value could be
be 0x65 and the Error Message field could contain the text: 0x65, and the Error Message field could contain the text: "Source
"Source address present for ASM flow". address present for ASM flow".
4.4. Multicast Admission Control Message 4.4. Multicast Admission Control Message
This section defines a new message called the Multicast Admission This section defines a new message called the Multicast Admission
Control message. The Multicast Admission Control message is sent by Control message. The Multicast Admission Control message is sent by
the AN to the NAS to request admission of a multicast flow, or to the AN to the NAS to request admission of a multicast flow, or to
notify of the removal of a multicast flow, for a given target. notify of the removal of a multicast flow, for a given target.
The Message Type for the Multicast Admission Control message is 145. The Message Type for the Multicast Admission Control message is 145.
skipping to change at page 25, line 16 skipping to change at page 24, line 41
TLVs: TLVs:
o Target TLV: The Target TLV is defined in [RFC6320]. It MUST o Target TLV: The Target TLV is defined in [RFC6320]. It MUST
appear once and only once in the Multicast Admission Control appear once and only once in the Multicast Admission Control
message. It is encoded as specified in [RFC6320] or extensions message. It is encoded as specified in [RFC6320] or extensions
and identifies the AN port subject to the request for admission or and identifies the AN port subject to the request for admission or
release. release.
o Command TLV: The Command TLV is defined in [RFC6320]. It MUST be o Command TLV: The Command TLV is defined in [RFC6320]. It MUST be
present. If it appears more than once, only the first instance is present. If it appears more than once, only the first instance is
considered meaningful in the present version of this specification considered meaningful in the present version of this
and the other instances are ignored. specification, and the other instances are ignored.
Note:
In the future, the specification of the Admission Control message Note: In the future, the specification of the Multicast Admission
may be extended to allow transport of more than a single directive Control message may be extended to allow transport of more than a
(e.g., to carry both a leave from one group and a join to another single directive (e.g., to carry both a leave from one group and a
group for the same Target). It is expected that this would join to another group for the same target). It is expected that
support a similar notion of strict sequenced processing as this would support a similar notion of strict sequenced processing
currently defined for handling multiple directives in the as 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 cannot 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.
o similarly, a Request-Source-MAC TLV MAY be appended to the Command o Similarly, a Request-Source-MAC TLV MAY be appended to the Command
TLV as an additional embedded TLV. TLV as an additional embedded TLV.
o Finally and preferably, a Request-Source-Device-Id TLV MAY be o Finally and preferably, a Request-Source-Device-Id TLV MAY be
appended to the Command TLV as an additional embedded TLV. appended to the Command TLV as an additional embedded TLV.
Note that the Command TLV length includes the length of any embedded Note that the Command TLV length includes the length of any embedded
TLVs, including the embedded TLV headers. TLVs, including the embedded TLV headers.
4.4.1. Sender Behaviour 4.4.1. Sender Behavior
The AN sending the Multicast Admission Control message MUST set the The AN sending the Multicast Admission Control message MUST set the
Result field to Ignore (0x0). Result field to Ignore (0x0).
The AN MUST populate the ANCP Transaction Identifier field with a The AN MUST populate the ANCP Transaction Identifier field with a
unique value, as described in Section 3.6.1.6 of [RFC6320]. unique value, as described in Section 3.6.1.6 of [RFC6320].
The AN MUST encode the Command TLV as specified in Section 4.3 with The AN MUST encode the Command TLV as specified in Section 4.3 with
the following additional rules: the following additional rules:
o the Accounting field MUST be set to 0; o The Accounting field MUST be set to 0.
o the Command Code field MUST be set to "Add" (1) when the message o The Command Code field MUST be set to "Add" (1) when the message
conveys a Join , to "Delete" (2) when the message conveys a Leave conveys a join request, to "Delete" (2) when the message conveys a
and to "Delete All" (3) when the message conveys a Leave of all leave, and to "Delete All" (3) when the message conveys a leave of
channels (on the target); all channels (on the target).
o The Multicast-Flow TLV within the Command TLV identifies the o The Multicast-Flow TLV within the Command TLV identifies the
multicast flow subject to the request for admission or release. multicast flow subject to the request for admission or release.
When the Command Code is 3, the Multicast-Flow TLV is omitted. When the Command Code is 3, the Multicast-Flow TLV is omitted.
o The Request-Source-IP embedded TLV MAY be included by the AN to o The Request-Source-IP embedded TLV MAY be included by the AN to
convey the IP address of the sender of the join/leave message convey the IP address of the sender of the join/leave message
(e.g., IGMP/MLD Join/Leave) that triggered the AN to include the (e.g., IGMP/MLD join/leave) that triggered the AN to include the
corresponding Command TLV in the Admission Control message. If it corresponding Command TLV in the Multicast Admission Control
appears more than once, only the first instance is considered message. If it appears more than once, only the first instance is
meaningful and the other instances are ignored. considered meaningful, and the other instances are ignored.
o The Request-Source-MAC embedded TLV MAY be included by the AN to o The Request-Source-MAC embedded TLV MAY be included by the AN to
convey the MAC address of the sender of the join/leave message convey the Media Access Control (MAC) address of the sender of the
(e.g., IGMP/MLD Join/Leave) that triggered the AN to include the join/leave message (e.g., IGMP/MLD join/leave) that triggered the
corresponding Command TLV in the Admission Control message. If it AN to include the corresponding Command TLV in the Multicast
appears more than once, only the first instance is considered Admission Control message. If it appears more than once, only the
meaningful and the other instances are ignored. first instance is considered meaningful, and the other instances
are ignored.
o As a third alternative, the Request-Source-Device-Id embedded TLV o As a third alternative, the Request-Source-Device-Id embedded TLV
MAY be included by the AN to convey a local identifier of the MAY be included by the AN to convey a local identifier of the
sender of the join/leave message (e.g., IGMP/MLD Join/Leave) that sender of the join/leave message (e.g., IGMP/MLD join/leave) that
triggered the AN to include the corresponding Command TLV in the triggered the AN to include the corresponding Command TLV in the
Admission Control message. If it appears more than once, only the Multicast Admission Control message. If it appears more than
first instance is considered meaningful and the other instances once, only the first instance is considered meaningful, and the
are ignored. other instances 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 8. The local Authentication, Authorization, and Accounting (AAA) but not to the
identifier is transmitted using the Request-Source-Device-Id TLV. NAS, as discussed in Section 8. The local identifier is transmitted
using the Request-Source-Device-Id TLV.
4.4.2. Receiver Behaviour 4.4.2. Receiver Behavior
On receipt of an Multicast Admission Control message, the NAS: On receipt of a Multicast Admission Control message:
o MUST ignore the Result field; o The NAS 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
NAS, the NAS MUST NOT generate any ANCP message in response to the NAS, the NAS MUST NOT generate any ANCP message in response to the
Multicast Admission Control message; Multicast Admission Control message.
o if the directive in the Multicast Admission Control message is o If the directive in the Multicast Admission Control message is
"Add" (1) and is accepted by the NAS, the NAS MUST generate a "Add" (1) and is accepted by the NAS, the NAS MUST generate a
Multicast Replication Control in response to the Multicast Multicast Replication Control message in response to the Multicast
Admission Control message. The Multicast Replication Control Admission Control message. The Multicast Replication Control
message: message:
* 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]; and
* 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) and 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
in Section 3.6.1.6 of [RFC6320]; in Section 3.6.1.6 of [RFC6320]; and
* MUST contain the directive rejected by the NAS (i.e., Target * MUST contain the directive rejected by the NAS (i.e., Target
TLV and Command TLV) but with a Command Code set to "Admission TLV and Command TLV) but with a Command Code set to "Admission
Control Reject" (4), "Conditional Access Reject" (5), or Control Reject" (4), "Conditional Access Reject" (5), or
"Admission Control and Conditional Access Reject" (6) as "Admission Control and Conditional Access Reject" (6) as
applicable. applicable.
o if the Multicast Admission Control message cannot be processed o If the Multicast Admission Control message cannot be processed
correctly by the NAS (e.g. the message is malformed, the multicast correctly by the NAS (e.g., the message is malformed, the
flow does not exist etc.), the NAS MUST generate a Generic multicast flow does not exist, etc.), the NAS MUST generate a
Response message (defined in Section 4.2 of [RFC6320]) with Generic Response message (defined in Section 4.2 of [RFC6320])
appropriate content indicating the reason for the failure. with appropriate content indicating the reason for the failure.
4.5. Bandwidth Reallocation Request Message 4.5. Bandwidth Reallocation Request Message
The Bandwidth Reallocation Request message is used when the bandwidth The Bandwidth Reallocation Request message is used when the bandwidth
delegation capability is included in the negotiated set. It MAY be delegation capability is included in the negotiated set. It MAY be
sent either by the NAS or by the AN to request an adjustment in the sent either by the NAS or by the AN to request an adjustment in the
amount of delegated bandwidth. It will be sent by the NAS typically amount of delegated bandwidth. It will be sent by the NAS typically
to reduce the multicast bandwidth allocated to the AN in order for to reduce the multicast bandwidth allocated to the AN in order for
the NAS to satisfy a request to add one or more flows. Conversely, the NAS to satisfy a request to add one or more flows. Conversely,
the AN will send a Bandwidth Reallocation Request to obtain the AN will send a Bandwidth Reallocation Request message to obtain
additional bandwidth to satisfy a request to add a multicast channel. additional bandwidth to satisfy a request to add a multicast channel.
In each case, the requestor has a minimum requirement for additional In each case, the requestor has a minimum requirement for additional
bandwidth, and MAY ask for additional bandwidth beyond this amount bandwidth and MAY ask for additional bandwidth beyond this amount
(e.g., to handle anticipated future requests). (e.g., to handle anticipated future requests).
The Bandwidth Reallocation Request message contains two TLVs: The Bandwidth Reallocation Request message contains two TLVs:
o the Target TLV (Section 4.3 of [RFC6320] or an extension), o the Target TLV (Section 4.3 of [RFC6320] or an extension),
specifying a single access line; specifying a single access line; and
o the Bandwidth-Request TLV (Section 5.8), specifying the required o the Bandwidth-Request TLV (Section 5.8), specifying the required
and preferred amounts of delegated bandwidth. and preferred amounts of delegated bandwidth.
The Message Type for the Bandwidth Reallocation Request message is The Message Type for the Bandwidth Reallocation Request message is
146. 146.
4.5.1. Sender Behaviour 4.5.1. Sender Behavior
The Result field in the header of the Bandwidth Reallocation Request The Result field in the header of the Bandwidth Reallocation Request
message is not used and the sender MUST set it to Ignore (0x0). message is not used, and the sender MUST set it to Ignore (0x0).
The bandwidth values in the Bandwidth-Request TLV are expressed in The bandwidth values in the Bandwidth-Request TLV are expressed in
terms of total multicast bandwidth allocated to the AN. terms of total multicast bandwidth allocated to the AN.
The choice of "total bandwidth" rather than "incremental Note: The choice of "total bandwidth" rather than "incremental
bandwidth" was made so that it would be easier for the AN and NAS bandwidth" was made so that it would be easier for the AN and NAS
to keep their respective views of the current amount of delegated to keep their respective views of the current amount of delegated
bandwidth synchronized. bandwidth synchronized.
Because the values are totals rather than desired increments/ Because the values are totals rather than desired increments/
decrements, the relationship between the required amount and the decrements, the relationship between the required amount and the
preferred amount will differ depending on whether the Bandwidth preferred amount will differ depending on whether the Bandwidth
Reallocation Request message is issued by the NAS or the AN. Reallocation Request message is issued by the NAS or the AN.
o If the NAS is making the request, the preferred amount MUST be o If the NAS is making the request, the preferred amount MUST be
less than or equal to the required amount. The required amount less than or equal to the required amount. The required amount
MUST be less than the current amount of delegated bandwidth. MUST be less than the current amount of delegated bandwidth.
o If the AN is making the request, the preferred amount MUST be o If the AN is making the request, the preferred amount MUST be
greater than or equal to the required amount. The required amount greater than or equal to the required amount. The required amount
MUST be greater than the current amount of delegated bandwidth. MUST be greater than the current amount of delegated bandwidth.
4.5.2. Receiver Behaviour 4.5.2. Receiver Behavior
When the peer receives a valid Bandwidth Reallocation Request When the peer receives a valid Bandwidth Reallocation Request
message, it SHOULD determine whether it can satisfy the request from message, it SHOULD determine whether it can satisfy the request from
its existing allocation of unused video bandwidth. If it decides its existing allocation of unused video bandwidth. If it decides
that it can reallocate bandwidth to the peer, it MAY choose to return that it can reallocate bandwidth to the peer, it MAY choose to return
any amount between the required and the preferred amounts indicated any amount between the required and the preferred amounts indicated
in the Bandwidth Reallocation Request message. in the Bandwidth Reallocation Request message.
The peer MUST return a Bandwidth Transfer message (Section 4.6) The peer MUST return a Bandwidth Transfer message (Section 4.6)
indicating its decision. If the request is met, the Result field of indicating its decision. If the request is met, the Result field of
the Bandwidth Transfer message MUST be set to Success (0x3), the the Bandwidth Transfer message MUST be set to Success (0x3), the
Result Code field MUST be set to 0x000, and the Bandwidth-Allocation Result Code field MUST be set to 0x000, and the Bandwidth-Allocation
TLV (Section 5.5) MUST contain the new value of total multicast TLV (Section 5.5) MUST contain the new value of total multicast
bandwidth. This new value MUST lie between the required and bandwidth. This new value MUST lie between the required and
preferred values, inclusive, from the request message. If the preferred values, inclusive, from the request message. If the
request is not met, the Result field of the Bandwidth Transfer request is not met, the Result field of the Bandwidth Transfer
message MUST be set to Failure (0x4), the Result Code field MUST be message MUST be set to Failure (0x4), the Result Code field MUST be
set to 0, and the Bandwidth Allocation TLV MUST contain the value of set to 0, and the Bandwidth-Allocation TLV MUST contain the value of
the currently allocated amount of delegated bandwidth as the the currently allocated amount of delegated bandwidth as the
responder views it. responder views it.
The following cases indicate that the sender holds a different view The following cases indicate that the sender holds a different view
of the amount of delegated bandwidth from the receiver: of the amount of delegated bandwidth from the receiver:
o the NAS receives a request where the required amount is less than o The NAS receives a request where the required amount is less than
its view of the current amount of delegated bandwidth; its view of the current amount of delegated bandwidth.
o the AN receives a request where the required amount is greater o The AN receives a request where the required amount is greater
than its view of the current amount of delegated bandwidth. than its view of the current amount of delegated bandwidth.
If one of these cases occurs, the receiver with one exception MUST If one of these cases occurs, the receiver, with one exception, MUST
send a Bandwidth Transfer message indicating Success. send a Bandwidth Transfer message indicating Success.
o If the NAS received the request, the allocated amount in the NAS's o If the NAS received the request, the allocated amount in the NAS's
response MUST be at least equal to NAS's view of the current response MUST be at least equal to the NAS's view of the current
amount of delegated bandwidth. amount of delegated bandwidth.
o If the AN received the request, the allocated amount in the AN's o If the AN received the request, the allocated amount in the AN's
response MUST be no greater than the AN's view of the current response MUST be no greater than the AN's view of the current
amount of delegated bandwidth. amount of delegated bandwidth.
The exception is when the NAS receives a request while it has a The exception is when the NAS receives a request while it has a
request of its own outstanding. Handling of that case is described request of its own outstanding. Handling of that case is described
below. below.
While the cases just described are an error condition, the success Note: While the cases just described are an error condition, the
response achieves a graceful recovery. success response achieves a graceful recovery.
To avoid deadlock due to race conditions, the following rules MUST be To avoid deadlock due to race conditions, the following rules MUST be
applied: applied:
a. If the NAS receives a Bandwidth Reallocation Request message a. If the NAS receives a Bandwidth Reallocation Request message
while it has a Bandwidth Reallocation Request message of its own while it has a Bandwidth Reallocation Request message of its own
outstanding for the same access line, the NAS MUST provide an outstanding for the same access line, the NAS MUST provide an
immediate failure response to the request from the AN, with a immediate failure response to the request from the AN, with a
Result Code value set to 0x68 "Inconsistent views of delegated Result Code value set to 0x68 "Inconsistent views of delegated
bandwidth amount" or 0x69 "Bandwidth request conflict" as bandwidth amount" or 0x69 "Bandwidth request conflict" as
applicable. (See below for more information). applicable. (See below for more information).
b. If the AN receives a Bandwidth Reallocation Request message while b. If the AN receives a Bandwidth Reallocation Request message while
it has a Bandwidth Reallocation Request message of its own it has a Bandwidth Reallocation Request message of its own
outstanding for the same access line, the AN MUST release any outstanding for the same access line, the AN MUST release any
bandwidth it has already committed to an outstanding Join request bandwidth it has already committed to an outstanding join request
while it is awaiting a response from the NAS. It MUST decide while it is awaiting a response from the NAS. It MUST decide
upon and send its response to the NAS taking the released upon and send its response to the NAS taking the released
bandwidth into account. bandwidth into account.
If the receiver is unable to process the Bandwidth Reallocation If the receiver is unable to process the Bandwidth Reallocation
Request message due to an error, then the receiver MUST return a Request message due to an error, then the receiver MUST return a
Bandwidth Transfer message where: Bandwidth Transfer message where:
o the Result field is set to Failure (0x4), o the Result field is set to Failure (0x4),
o the Result Code field is set appropriately to indicate the type of o the Result Code field is set appropriately to indicate the type of
error that was detected, error that was detected,
o the Bandwidth Allocation TLV contains the value of the current o the Bandwidth-Allocation TLV contains the value of the current
amount of delegated bandwidth as the responder views it, and amount of delegated bandwidth as the responder views it, and
o a Status-Info TLV MAY follow the Bandwidth Allocation TLV giving o a Status-Info TLV MAY follow the Bandwidth-Allocation TLV giving
further information about the error. further information about the error.
This specification provides three new Result Code values applicable This specification provides three new Result Code values applicable
specifically to the contents of the Bandwidth-Request TLV. These specifically to the contents of the Bandwidth-Request TLV. These
Result Code values by their nature MUST only be used when the error Result Code values by their nature MUST only be used when the error
is being reported in a Bandwidth Transfer message rather than a is being reported in a Bandwidth Transfer message rather than a
Generic Response message. Generic Response message.
0x67 Invalid preferred bandwidth amount. 0x67 Invalid preferred bandwidth amount.
skipping to change at page 32, line 29 skipping to change at page 32, line 8
previous section, it is the required response to a valid Bandwidth previous section, it is the required response to a valid Bandwidth
Reallocation Request message. Reallocation Request message.
The Bandwidth Transfer message MAY also be used to transfer bandwidth The Bandwidth Transfer message MAY also be used to transfer bandwidth
autonomously from one peer to another. One example of this usage is autonomously from one peer to another. One example of this usage is
to release bandwidth borrowed earlier by means of the Bandwidth to release bandwidth borrowed earlier by means of the Bandwidth
Reallocation Request message. When the message is used in this way, Reallocation Request message. When the message is used in this way,
the Result field in the Bandwidth Transfer message MUST be set to the Result field in the Bandwidth Transfer message MUST be set to
Ignore (0x0). Ignore (0x0).
This allows the receiver to distinguish between an autonomous Note: This allows the receiver to distinguish between an
transfer and a response to a previous Bandwidth Reallocation autonomous transfer and a response to a previous Bandwidth
Request, for purposes of validation. Reallocation Request message, 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 Behavior
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
access line concerned; access line concerned.
o if the message is sent by the AN, the bandwidth value in the o If the message is sent by the AN, the bandwidth value in the
Bandwidth-Allocation TLV MUST be less than or equal to the Bandwidth-Allocation TLV MUST be less 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
access line concerned. access line concerned.
Further sender behaviour is specified above, in Section 4.5.2. Further sender behavior is specified above, in Section 4.5.2.
4.6.2. Receiver Behaviour 4.6.2. Receiver Behavior
4.6.2.1. Behaviour of the NAS 4.6.2.1. Behavior of the NAS
If the amount of delegated bandwidth provided in the Bandwidth- If the amount of delegated bandwidth provided in the Bandwidth-
Allocation TLV is not greater than the NAS's view of the current Allocation TLV is not greater than the NAS's view of the current
amount of delegated bandwidth, the NAS MUST update its view of the amount of delegated bandwidth, the NAS MUST update its view of the
current amount of delegated bandwidth to the amount indicated in the current amount of delegated bandwidth to the amount indicated in the
Bandwidth Transfer message. This is required regardless of whether Bandwidth Transfer message. This is required regardless of whether
the Result field of that message indicates Success or Failure. the Result field of that message indicates Success or Failure.
If the amount of delegated bandwidth provided in the Bandwidth- If the amount of delegated bandwidth provided in the Bandwidth-
Allocation TLV is greater than the NAS's view of the current amount Allocation TLV is greater than the NAS's view of the current amount
of delegated bandwidth, the NAS MAY accept the given value as its new of delegated bandwidth, the NAS MAY accept the given value as its new
value of delegated bandwidth. Alternatively, the NAS MAY force the value of delegated bandwidth. Alternatively, the NAS MAY force the
AN to modify its view of the amount of delegated bandwidth to that AN to modify its view of the amount of delegated bandwidth to that
held by the NAS, by sending a Port Management message for the target held by the NAS by sending a Port Management message for the target
access line concerned, containing a Bandwidth-Allocation TLV with a access line concerned that contains a Bandwidth-Allocation TLV with a
value equal to the amount of delegated bandwidth the NAS wishes to value equal to the amount of delegated bandwidth the NAS wishes to
enforce. enforce.
4.6.2.2. Behaviour of the AN 4.6.2.2. Behavior of the AN
If the amount of delegated bandwidth provided in the Bandwidth- If the amount of delegated bandwidth provided in the Bandwidth-
Allocation TLV of the Bandwidth Transfer message differs from the Allocation TLV of the Bandwidth Transfer message differs from the
AN's view of the current amount of delegated bandwidth, the AN MUST AN's view of the current amount of delegated bandwidth, the AN MUST
update its view of the current amount of delegated bandwidth to the update its view of the current amount of delegated bandwidth to the
amount indicated in the Bandwidth Transfer message. This is required amount indicated in the Bandwidth Transfer message. This is required
with the exception of a Bandwidth Transfer message with a Result with the exception of a Bandwidth Transfer message with a Result
field equal to Failure (0x4) and a Result Code field equal to 0x68 field equal to Failure (0x4) and a Result Code field equal to 0x68
"Inconsistent views of delegated bandwidth amount" or 0x69 "Bandwidth "Inconsistent views of delegated bandwidth amount" or 0x69 "Bandwidth
request conflict". If Result Code value 0x68 is received, the AN request conflict". If Result Code value 0x68 is received, the AN
MUST issue a Delegated Bandwidth Query Request message to determine MUST issue a Delegated Bandwidth Query Request message to determine
the NAS's current view of the amount of delegated bandwidth. The AN the NAS's current view of the amount of delegated bandwidth. The AN
MUST update its own view based on the value returned in the Delegated MUST update its own view based on the value returned in the Delegated
Bandwidth Query Response. If Result Code value 0x69 is received, the Bandwidth Query Response message. If Result Code value 0x69 is
AN SHOULD carry out this procedure unless it can account for the received, the AN SHOULD carry out this procedure unless it can
discrepancy as a result of a transfer of bandwidth to the NAS that account for the discrepancy as a result of a transfer of bandwidth to
was carried out just before the incoming Bandwidth Transfer message the NAS that was carried out just before the incoming Bandwidth
was processed. Transfer message was processed.
The two Result Code values indicate a race condition where the AN Note: The two Result Code values indicate a race condition where
may have just completed a transfer of bandwidth to the NAS. As a the AN may have just completed a transfer of bandwidth to the NAS.
result, the value given in the Bandwidth Transfer message may be As a result, the value given in the Bandwidth Transfer message may
outdated, and the AN needs to query the NAS to find its latest be outdated, and the AN needs to query the NAS to find its latest
view. The procedure assumes that ordering is preserved between view. The procedure assumes that ordering is preserved between
the Bandwidth Transfer message sent by the AN in response to the the Bandwidth Transfer message sent by the AN in response to the
NAS's request and the subsequent Delegated Bandwidth Query Request NAS's request and the subsequent Delegated Bandwidth Query Request
message. message.
If as the result of the procedures just described the AN determines If the AN has already committed multicast bandwidth exceeding the
that it has over-committed multicast bandwidth, it MUST NOT terminate amount given in the Bandwidth-Allocation TLV, the AN SHOULD NOT
any currently-active programs, but MUST NOT honour any more "join" discontinue any multicast streams in order to bring bandwidth down to
requests until it is possible to do so within the limit set by its within the new limit, unless such action is required by local policy.
current value of delegated bandwidth. However, the AN MUST NOT admit new multicast streams that are subject
to admission control until it can do so within the limit specified by
the Bandwidth-Allocation TLV. As specified in Section 6.2.5.2, the
AN MAY attempt to correct the situation by sending a request to the
NAS for an increased allocation of delegated bandwidth using the
Bandwidth Reallocation Request message.
4.7. Delegated Bandwidth Query Request Message 4.7. Delegated Bandwidth Query Request Message
The Message Type for the Delegated Bandwidth Query Request (and The Message Type for the Delegated Bandwidth Query Request (and
Response) messages is 148. Response) messages is 148.
The Delegated Bandwidth Query Request message MAY be sent either by The Delegated Bandwidth Query Request message MAY be sent either by
the NAS or by the AN to retrieve the peer's view of the amount of the NAS or by the AN to retrieve the peer's view of the amount of
delegated bandwidth. The request contains one TLV: delegated bandwidth. The request contains one TLV:
o a Target TLV designating the access line for which the information o a Target TLV designating the access line for which the information
is requested. is requested.
4.7.1. Sender Behaviour 4.7.1. Sender Behavior
The sender MUST set the Result field in the header of the Delegated The sender MUST set the Result field in the header of the Delegated
Bandwidth Query Request message to AckAll (0x2). The Result Code Bandwidth Query Request message to AckAll (0x2). The Result Code
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 Behavior
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 Identifier field MUST be copied from the request message.
body of the response MUST contain the Target TLV, copied from the 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
ports do not exist"). The Transaction-Id field MUST be copied from ports do not exist"). The Transaction Identifier field MUST be
the request. The body of the response MUST contain the Target TLV copied from the request. The body of the response MUST contain the
copied from the request. This MAY be followed by a Status-Info TLV Target TLV copied from the request. This MAY be followed by a
giving further information about the error. Status-Info TLV giving further information about the error.
4.8. Delegated Bandwidth Query Response Message 4.8. Delegated Bandwidth Query Response Message
The Delegated Bandwidth Query Response message is sent in reply to a The Delegated Bandwidth Query Response message is sent in reply to a
Delegated Bandwidth Query Request. The response to a valid request Delegated Bandwidth Query Request message. The response to a valid
contains two TLVs: request contains two TLVs:
o the Target TLV, copied from the request; o the Target TLV, copied from the request; and
o a Bandwidth-Allocation TLV, giving the responder's view of the o a Bandwidth-Allocation TLV, giving the responder's view of the
current amount of multicast bandwidth delegated to the AN. current amount of multicast bandwidth delegated to the AN.
The Message Type for the Delegated Bandwidth Query Response message The Message Type for the Delegated Bandwidth Query Response message
is 148. is 148.
4.8.1. Sender Behaviour 4.8.1. Sender Behavior
Sender behaviour for the Delegated Bandwidth Query Response message Sender behavior for the Delegated Bandwidth Query Response message is
is specified in Section 4.7.2. specified in Section 4.7.2.
4.8.2. Receiver Behaviour 4.8.2. Receiver Behavior
If the Delegated Bandwidth Query Response message indicates Success If the Delegated Bandwidth Query Response message indicates Success
(0x3), the following actions apply. (0x3), the actions described in Sections 4.8.2.1 and 4.8.2.2 apply.
4.8.2.1. Behaviour at the NAS 4.8.2.1. Behavior at the NAS
If the amount of delegated bandwidth provided in the Bandwidth- If the amount of delegated bandwidth provided in the Bandwidth-
Allocation TLV is less than the NAS's view of the current amount of Allocation TLV is less than the NAS's view of the current amount of
delegated bandwidth, the NAS MUST update its view of the current delegated bandwidth, the NAS MUST update its view of the current
amount of delegated bandwidth to the amount indicated in the amount of delegated bandwidth to the amount indicated in the
Delegated Bandwidth Query Response message. Delegated Bandwidth Query Response message.
If the amount of delegated bandwidth provided in the Bandwidth- If the amount of delegated bandwidth provided in the Bandwidth-
Allocation TLV is greater than the NAS's view of the current amount Allocation TLV is greater than the NAS's view of the current amount
of delegated bandwidth, the NAS MAY accept the given value as its new of delegated bandwidth, the NAS MAY accept the given value as its new
value of delegated bandwidth. Alternatively, the NAS MAY force the value of delegated bandwidth. Alternatively, the NAS MAY force the
AN to modify its view of the amount of delegated bandwidth to that AN to modify its view of the amount of delegated bandwidth to that
held by the NAS, by sending a Port Management message for the target held by the NAS by sending a Port Management message for the target
access line concerned, containing a Bandwidth-Allocation TLV with a access line concerned that contains a Bandwidth-Allocation TLV with a
value equal to the amount of delegated bandwidth the NAS wishes to value equal to the amount of delegated bandwidth the NAS wishes to
enforce. enforce.
4.8.2.2. Behaviour at the AN 4.8.2.2. Behavior at the AN
The AN SHOULD accept the value returned in the Bandwidth-Allocation The AN SHOULD accept the value returned in the Bandwidth-Allocation
TLV of the Delegated Bandwidth Query Response message as the correct TLV of the Delegated Bandwidth Query Response message as the correct
value of the current amount of delegated bandwidth. If the AN has value of the current amount of delegated bandwidth. If the AN has
currently committed more than this amount to active programs, it MUST already committed multicast bandwidth exceeding the amount given in
NOT cease replicating the flows concerned, but MUST NOT honour any the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any
more Join requests until possible to do so within the new limit. multicast streams in order to bring bandwidth down to within the new
limit, unless such action is required by local policy. However, the
AN MUST NOT admit new multicast streams that are subject to admission
control until it can do so within the limit specified by the
Bandwidth-Allocation TLV. As specified in Section 6.2.5.2, the AN
MAY attempt to correct the situation by sending a request to the NAS
for an increased allocation of delegated bandwidth using the
Bandwidth Reallocation Request message.
A race condition is possible, where the AN sends a query, the NAS Note: A race condition is possible where the AN sends a query, the
requests more bandwidth, then receives and responds to the query, NAS requests more bandwidth, then receives and responds to the
then receives the Bandwidth Transfer message responding to its query, and then receives the Bandwidth Transfer message responding
request. It is up to the AN to take appropriate action in this to its request. It is up to the AN to take appropriate action in
case. The best action appears to be not to act on the result of this case. The best action appears to be not to act on the result
the first query, but to repeat the query after sending the of the first query but to repeat the query after sending the
Bandwidth Transfer message. Similar considerations apply to a Bandwidth Transfer message. Similar considerations apply to a
race between queries from both sides. race between queries from both sides.
4.9. Multicast Flow Query Request and Response Messages 4.9. Multicast Flow Query Request and Response Messages
This section defines two new messages called the Multicast Flow Query This section defines two new messages called the Multicast Flow Query
Request and Multicast Flow Query Response. The Multicast Flow Query Request and Multicast Flow Query Response. The Multicast Flow Query
Request is sent by the NAS to request information about the multicast Request message is sent by the NAS to request information about the
flows that are active on the AN. The Multicast Flow Query Response multicast flows that are active on the AN. The Multicast Flow Query
is sent in response by the AN to provide the requested information to Response message is sent in response by the AN to provide the
the NAS. requested information to the NAS.
The Message Type for the Multicast Flow Query Request and Multicast The Message Type for the Multicast Flow Query Request and Multicast
Flow Query Response messages is 149. Flow Query Response messages is 149.
The contents of the Multicast Flow Query Request and Response depend The contents of the Multicast Flow Query Request and Multicast Flow
on the nature of the query, as described below. Query Response messages depend on the nature of the query, as
described below.
4.9.1. Sender Behaviour 4.9.1. Sender Behavior
The sender of a Multicast Flow Query Request message MUST set the The sender of a Multicast Flow Query Request message MUST set the
Result field to AckAll (0x2). The Result Code field MUST be set to Result field to AckAll (0x2). The Result Code field MUST be set to
0x000. The sender MUST populate the ANCP Transaction Identifier 0x000. The sender MUST populate the ANCP Transaction Identifier
field with a unique value, as described in section 3.6.1.6 of field with a unique value, as described in Section 3.6.1.6 of
[RFC6320]. [RFC6320].
The Multicast Flow Query Request MAY be used by the NAS to retrieve: The Multicast Flow Query Request message MAY be used by the NAS to
retrieve:
o the AN's view of which multicast flows are currently active on a o the AN's view of which multicast flows are currently active on a
specified set of access ports; or specified set of access ports; or
o the AN's view of the access ports on which a specified set of o the AN's view of the access ports on which a specified set of
multicast flows are currently active; or multicast flows are currently active; or
o the AN's view of all the multicast flows currently active on each o the AN's view of all the multicast flows currently active on each
access port of the AN. access port of the AN.
skipping to change at page 37, line 25 skipping to change at page 37, line 16
active on a given port of the AN, the NAS MUST include a Target TLV active on a given port of the AN, the NAS MUST include a Target TLV
in the Multicast Flow Query Request payload identifying that port. in the Multicast Flow Query Request payload identifying that port.
The Target TLV is encoded as specified in [RFC6320]. The Target TLV is encoded as specified in [RFC6320].
To retrieve the AN's view of the ports currently receiving a given To retrieve the AN's view of the ports currently receiving a given
multicast flow, the NAS MUST include a Multicast-Flow TLV in the multicast flow, the NAS MUST include a Multicast-Flow TLV in the
Multicast Flow Query Request payload identifying that flow. The Multicast Flow Query Request payload identifying that flow. The
Multicast-Flow TLV is encoded as specified in Section 5.12. Multicast-Flow TLV is encoded as specified in Section 5.12.
The NAS MAY include multiple Target TLVs or multiple Multicast-Flow The NAS MAY include multiple Target TLVs or multiple Multicast-Flow
TLVs in the Multicast Flow Query Request, but MUST NOT include both TLVs in the Multicast Flow Query Request message but MUST NOT include
Target and Multicast-Flow TLVs in the same message. both Target and Multicast-Flow TLVs in the same message.
To retrieve the AN's view of all of the multicast flows currently To retrieve the AN's view of all of the multicast flows currently
active on each port of the AN, the NAS MUST send a Multicast Flow 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 message that does not contain any instance of the
or the Multicast-Flow TLV. Target TLV or the Multicast-Flow TLV.
4.9.2. Receiver Behaviour 4.9.2. Receiver Behavior
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 Identifier field MUST be copied from the request.
If the Multicast Flow Query Request contained one (or more) Target If the Multicast Flow Query Request contains 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
identified in the preceding Target TLV. identified in the preceding Target TLV.
The Target TLVs MUST appear in the response from the AN in the same The Target TLVs MUST appear in the response from the AN in the same
order as in the query from the NAS. order as in the query from the NAS.
If the Multicast Flow Query Request contained one (or more) If the Multicast Flow Query Request message contains one (or more)
Multicast-Flow TLVs, the AN MUST include, for each of these Multicast-Flow TLVs, the AN MUST include, for each of these
Multicast-Flow TLVs, the following set of TLVs: Multicast-Flow TLVs, the following set of TLVs:
o Multicast-Flow TLV. This MUST be identical to the Multicast-Flow o Multicast-Flow TLV. This MUST be identical to the Multicast-Flow
TLV in the received Multicast Flow Query Request message. TLV in the received Multicast Flow Query Request message.
o Target TLV(s). The Target TLV MUST appear once per AN port on o Target TLV(s). The Target TLV MUST appear once per AN port on
which the multicast flow identified in the preceding Multicast- which the multicast flow identified in the preceding Multicast-
Flow TLV is active. Flow TLV is active.
The Multicast-Flow TLVs MUST appear in the response from the AN in The Multicast-Flow TLVs MUST appear in the response from the AN in
the same order as in the query from the NAS. the same order as in the query from the NAS.
If the Multicast Flow Query Request contained no Target TLV and no If the Multicast Flow Query Request message contains no Target TLV
Multicast Flow TLV, the AN MUST include, for each AN port currently and no Multicast Flow TLV, the AN MUST include, for each AN port
receiving multicast flow(s), the following set of TLVs: currently receiving multicast flow(s), the following set of TLVs:
o Target TLV. This MUST identify one AN port. o Target TLV. This MUST identify one AN port.
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
identified in the preceding Target TLV. identified in the preceding Target TLV.
If the contents of the Multicast Flow Query Request are in error, the If the contents of the Multicast Flow Query Request message are in
AN MUST reply with a Multicast Flow Query Response message with the error, the AN MUST reply with a Multicast Flow Query Response message
Result field set to Failure (0x4) and the Result Code field set to with the Result field set to Failure (0x4) and the Result Code field
indicate the nature of the error. If the request contained multiple set to indicate the nature of the error. If the request contained
instances of the Target TLV or the Multicast-Flow TLV and one of multiple instances of the Target TLV or the Multicast-Flow TLV and
these is in error, the response message MUST contain the results for one of these is in error, the response message MUST contain the
the preceding instances of the TLV as if there had been no error. results for the preceding instances of the TLV as if there had been
These successful results MUST be followed by the TLV in error, copied no error. These successful results MUST be followed by the TLV in
from the request. The AN MUST NOT do further processing of the error, copied from the request. The AN MUST NOT do further
request. The AN MAY add a Status-Info TLV to provide further processing of the request. The AN MAY add a Status-Info TLV to
information on the nature of the error. provide further information on the nature of the error.
4.10. Committed Bandwidth Report Message 4.10. Committed Bandwidth Report Message
This section describes the Committed Bandwidth Report message, which This section describes the Committed Bandwidth Report message, which
is sent from the AN to the NAS to report the most recent amount of is sent from the AN to the NAS to report the most recent amount of
multicast bandwidth usage committed to one or more access lines. multicast bandwidth usage committed to one or more access lines.
The Message Type for the Committed Bandwidth Report message is 150. The Message Type for the Committed Bandwidth Report message is 150.
The Committed Bandwidth Report message contains one or more instances The Committed Bandwidth Report message contains one or more instances
of the Committed-Bandwidth TLV, as described in Section 5.14. of the Committed-Bandwidth TLV, as described in Section 5.14.
4.10.1. Sender Behaviour 4.10.1. Sender Behavior
The sender of a Committed Bandwidth Report message MUST set the The sender of a Committed Bandwidth Report message MUST set the
Result field to Ignore (0x0). The Result Code field MUST be set to Result field to Ignore (0x0). The Result Code field MUST be set to
0x000. The sender MUST populate the ANCP Transaction Identifier 0x000. The sender MUST populate the ANCP Transaction Identifier
field with a unique value, as described in section 3.6.1.6 of field with a unique value, as described in Section 3.6.1.6 of
[RFC6320]. [RFC6320].
Each instance of the Committed-Bandwidth TLV included in the message Each instance of the Committed-Bandwidth TLV included in the message
MUST identify an access line for which the amount of committed MUST identify an access line for which the amount of committed
multicast bandwidth has changed since the previous Committed multicast bandwidth has changed since the previous Committed
Bandwidth Report message was sent and MUST report the latest amount Bandwidth Report message was sent and MUST report the latest amount
of multicast bandwidth committed to that line. There MUST be only of multicast bandwidth committed to that line. There MUST be only
one instance of the Committed-Bandwidth TLV present in the message one instance of the Committed-Bandwidth TLV present in the message
for any given access line. The message MUST include an instance of for any given access line. The message MUST include an instance of
the Committed-Bandwidth TLV for every access line for which committed the Committed-Bandwidth TLV for every access line for which committed
multicast bandwidth has changed since the previous Committed multicast bandwidth has changed since the previous Committed
Bandwidth Report message was sent. Bandwidth Report message was sent.
Further behaviour at the AN is specified in Section 6.2.2. Further behavior at the AN is specified in Section 6.2.2.
4.10.2. Receiver Behaviour 4.10.2. Receiver Behavior
The usage of the contents of a Committed Bandwidth Report message The usage of the contents of a Committed Bandwidth Report message
received by the NAS is implementation-dependent. One example is that received by the NAS is implementation-dependent. One example is that
the NAS uses the reports of multicast bandwidth commitments to adjust the NAS uses the reports of multicast bandwidth commitments to adjust
its forwarding scheduler operation to provide the intended level of its forwarding scheduler operation to provide the intended level of
QoS. QoS.
The NAS MUST NOT reply to a valid Committed Bandwidth Report message. The NAS MUST NOT reply to a valid Committed Bandwidth Report message.
The NAS MAY send a Generic Response message indicating the nature of The NAS MAY send a Generic Response message indicating the nature of
any errors detected in a Committed Bandwidth Report message that it any errors detected in a Committed Bandwidth Report message that it
skipping to change at page 40, line 5 skipping to change at page 39, line 43
This section defines new ANCP TLVs for the control of multicast This section defines new ANCP TLVs for the control of multicast
flows. flows.
5.1. Multicast-Service-Profile TLV 5.1. Multicast-Service-Profile TLV
This document defines the new Multicast-Service-Profile TLV. This document defines the new Multicast-Service-Profile TLV.
The Multicast-Service-Profile TLV MAY be included in a Provisioning The Multicast-Service-Profile TLV MAY be included in a Provisioning
message as specified in Section 4.1. message as specified in Section 4.1.
The Multicast-Service-Profile TLV is illustrated in Figure 6. It The Multicast-Service-Profile TLV is illustrated in Figure 7. It
consists of a TLV header encapsulating a single instance of the consists of a TLV header encapsulating a single instance of the
Multicast-Service-Profile-Name TLV and one or more instances of the Multicast-Service-Profile-Name TLV and one or more instances of the
List-Action TLV. List-Action TLV.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Service-Profile 0x0013 | TLV Length | | Mcast-Service-Profile 0x0013 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Service-Profile-Name TLV | | Multicast-Service-Profile-Name TLV |
skipping to change at page 40, line 28 skipping to change at page 40, line 23
| List-Action TLV | | List-Action TLV |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action TLV | | List-Action TLV |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Multicast-Service-Profile TLV Figure 7: Multicast-Service-Profile TLV
The Multicast-Service-Profile TLV has the following fields: The Multicast-Service-Profile TLV has the following fields:
o The Multicast-Service-Profile TLV Type is 0x0013. o TLV Type: 0x0013
o The TLV length is determined by the contents following the TLV o TLV Length: determined by the contents following the TLV header.
header.
o The Multicast-Service-Profile-Name TLV is described in o Multicast-Service-Profile-Name TLV: described in Section 5.2. The
Section 5.2. The Multicast-Service-Profile-Name TLV MUST contain Multicast-Service-Profile-Name TLV MUST contain an identifier that
an identifier which is unique over all profiles provisioned to the is unique over all profiles provisioned to the same AN partition.
same AN partition. This identifier will be used to refer to the This identifier will be used to refer to the profile when
profile when activating it for a given target within a Port activating it for a given target within a Port Management message
Management message (see Section 4.2). (see Section 4.2).
o The List-Action TLV is described in Section 5.3. The List-Action o List-Action TLV: described in Section 5.3. The List-Action TLV(s)
TLV(s) provide the content of a newly defined multicast service provide the content of a newly defined multicast service profile
profile or modify the existing content. If more than one List- or modify the existing content. If more than one List-Action TLV
Action TLV is present, the order of the TLVs may be significant, is present, the order of the TLVs may be significant, since List-
since List-Action TLVs are processed in the order in which they Action TLVs are processed in the order in which they appear.
appear.
5.2. Multicast-Service-Profile-Name TLV 5.2. Multicast-Service-Profile-Name TLV
The Multicast-Service-Profile-Name TLV carries the identifier of a The Multicast-Service-Profile-Name TLV carries the identifier of a
multicast service profile provisioned on the AN. It is illustrated multicast service profile provisioned on the AN. It is illustrated
in Figure 7. in Figure 8.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Svc-Profile-Name 0x0018 | TLV Length | | Mcast-Svc-Profile-Name 0x0018 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile identifier | | Multicast service profile identifier |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Multicast-Service-Profile-Name TLV Figure 8: Multicast-Service-Profile-Name TLV
The Multicast-Service-Profile-Name TLV has the following fields: The Multicast-Service-Profile-Name TLV has the following fields:
o The Multicast-Service-Profile-Name TLV Type is 0x0018. o TLV Type: 0x0018
o TLV Length: up to 255 octets. o TLV Length: up to 255 octets.
o Multicast service profile identifier: an opaque sequence of octets o Multicast service profile identifier: an opaque sequence of octets
identifying a specific multicast service profile. identifying a specific multicast service profile.
The identifier could have the form of human-readable text or an Note: The identifier could have the form of human-readable text
arbitrary binary value, depending on the operator's practices. or an arbitrary binary value, depending on the operator's
practices.
5.3. List-Action TLV 5.3. List-Action TLV
The List-Action TLV identifies multicast flows to be added to or The List-Action TLV identifies multicast flows to be added to or
removed from a list of white-, black-, or grey-listed flows. It is removed from a list of white-, black-, or grey-listed flows. It is
meaningful only in association with a Multicast-Service-Profile-Name meaningful only in association with a Multicast-Service-Profile-Name
TLV identifying the profile to which the List-Action TLV applies. TLV identifying the profile to which the List-Action TLV applies.
Such an association can be achieved by placing both TLVs in the same Such an association can be achieved by placing both TLVs in the same
base message payload or as embedded TLVs of another TLV such as the base message payload or as embedded TLVs of another TLV such as the
Multicast-Service-Profile. The List-Action TLV is shown in Figure 8. Multicast-Service-Profile TLV. The List-Action TLV is shown in
Figure 9.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | TLV Length | | TLV Type = List-Action 0x0021 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation | List Type | Reserved | | Operation | List Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields | | Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 42, line 25 skipping to change at page 42, line 25
...... ......
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields | | Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields | | Multicast flow fields |
...... ......
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: List-Action TLV Figure 9: List-Action TLV
The List-Action TLV contains the following fields: The List-Action TLV contains the following fields:
o The List-Action TLV Type is 0x0021. o TLV Type: 0x0021
o TLV Length: length of the subsequent contents. o TLV Length: length of the subsequent contents.
o Operation: operation to be performed upon the white, black, or o Operation: operation to be performed upon the white, black, or
grey list identified by the List Type field within the profile grey list identified by the List Type field within the profile
identified by the associated Multicast-Service-Profile-Name identified by the associated Multicast-Service-Profile-Name
embedded TLV. The possible values are: embedded TLV. The possible values are:
* 1 "Add": the multicast flow fields are to be added to the list. * 1 "Add": the multicast flow fields are to be added to the list.
* 2 "Delete": the multicast flow fields are to be removed from * 2 "Delete": the multicast flow fields are to be removed from
the list. Each multicast flow field in the List-Action MUST the list. Each multicast flow field in the List-Action MUST
match exactly an existing entry in the list concerned. Thus to match exactly an existing entry in the list concerned. Thus,
remove part of the range provided by a wildcarded list entry, to remove part of the range provided by a wildcarded list
it is necessary to remove the entire entry and add back the entry, it is necessary to remove the entire entry and add back
remaining partial range(s). the remaining partial range(s).
* 3 "Replace": the multicast flow fields replace the existing * 3 "Replace": the multicast flow fields replace the existing
contents of the list. contents of the list.
o List Type: the list type being modified by this List-Action. The o List Type: the list type being modified by this List-Action TLV.
possible values are 1 "White", 2 "Black", or 3 "Grey". The possible values are 1 "White", 2 "Black", or 3 "Grey".
o Reserved: a sender MUST set this field to zeroes. A receiver MUST o Reserved: a sender MUST set this field to zeroes. A receiver MUST
ignore the contents of this field. ignore the contents of this field.
o Address Family: the IP version of the set of multicast flow fields o Address Family: the IP version of the set of multicast flow fields
that follow, encoded according to [PIMreg]. Possible values are 1 that follow, encoded according to [PIMreg]. Possible values are 1
"IPv4" or 2 "IPv6". Either an IPv4 list or an IPv6 list or both "IPv4" or 2 "IPv6". Either an IPv4 list or an IPv6 list or both
MAY be present in the List-Action TLV. MAY be present in the List-Action TLV.
o Number of flow fields: the number of multicast flow fields of the o Number of flow fields: the number of multicast flow fields of the
given address family which follow. given address family that follows.
o Multicast flow field: a field identifying one or more multicast o Multicast flow field: a field identifying one or more multicast
flows. It consists of an 8-bit group address prefix length, an flows. It consists of an 8-bit group address prefix length, an
8-bit source address prefix length, a 0-16 octet group prefix, and 8-bit source address prefix length, a group prefix of 0-16 octets,
a 0-16 octet source prefix, as shown in Figure 9. and a source prefix of 0-16 octets, as shown in Figure 10.
Each multicast flow field refers either to a Source-Specific Each multicast flow field refers either to a Source-Specific
Multicast (SSM) channel or to an Any Source Multicast (ASM) group. Multicast (SSM) channel or to an Any-Source Multicast (ASM) group.
The scope of the designation may be broadened to multiple channels or The scope of the designation may be broadened to multiple channels or
groups through use of prefix length values smaller than the total groups through use of prefix length values smaller than the total
address length for the given address family. Multicast flow fields address length for the given address family. Multicast flow fields
MUST be placed consecutively within the embedded TLV without MUST be placed consecutively within the embedded TLV without
intervening padding except to round out individual addresses to the intervening padding except to round out individual addresses to the
nearest octet boundary. nearest octet boundary.
A multicast flow field consists of two single-octet prefix lengths A multicast flow field consists of two single-octet prefix lengths
followed by zero to two prefix values as shown in Figure 9: followed by zero to two prefix values as shown in Figure 10:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Group PrefLen | | Group PrefLen |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Source PrefLen| | Source PrefLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Prefix (multicast) (0 to 16 octets) | | Group Prefix (multicast) (0 to 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Prefix (unicast, SSM only) (0 to 16 octets) | | Source Prefix (unicast, SSM only) (0 to 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Organization of a Single Multicast Flow Field Figure 10: Organization of a Single Multicast Flow Field
The prefix length has its usual meaning. It is the number of most- The prefix length has its usual meaning. It is the number of most-
significant bits specified within the corresponding prefix. The significant bits specified within the corresponding prefix. The
prefix length MAY vary from 0 to 32 in the IPv4 sub-list, and from 0 prefix length MAY vary from 0 to 32 in the IPv4 sub-list and from 0
to 128 in the IPv6 sub-list. to 128 in the IPv6 sub-list.
A value of 0 for either the Group PrefLen (prefix length) or the A value of 0 for either the Group PrefLen (prefix length) or the
Source PrefLen indicates that any value of the corresponding address Source PrefLen indicates that any value of the corresponding address
will match (wild card). If the value 0 is provided for a particular will match (wildcard). If the value 0 is provided for a particular
prefix length, the corresponding prefix MUST be omitted from the prefix length, the corresponding prefix MUST be omitted from the
field contents. field contents.
The length of a Source or Group Prefix field is equal to (PrefLen + The length of a Source or Group Prefix field is equal to (PrefLen +
7)/8 octets, truncated to the nearest integer. Unused bits at the 7)/8 octets, truncated to the nearest integer. Unused bits at the
end of the prefix MUST be set to zeroes. end of the prefix MUST be set to zeroes.
5.4. Sequence-Number TLV 5.4. Sequence-Number TLV
The Sequence-Number TLV conveys a sequence number of some sort. The The Sequence-Number TLV conveys a sequence number of some sort. The
specific meaning of the sequence number is message-specific. Within specific meaning of the sequence number is message-specific. Within
this specification, the Sequence-Number TLV is used as a embedded TLV this specification, the Sequence-Number TLV is used as an embedded
in a Status-Info TLV, in a Generic Response reporting a failed TLV in a Status-Info TLV in a Generic Response message reporting a
command in a Multicast Replication Control or Multicast Admission failed command in a Multicast Replication Control or Multicast
Request message. It identifies the sequence number within the Admission Request message. It identifies the sequence number within
message of the command that failed. the message of the command that failed.
The Sequence-Number TLV has the format shown in Figure 10. The Sequence-Number TLV has the format shown in Figure 11.
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 = Sequence-Number 0x0022 | TLV Length = 4 | | Type = Sequence-Number 0x0022 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number | | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Sequence-Number TLV Figure 11: Sequence-Number TLV
The Sequence-Number TLV has the following fields: The Sequence-Number TLV has the following fields:
o The Sequence-Number TLV Type is 0x0022. o TLV Type: 0x0022
o TLV length is 4. o TLV Length: 4
o Sequence number: the sequence number of a specific entity within a o Sequence number: the sequence number of a specific entity within a
series, where numbering starts from 1 for the first entity in the series, where numbering starts from 1 for the first entity in the
series. Represented as a 32-bit binary number, most significant series. Represented as a 32-bit binary number, most significant
bit first. bit first.
5.5. Bandwidth-Allocation TLV 5.5. Bandwidth-Allocation TLV
The Bandwidth-Allocation TLV is used to indicate the total amount of The Bandwidth-Allocation TLV is used to indicate the total amount of
video bandwidth delegated to the AN for multicast admission control video bandwidth delegated to the AN for multicast admission control
for a given access line, in kilobits per second. The TLV has the for a given access line, in kilobits per second. The TLV has the
format shown in Figure 11. format shown in Figure 12.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 | | Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount (kbits/s) | | Delegated amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: The Bandwidth-Allocation TLV Figure 12: Bandwidth-Allocation TLV
The Bandwidth-Allocation TLV has the following fields: The Bandwidth-Allocation TLV has the following fields:
o The Bandwidth-Allocation TLV Type is 0x0015. o TLV Type: 0x0015
o TLV length is 4. o TLV Length: 4
o Delegated amount: the bandwidth amount delegated to the AN for o Delegated amount: the bandwidth amount delegated to the AN for
admission of multicast video on a given port, kilobits per second. admission of multicast video on a given port, kilobits per second.
Presented as a 32-bit binary value, most significant bit first. Represented as a 32-bit binary value, most significant bit first.
5.6. White-List-CAC TLV 5.6. White-List-CAC TLV
The White-List-CAC TLV is used to indicate that the NAS wishes the AN The White-List-CAC TLV is used to indicate that the NAS wishes the AN
to do admission control for white-listed flows. Details on when the to do admission control for white-listed flows. Details on when the
White-List-CAC TLV may be provisioned are specified in Section 6. White-List-CAC TLV may be provisioned are specified in Section 6.
The White-List-CAC TLV is illustrated in Figure 12. The White-List-CAC TLV is illustrated in Figure 13.
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 = White-List-CAC 0x0024 | TLV Length = 0 | | Type = White-List-CAC 0x0024 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: White-List-CAC TLV Figure 13: White-List-CAC TLV
The White-List-CAC TLV contains the following fields: The White-List-CAC TLV contains the following fields:
o The White-List-CAC TLV Type is 0x0024. o TLV Type: 0x0024
o TLV length is 0, since the TLV contains no data other than the TLV o TLV Length: 0, since the TLV contains no data other than the TLV
header. header.
5.7. MRepCtl-CAC TLV 5.7. MRepCtl-CAC TLV
The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to
do admission control for flows added by the Multicast Replication do admission control for flows added by the Multicast Replication
Control message. Details on when the MRepCtl-CAC TLV may be Control message. Details on when the MRepCtl-CAC TLV may be
provisioned are specified in Section 6. The MRepCtl-CAC TLV is provisioned are specified in Section 6. The MRepCtl-CAC TLV is
illustrated in Figure 13. illustrated in Figure 14.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = MRepCtl-CAC 0x0025 | TLV Length = 0 | |TLV Type = MRepCtl-CAC 0x0025 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: MRepCtl-CAC TLV Figure 14: MRepCtl-CAC TLV
The MRepCtl-CAC TLV contains the following fields: The MRepCtl-CAC TLV contains the following fields:
o The MRepCtl-CAC TLV Type is 0x0025. o TLV Type: 0x0025
o TLV length is 0, since the TLV contains no data other than the TLV o TLV Length: 0, since the TLV contains no data other than the TLV
header. header.
5.8. Bandwidth-Request TLV 5.8. Bandwidth-Request TLV
The Bandwidth-Request TLV is used to request an adjustment of the The Bandwidth-Request TLV is used to request an adjustment of the
total amount of video bandwidth allocated to the AN for multicast total amount of video bandwidth allocated to the AN for multicast
admission control for a given line. The "Required amount" field admission control for a given line. The "Required amount" field
indicates the minimum adjustment required to meet the request. The indicates the minimum adjustment required to meet the request. The
"Preferred amount" field indicates the adjustment the requestor would "Preferred amount" field indicates the adjustment the requestor would
prefer to have, if possible. Section 4.5 discusses the required prefer to have, if possible. Section 4.5 discusses the required
relationships between the "Required amount", "Preferred amount", and relationships between the "Required amount", "Preferred amount", and
current values of total bandwidth allocated to the AN. current values of total bandwidth allocated to the AN.
The Bandwidth-Request TLV has the format shown in Figure 14. The Bandwidth-Request TLV has the format shown in Figure 15.
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=Bandwidth-Request 0x0016 | TLV Length = 8 | | Type=Bandwidth-Request 0x0016 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required amount (kbits/s) | | Required amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred amount (kbits/s) | | Preferred amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: The Bandwidth-Request TLV Figure 15: Bandwidth-Request TLV
The Bandwidth-Request TLV has the following fields: The Bandwidth-Request TLV has the following fields:
o The Bandwidth-Request TLV Type is 0x0016. o TLV Type: 0x0016
o The TLV length is 8 octets. o TLV Length: 8 octets
o Required amount: the minimum or maximum amount, depending on o Required amount: the minimum or maximum amount, depending on
whether the sender is the AN or the NAS respectively, of delegated whether the sender is the AN or the NAS respectively, of delegated
video bandwidth that is being requested, in kilobits per second. video bandwidth that is being requested, in kilobits per second.
Presented as a 32-bit binary value, most significant bit first. Represented as a 32-bit binary value, most significant bit first.
o Preferred amount: the preferred amount of delegated video o Preferred amount: the preferred amount of delegated video
bandwidth that is being requested, in kilobits per second. bandwidth that is being requested, in kilobits per second.
Presented as a 32-bit binary value, most significant bit first. Represented as a 32-bit binary value, most significant bit first.
5.9. Request-Source-IP TLV 5.9. Request-Source-IP TLV
The Request-Source-IP TLV provides the IP address of the entity that The Request-Source-IP TLV provides the IP address of the entity that
originated a specific request to join or leave a multicast channel. originated a specific request to join or leave a multicast channel.
The TLV is illustrated in Figure 15. The TLV is illustrated in Figure 16.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Request-Source-IP | TLV length = 4 or 16 | | TLV Type = Request-Source-IP | TLV Length = 4 or 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Address | | Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Request-Source-IP TLV Figure 16: Request-Source-IP TLV
The Request-Source-IP TLV contains the following fields: The Request-Source-IP TLV contains the following fields:
o The Request-Source-IP TLV Type is 0x0092. o TLV Type: 0x0092
o TLV length is 4 for an IPv4 address or 16 for an IPv6 address. o TLV Length: 4 for an IPv4 address or 16 for an IPv6 address.
o Unicast address: IP address of the source of a multicast flow join o Unicast address: IP address of the source of a multicast flow join
request, in network byte order. request, in network byte order.
5.10. Request-Source-MAC TLV 5.10. Request-Source-MAC TLV
The Request-Source-MAC TLV provides the MAC address of the entity The Request-Source-MAC TLV provides the MAC address of the entity
that originated a specific request to join or leave a multicast that originated a specific request to join or leave a multicast
channel. The TLV is illustrated in Figure 16. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type=Request-Source-MAC | TLV Length = 6 or 8 | |TLV Type=Request-Source-MAC | TLV Length = 6 or 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+- IEEE MAC Address +-+-+-+ +-+-+- IEEE MAC Address +-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Request-Source-MAC TLV Figure 17: Request-Source-MAC TLV
The Request-Source-MAC TLV contains the following fields: The Request-Source-MAC TLV contains the following fields:
o The Request-Source-MAC TLV Type is 0x0093. o TLV Type: 0x0093.
o TLV length is either 6 octets (MAC-48 or EUI-48) or 8 octets o TLV Length: either 6 octets (MAC-48 or EUI-48) or 8 octets (EUI-
(EUI-64). 64).
o IEEE MAC Address: MAC address of the device originating the o IEEE MAC Address: MAC address of the device originating the
request to join a multicast flow. Within the address, bytes and request to join a multicast flow. Within the address, bytes and
bits respectively shall be ordered from most to least significant, bits, respectively, shall be ordered from most to least
consistently with [IEEE48] for MAC-48 and EUI-48, and with significant, consistent with [IEEE48] for MAC-48 and EUI-48 and
[IEEE64] for EUI-64. with [IEEE64] for EUI-64.
EUI-48 and EUI-64 are registered trademarks of the IEEE. Note: EUI-48 and EUI-64 are registered trademarks of the IEEE.
5.11. Request-Source-Device-Id TLV 5.11. Request-Source-Device-Id TLV
The Request-Source-Device-Id TLV provides a local identifier of the The Request-Source-Device-Id TLV provides a local identifier of the
entity that originated a specific request to join or leave a entity that originated a specific request to join or leave a
multicast channel. The TLV is illustrated in Figure 17. multicast channel. The 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 18: 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 TLV Type: 0x0096.
o TLV length is 4. o TLV Length: 4
o Local device identifier value, known to the AN and AAA. Given o Identifier value: local device identifier value, known to the AN
that the scope of the identifier is a single customer network, 32 and AAA. Given that the scope of the identifier is a single
bits is a more than sufficient numbering space. customer network, 32 bits is a more-than-sufficient numbering
space.
5.12. Multicast-Flow TLV 5.12. Multicast-Flow TLV
IGMPv3 [RFC3376] and MLDv2 [RFC3810] allow multicast listeners to IGMPv3 [RFC3376] and MLDv2 [RFC3810] allow multicast listeners to
specify multiple source addresses for the same multicast group. specify multiple source addresses for the same multicast group.
Similarly the Multicast-Flow TLV specifies a multicast flow in terms Similarly, the Multicast-Flow TLV specifies a multicast flow in terms
of its multicast group address and, if applicable, one or more of its multicast group address and, if applicable, one or more
unicast source addresses. The Multicast-Flow TLV is illustrated in unicast source addresses. The Multicast-Flow TLV is illustrated in
Figure 18. Figure 19.
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 | Number of source addresses | | 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 19: 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 TLV Type: 0x0019
o TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow) o TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow)
upwards. Total length is 4 + 4*(Number of Source Addresses +1) upwards. Total length is 4 + 4*(Number of Source Addresses +1)
for IPv4 or 4 + 16*(Number of Source Addresses + 1) for IPv6. 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
registry ([PIMreg]). 1 indicates IPv4, 2 indicates IPv6. Family" registry ([PIMreg]). 1 indicates IPv4; 2 indicates IPv6.
o Number of Source Addresses: 0 for ASM, 1 or more for SSM. o Number of Source Addresses: 0 for ASM, 1 or more for SSM.
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), the number of source be present. If the Flow Type is "SSM" (2), the number of source
addresses given by the Number of Source Addresses field MUST be addresses given by the Number of Source Addresses field MUST be
skipping to change at page 50, line 25 skipping to change at page 50, line 30
EXCLUDE mode IGMP/MLD records to INCLUDE mode for the Multicast-Flow EXCLUDE mode IGMP/MLD records to INCLUDE mode for the Multicast-Flow
TLV. TLV.
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 20.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report-Buffering-Time 0x0094 | TLV Length = 4 | | Report-Buffering-Time 0x0094 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffering Time (ms) | | Buffering Time (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Report-Buffering-Time TLV Figure 20: Report-Buffering-Time TLV
The Report-Buffering-Time TLV contains the following fields: The Report-Buffering-Time TLV contains the following fields:
o The Report-Buffering-Time TLV Type is 0x0094. o TLV Type: 0x0094
o TLV length is 4 octets. o TLV Length: 4 octets
o Buffering Time is a 32-bit unsigned integer containing a time o Buffering Time is a 32-bit unsigned integer containing a time
value in ms. value in milliseconds (ms).
5.14. Committed-Bandwidth TLV 5.14. Committed-Bandwidth TLV
The Committed-Bandwidth TLV identifies an access line and provides The Committed-Bandwidth TLV identifies an access line and provides
the current amount of multicast bandwidth that the AN has committed the current amount of multicast bandwidth that the AN has committed
to it. The TLV is illustrated in Figure 20. to it. The TLV is illustrated in Figure 21.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed-Bandwidth 0x0095 | TLV Length (variable) | | Committed-Bandwidth 0x0095 | TLV Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Multicast Bandwidth (kbits/s) | | Committed Multicast Bandwidth (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Target TLV ~ ~ Target TLV ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Committed-Bandwidth TLV Figure 21: Committed-Bandwidth TLV
The Committed-Bandwidth TLV contains the following fields: The Committed-Bandwidth TLV contains the following fields:
o The Committed-Bandwidth TLV Type is 0x0095. o TLV Type: 0x0095
o TLV length is 4 octets plus the length of the Target TLV including o TLV Length: 4 octets plus the length of the Target TLV, including
its header and any padding. its header and any padding.
o Committed Multicast Bandwidth is a 32-bit unsigned integer o Committed Multicast Bandwidth: a 32-bit unsigned integer providing
providing a bandwidth amount in kbits/s. a bandwidth amount in kbits/s.
o The Target TLV identifies the access line to which this amount of o Target TLV: identifies the access line to which this amount of
multicast bandwidth is currently committed. multicast bandwidth is currently committed.
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 multicast replication (capability type 3);
o committed multicast bandwidth reporting (capability type 5); o committed bandwidth reporting (capability type 5);
o conditional access and admission control with white and black o conditional access and admission control with white and black
lists (capability type 6); lists (capability type 6);
o conditional access and admission control with grey lists o conditional access and admission control with grey lists
(capability type 7); (capability type 7); and
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
procedures that apply to each capability on its own. Section 6.3 procedures that apply to each capability on its own. Section 6.3
specifies how the capabilities interact if more than one multicast specifies how the capabilities interact if more than one multicast
capability is included in the set of capabilities negotiated between capability is included in the set of capabilities negotiated between
the AN and the NAS. the AN and the NAS.
6.1. Required Protocol Support 6.1. Required Protocol Support
This section specifies the protocol elements that MUST be implemented This section specifies the protocol elements that MUST be implemented
to support each of the four multicast capabilities. Support of to support each of the five multicast capabilities. Support of
multiple multicast capabilities requires implementation of the union multiple multicast capabilities requires implementation of the union
of the sets of protocol elements applying to each of the individual of the sets of protocol elements applying to each of the individual
capabilities in the supported set. capabilities in the supported set.
In addition to the elements listed below, implementation of the In addition to the elements listed below, implementation of the
Target TLV (Section 4.3 of [RFC6320]) is REQUIRED for all of the Target TLV (Section 4.3 of [RFC6320]) is REQUIRED for all of the
capabilities specified in this document. capabilities specified in this document.
6.1.1. Protocol Requirements For NAS-Initiated Replication 6.1.1. Protocol Requirements for NAS-Initiated Multicast Replication
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 multicast replication 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 | | Section 4.9 | Multicast Flow Query Request and Response messages |
| | 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 Multicast
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 | | Section 4.9 | Multicast Flow Query Request and Response messages |
| | 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 and Admission 6.1.3. Protocol Requirements for Conditional Access and Admission
Control With White and 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
and admission control with white and black lists multicast and admission control with white and black lists multicast
capability. 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 | | Section 4.9 | Multicast Flow Query Request and Response messages |
| | 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 and Admission Table 3: Protocol Requirements for Conditional Access and Admission
Control with White and Black Lists Control with White and Black Lists
6.1.4. Protocol Requirements For Conditional Access and Admission 6.1.4. Protocol Requirements for Conditional Access and Admission
Control With Grey Lists 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
and admission control with grey lists multicast capability. and admission control with grey lists multicast capability.
Additionally, implementation of the Multicast Replication Control Additionally, implementation of the Multicast Replication Control
message requires implementation of the Command TLV (Section 4.4 of message requires implementation of the Command TLV (Section 4.4 of
[RFC6320] with additional details 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 | | Section 4.9 | Multicast Flow Query Request and Response messages |
| | 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 and Admission Table 4: Protocol Requirements for Conditional Access and Admission
Control with Grey Lists Control with Grey Lists
6.1.5. Protocol Requirements For Delegated Bandwidth 6.1.5. Protocol Requirements for Bandwidth Delegation
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 bandwidth
multicast capability. delegation 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 | | Section 4.9 | Multicast Flow Query Request and Response messages |
| | 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 Bandwidth Delegation
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.
The use of the Multicast Flow Query Request and Response messages to The use of the Multicast Flow Query Request and Response messages to
determine the association between multicast flows and ports is common determine the association between multicast flows and ports is common
to all multicast capabilities. No additional text is required here, to all multicast capabilities. No additional text is required here,
beyond that already given in Section 4.9 to describe the use of those beyond that already given in Section 4.9 to describe the use of those
messages. messages.
6.2.1. Procedures For NAS-Initiated Replication 6.2.1. Procedures for NAS-Initiated Multicast Replication
NAS-initiated replication may be negotiated to support a mode of NAS-initiated multicast replication may be negotiated to support a
operation where IGMP/MLD requests are terminated on the NAS. mode of 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 signaling)
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 admission control for NAS-initiated replication. The NAS MAY perform admission control for NAS-initiated replication.
In this case, it MUST NOT include the MRepCtl-CAC TLV in a In this case, it MUST NOT include the MRepCtl-CAC TLV in a
Provisioning message sent to the AN. Alternatively, the NAS MAY Provisioning message sent to the AN. Alternatively, the NAS MAY
enable admission control at the AN for NAS-initiated replication. To enable admission control at the AN for NAS-initiated multicast
do this, it MUST include the MRepCtl-CAC TLV in a Provisioning replication. To do this, it MUST include the MRepCtl-CAC TLV in a
message sent to the AN and it MUST also include a Bandwidth- Provisioning message sent to the AN, and it MUST also include a
Allocation TLV in a Port Management message for each access line. Bandwidth-Allocation TLV in a Port Management 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 multicast replication
straightforward. To initiate replication, the NAS MUST send a are 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
Section 4.3.2. Section 4.3.2.
6.2.2. Procedures For Committed Bandwidth Reporting 6.2.2. Procedures for Committed Bandwidth Reporting
Committed bandwidth reporting may be negotiated if the NAS requires Committed bandwidth reporting may be negotiated if the NAS requires
current knowledge of the amount of multicast bandwidth committed to current knowledge of the amount of multicast bandwidth committed to
each access line and cannot obtain this information by other means. each access line and cannot obtain this information by other means.
6.2.2.1. Provisioning 6.2.2.1. Provisioning
The default buffering time when committed bandwidth reporting is The default buffering time when committed bandwidth reporting is
enabled is zero (immediate reporting). To change this, the NAS MAY enabled is zero (immediate reporting). To change this, the NAS MAY
send an instance of the Report-Buffering-Time TLV containing a non- send an instance of the Report-Buffering-Time TLV containing a non-
skipping to change at page 58, line 49 skipping to change at page 59, line 13
in another Provisioning message. in another Provisioning message.
6.2.2.2. Multicast Service Procedures 6.2.2.2. Multicast Service Procedures
If the buffering time for committed bandwidth reporting is zero, the If the buffering time for committed bandwidth reporting is zero, the
AN MUST send a Committed Bandwidth Report message to the NAS each AN MUST send a Committed Bandwidth Report message to the NAS each
time the amount of multicast bandwidth committed to any access line time the amount of multicast bandwidth committed to any access line
under its control changes. under its control changes.
If a non-zero value is provided in the Report-Buffering-Time TLV, the If a non-zero value is provided in the Report-Buffering-Time TLV, the
AN at any given moment is in one of two states: not-buffering, or AN is in one of two states at any given moment: not-buffering or
buffering. The AN enters buffering state if it is in not-buffering buffering. The AN enters buffering state if it is in not-buffering
state and the multicast bandwidth amount committed to some access state and the multicast bandwidth amount committed to some access
line changes. It leaves buffering state when the AN sends a line changes. It leaves buffering state when the AN sends a
Committed Bandwidth Report. Committed Bandwidth Report message.
Upon entry to the buffering state, the AN MUST start a buffering Upon entry to the buffering state, the AN MUST start a buffering
timer and create a Committed Bandwidth Report message containing a timer and create a Committed Bandwidth Report message containing a
Committed-Bandwidth TLV for the triggering access line, but MUST NOT Committed-Bandwidth TLV for the triggering access line, but it MUST
send it. If a multicast bandwidth change occurs for another access NOT send it. If a multicast bandwidth change occurs for another
line, the AN MUST add a new Committed-Bandwidth TLV to the message access line, the AN MUST add a new Committed-Bandwidth TLV to the
for that additional line. If a multicast bandwidth change occurs for message for that additional line. If a multicast bandwidth change
a line for which a Committed-Bandwidth TLV is already present in the occurs for a line for which a Committed-Bandwidth TLV is already
buffered report, the AN MUST update the corresponding Committed- present in the buffered report, the AN MUST update the corresponding
Bandwidth TLV to contain the new bandwidth value, rather than adding Committed-Bandwidth TLV to contain the new bandwidth value rather
another Committed-Bandwidth TLV for the same access line. than adding 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 Note: Report buffering implies that NAS reaction to changes in
bandwidth usage is delayed by the amount of the buffering period. multicast bandwidth usage is delayed by the amount of the
The choice of buffering period must take this into consideration. buffering period. The choice of buffering period must take this
into consideration.
6.2.3. Procedures For Conditional Access and Admission Control With 6.2.3. Procedures for Conditional Access and Admission Control with
Black and White Lists 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 admission control at the AN for white- The NAS MAY choose to enable admission control at the AN for white-
listed flows. To do this, it MUST send a Provisioning message as listed flows. To do this, it MUST send a Provisioning message as
described in Section 4.1, which includes the White-List-CAC TLV and described in Section 4.1, which includes the White-List-CAC TLV, and
it MUST provide a multicast bandwidth allocation for each access line it MUST provide a multicast bandwidth allocation for each access line
by including a Bandwidth-Allocation TLV in a Port Management message. by including a Bandwidth-Allocation TLV in a Port 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 and admission control with white and black
that IGMP/MLD requests are terminated on the AN. When the AN lists capability assumes that IGMP/MLD requests are terminated on the
receives a "join" request, it MUST check to see whether the requested AN. When the AN receives a join request, it MUST check to see
flow is white-listed or black-listed as described below. Requests whether the requested flow is white-listed or black-listed as
for black-listed flows MUST be discarded. If the NAS has enabled described below. Requests for black-listed flows MUST be discarded.
admission control on the AN as described in the previous section, but If the NAS has enabled admission control on the AN as described in
a white-listed flow would cause the amount of committed multicast the previous section, but a white-listed flow would cause the amount
bandwidth to exceed the provisioned limit, the request MUST be of committed multicast bandwidth to exceed the provisioned limit, the
discarded. The AN replicates flows passing these checks to the request MUST be discarded. The AN replicates flows passing these
access line. checks to the 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
context, the most specific match is defined as: context, the most specific match is defined as:
o first, most specific match (longest prefix length) on the o first, most specific match (longest prefix length) on the
multicast group address (i.e., on G of <S,G>) multicast group address (i.e., on G of <S,G>), and
o then, most specific match (longest prefix length) on the unicast o then, most specific match (longest prefix length) on the unicast
source address (i.e. on S of <S,G>) source address (i.e., on S of <S,G>).
If the requested multicast flow is not part of any list, the join If the requested multicast flow is not part of any list, the join
message SHOULD be discarded by the AN. This default behavior can message SHOULD be discarded by the AN. This default behavior can
easily be changed by means of a "catch-all" statement in the white easily be changed by means of a "catch-all" statement in the white
list. For instance, adding (<S=*,G=*>) in the white List would make list. For instance, adding (<S=*,G=*>) in the white List would make
the default behavior to accept join messages for a multicast flow the default behavior to accept join messages for a multicast flow
that has no other match on any list. that has no other match on any list.
When the AN receives a "leave" request, it terminates replication of When the AN receives a leave request, it terminates replication of
the multicast flow. the multicast flow.
If the AN receives a Provisioning message which updates an existing If the AN receives a Provisioning message that 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 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 and Admission Control With 6.2.4. Procedures for Conditional Access and Admission Control with
Grey Lists 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.
skipping to change at page 61, line 41 skipping to change at page 62, line 9
message sent to the AN. Alternatively, the NAS MAY enable admission message sent to the AN. Alternatively, the NAS MAY enable admission
control at the AN for grey-listed flows. To do this, it MUST include control at the AN for grey-listed flows. To do this, it MUST include
the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST
also provide a Bandwidth-Allocation TLV in a Port Management message also provide a Bandwidth-Allocation TLV in a Port Management message
for each access line. for each access line.
6.2.4.2. Multicast Service Procedures 6.2.4.2. Multicast Service Procedures
The conditional access and admission control with grey lists The conditional access and admission control with grey lists
capability assumes that IGMP/MLD requests are terminated on the AN. capability assumes that IGMP/MLD requests are terminated on the AN.
When the AN receives a "join" request, it MUST determine whether When the AN receives a join request, it MUST determine whether there
there is a match to the requested flow in the grey list of the is a match to the requested flow in the grey list of the multicast
multicast service profile provisioned against the given access line. service profile provisioned against the given access line. If there
If there is no match, the request is discarded. Otherwise, the AN is no match, the request is discarded. Otherwise, the AN MUST send a
MUST send a Multicast Admission Control message to the NAS with Multicast Admission Control message to the NAS with content
content identifying the access line and the multicast flow to be identifying the access line and the multicast flow to be added. As
added. As indicated in Section 4.4, the AN MAY add information indicated in Section 4.4, the AN MAY add information identifying the
identifying the requesting device. 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 message 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 message, it
performs admission control if that has been enabled as described in performs admission control if that has been enabled as described in
the previous section. If admitting the flow would cause the the previous section. If admitting the flow would cause 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 that 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 the AN receives a Port Management message that assigns Similarly, if the AN receives a Port Management message that assigns
a new profile to a given port, the AN MUST review all active flows on a new profile to a given port, the AN MUST review all active flows on
that port. In either case, if any flow does not match an entry in that port. In either case, if any flow does not match an entry in
the grey list, it MUST be terminated immediately. the grey list, it MUST be terminated immediately.
6.2.5. Procedures For Delegated Bandwidth 6.2.5. Procedures for Bandwidth Delegation
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 Note: If it fails to do so and a value has not been provisioned on
AN by other means, the AN will be forced to request a bandwidth the AN by other means, the AN will be forced to request a
allocation as soon as it receives a "join" request. bandwidth allocation as soon as it receives a join request.
The NAS MAY at any time force an update of the amount of delegated The NAS MAY, at any time, force an update of the amount of delegated
bandwidth by the same means. bandwidth by the same means.
6.2.5.2. Multicast Service Procedures 6.2.5.2. Multicast Service Procedures
The delegated bandwidth capability assumes that IGMP/MLD requests are The bandwidth delegation capability assumes that IGMP/MLD requests
terminated on the AN. When the AN receives a "join" request, it are terminated on the AN. When the AN receives a join request, it
checks whether it has sufficient remaining uncommitted multicast checks whether it has sufficient remaining uncommitted multicast
bandwidth on the access line to accommodate the new multicast flow. bandwidth on the access line to accommodate the new multicast flow.
If not, it MAY send a request to the NAS for an increased allocation If not, it MAY send a request to the NAS for an increased allocation
of delegated bandwidth, using the Bandwidth Reallocation Request of delegated bandwidth using the Bandwidth Reallocation Request
message. The NAS MUST return a Bandwidth Transfer message indicating message. The NAS MUST return a Bandwidth Transfer message indicating
whether it has granted the request, and if so, what is the new amount whether it has granted the request and, if so, the new amount of
of delegated bandwidth. delegated bandwidth.
If the AN has sufficient uncommitted multicast capacity to admit the If the AN has sufficient uncommitted multicast capacity to admit the
request, either originally or as the result of a successful request request, either originally or as the result of a successful request
to the NAS, it replicates the requested flow to the access line. to the NAS, it replicates the requested flow to the access line.
Otherwise it discards the request. Otherwise, it discards the request.
When the AN receives a "leave" request for an active flow, it ceases When the AN receives a leave request for an active flow, it ceases
replication. replication.
The NAS or AN MAY at some point detect that their respective views of The NAS or AN MAY, at some point, detect that their respective views
the amount of delegated bandwidth are inconsistent. If so, they can of the amount of delegated bandwidth are inconsistent. If so, they
recover using procedures described in Section 4.5 and Section 4.6. can recover using procedures described in Sections 4.5 and 4.6. As a
As a further aid to synchronization, either the NAS or the AN MAY further aid to synchronization, either the NAS or the AN MAY from
from time to time check the peer's view of the amount of delegated 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
autonomous Bandwidth Transfer message. The contents of this message an autonomous Bandwidth Transfer message. The contents of this
are described in Section 4.6. message 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 and Admission Control With 6.3.1. Combination of Conditional Access and Admission Control with
White and Black Lists and Conditional Access and Admission White and Black Lists and Conditional Access and Admission
Control With Grey Lists Control with Grey Lists
If conditional access with white and black lists is combined with If conditional access and admission control with white and black
conditional access with grey lists, provisioning of the multicast lists is combined with conditional access and admission control with
service profiles is as described in Section 6.2.3.1 except that grey lists, provisioning of the multicast service profiles is as
multicast service profiles will also include grey lists. Admission described in Section 6.2.3.1 except that multicast service profiles
control is enabled independently on the AN for white lists by will also include grey lists. Admission control is enabled
including the White-List-CAC TLV in the Provisioning message and for independently on the AN for white lists by including the White-List-
grey lists by including the MRepCtl-CAC TLV in the Provisioning CAC TLV in the Provisioning message and for grey lists by including
message. The Bandwidth-Allocation TLV provisions an amount that the MRepCtl-CAC TLV in the Provisioning message. The Bandwidth-
applies to both white- and grey- listed flows if admission control is Allocation TLV provisions an amount that applies to both white- and
enabled for both. grey-listed flows if admission control is 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 among multiple lists as described in Section 6.2.3.2.
Section 6.2.3.2. However, if there are multiple matches of equal However, if there are multiple matches of equal precision, the order
precision, the order of priority is black list first, grey list of priority is black list first, grey list second, and white list
second, and white list last. last.
Once profile matching has been completed, processing of a "join" Once profile matching has been completed, processing of a join
request is as described in Section 6.2.3.2 for white or black listed request is as described in Section 6.2.3.2 for white- or black-listed
flows or Section 6.2.4.2 for grey listed flows. Requests that do not flows or Section 6.2.4.2 for grey-listed flows. Requests that do not
match any list SHOULD be discarded. match any list SHOULD be discarded.
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. If the flow was grey-listed, the AN of the flow to the access line. If the flow was grey-listed, the AN
MUST then send a Multicast Admission Control message to the NAS MUST then send a Multicast Admission Control message to the NAS
indicating the deletion. indicating the deletion.
If the AN receives a Provisioning message which updates an existing If the AN receives a Provisioning message that 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 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 any flow has its most specific match active flows on that port. If any flow has its most specific match
in a black list entry, it MUST be terminated immediately. If any of in a black list entry, it MUST be terminated immediately. If any of
the remaining flows do not match an entry in the white or grey list, the remaining flows do not match an entry in the white or grey list,
they MUST also be terminated immediately. Finally, if any remaining they MUST also be terminated immediately. Finally, if any remaining
flows were originally admitted because they were white-listed, but flows were originally admitted because they were white-listed but
after the change they are grey-listed, the AN MUST generate a after the change they are grey-listed, the AN MUST generate a
Multicast Flow Query response message autonomously as if it were Multicast Flow Query Response message autonomously as if it were
responding to a Multicast Flow Query request, listing all such flows. responding to a Multicast Flow Query Request message, listing all
These flows MUST be allowed to continue until the NAS or the such flows. These flows MUST be allowed to continue until the NAS or
subscriber terminates them. Flows with their most specific match in the subscriber terminates them. Flows with their most specific match
the white list MUST be allowed to continue. in the white list MUST be allowed to continue.
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 Identifier
to all zeroes. field MUST be set to all zeroes.
The procedures in the previous paragraphs imply that the AN has to Note: The procedures in the previous paragraphs imply that the AN
retain a memory of whether an admitted flow was white-listed or has to retain a memory of whether an admitted flow was white-
grey-listed at the time of its admission/readmission. listed or grey-listed at the time of its admission/readmission.
6.3.2. Combination of Conditional Access and Admission Control With 6.3.2. Combination of Conditional Access and Admission Control with
Delegated Bandwidth Bandwidth Delegation
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 Sections 6.2.3, 6.2.4, or
or Section 6.3.1 as applicable. Conditional access follows the rules 6.3.1 as applicable. Conditional access follows the rules given in
given in those sections in terms of matching flows against white and those sections in terms of matching flows against white and black
black and/or grey lists. When admission control is enabled at the and/or grey lists. When admission control is enabled at the AN, the
AN, the amount of bandwidth used by the AN is negotiable as described amount of bandwidth used by the AN is negotiable as described in
in Section 6.2.5.2. 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 multicast replication can coexist with the other
but some means must exist to prevent double replication of flows. capabilities, but some means must exist to prevent double replication
The simplest way to do this is to terminate all IGMP/MLD requests on of flows. The simplest way to do this is to terminate all IGMP/MLD
the AN, so that NAS-initiated replication is stimulated only by requests on the AN, so that NAS-initiated multicast replication is
signalling through other channels. Other arrangements are possible, stimulated only by signaling through other channels. Other
but need not be discussed here. arrangements are possible 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 multicast replication and the
multicast capabilities is in the area of admission control. other multicast capabilities is in the area of admission control.
Specifically, if the AN is to do admission control for flows added by Specifically, if the AN is to do admission control for flows added by
Multicast Replication Control messages, regardless of whether they Multicast Replication Control messages, regardless of whether they
are part of NAS-initiated replication or grey list multicast service are part of NAS-initiated replication or grey list multicast service
processing, the NAS includes the MRepCtl-CAC TLV in a Provisioning processing, the NAS includes the MRepCtl-CAC TLV in a Provisioning
message and the Bandwidth-Allocation TLV in a Port Management message and the Bandwidth-Allocation TLV in a Port Management
message. If instead the NAS will do admission control for flows message. If, instead, the NAS will do admission control for flows
added by Multicast Replication Control messages, regardless of added by Multicast Replication Control messages, regardless of
whether they are part of NAS-initiated replication or grey list whether they are part of NAS-initiated replication or grey list
multicast service processing, it does not send the MRepCtl-CAC TLV in multicast service processing, it does not send the MRepCtl-CAC TLV in
a Provisioning messages to the AN. The NAS can independently enable a Provisioning message to the AN. The NAS can independently enable
admission control for white flows on the AN by including the White- admission control for white flows on the AN by including the White-
List-CAC TLV in the Provisioning message. List-CAC TLV in the 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 other
other multicast capabilities have been negotiated. However, some multicast capabilities that 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 and admission control initiated replication and/or conditional access and admission control
with grey lists. with grey lists.
7. Miscellaneous Considerations 7. Miscellaneous Considerations
This section deals with two sets of considerations. "Report This section deals with two sets of considerations. "Report
Buffering Considerations" considers requirements for configuration in Buffering Considerations" considers requirements for configuration in
support of some of the Committed Bandwidth Reporting capability. support of some of the committed bandwidth reporting capability.
"Congestion Considerations" is a warning to implementors about the "Congestion Considerations" is a warning to implementors about the
possibility of control plane congestion, with suggestions for possibility of control-plane congestion, with suggestions for
mitigation. mitigation.
7.1. Report Buffering Considerations 7.1. Report Buffering Considerations
The Committed Bandwidth Reporting capability allows the provisioning The committed bandwidth reporting capability allows the provisioning
of a report buffering period to reduce the number of messages the AN of a report buffering period to reduce the number of messages the AN
passes to the NAS. An appropriate value for this period, if passes to the NAS. An appropriate value for this period, if
buffering is allowed at all, depends first on the effect of delay in buffering is allowed at all, depends first on the effect of delay in
reporting bandwidth changes, and secondly on the rate at which reporting bandwidth changes and secondly on the rate at which
bandwidth changes are expected to occur. bandwidth changes are expected to occur.
Let us assume in the first instance that a delay in adjusting Let us assume, in the first instance, that a delay in adjusting
hierarchical scheduling at the NAS causes additional bandwidth demand hierarchical scheduling at the NAS causes additional bandwidth demand
to be served momentarily on a best-effort basis, introducing the to be served momentarily on a best-effort basis, introducing the
possibility of jitter and, more crucially, packet loss. ITU-T possibility of jitter and, more crucially, packet loss. Appendix IV
Recommendation G.1080 [ITU-T_G.1080] Appendix IV indicates that the of ITU-T Recommendation G.1080 [ITU-T_G.1080] indicates that the
maximum tolerable duration of a loss episode is less than 16 ms. 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 This would more likely apply in the middle of a program rather than
when it was starting up, but at least gives an (extremely when it was starting up but at least gives an (extremely
conservative) order of magnitude for setting the buffering period. conservative) order of magnitude for setting the buffering period.
The next question is whether enough messaging is likely to be The next question is whether enough messaging is likely to be
generated that multiple bandwidth changes would be observed within generated that multiple bandwidth changes would be observed within
such an interval. Let us consider a reasonable example in a DSL such an interval. Let us consider a reasonable example in a DSL
environment, where during the busiest hour of the day subscribers environment, where during the busiest hour of the day subscribers
start watching at the rate of one programme per subscriber per hour. start watching at the rate of one program per subscriber per hour.
Typically, because of programme scheduling, the new channel requests
Typically, because of program scheduling, the new channel requests
might be concentrated within a three-minute period, giving an might be concentrated within a three-minute period, giving an
effective request rate of 1/(3 minutes * 60 seconds * 1000 ms/second) effective request rate of 1/(3 minutes * 60 seconds * 1000 ms/second)
* 16 ms = 0.00009 requests per buffering interval of 16 ms. With * 16 ms = 0.00009 requests per buffering interval of 16 ms. With
these figures, an AN serving 10,000 subscribers will report an these figures, an AN serving 10,000 subscribers will report an
average of 0.9 bandwidth changes per 16 ms buffering interval. It average of 0.9 bandwidth changes per 16 ms buffering interval. It
appears that buffering is worthwhile only for larger-scale appears that buffering is worthwhile only for larger-scale
deployments. deployments.
Note that simple replacement of one channel with another -- channel Note that simple replacement of one channel with another -- channel
surfing -- does not require reporting or adjustment at the NAS end. surfing -- does not require reporting or adjustment at the NAS end.
7.2. Congestion Considerations 7.2. Congestion Considerations
Implementors must beware of the possibility that a single channel- Implementors must beware of the possibility that a single channel-
surfing subscriber could generate enough control messaging to surfing subscriber could generate enough control messaging to
overload the AN or the messaging channel between the AN and the NAS. overload the AN or the messaging channel between the AN and the NAS.
The implementation problem is to strike the right balance between The implementation problem is to strike the right balance between
minimizing the processing of requests that have been overtaken by minimizing the processing of requests that have been overtaken by
subsequent events and meeting requirements for what is termed subsequent events and meeting requirements for what is termed
"channel zapping delay". Nominally such a requirement is to be found "channel zapping delay". Nominally, such a requirement is to be
in [ITU-T_G.1080] Section 8.1, but unfortunately no quantitative found in Section 8.1 of [ITU-T_G.1080], but unfortunately no
value was available at the time of publication of this document. quantitative value was available at the time of publication of this
Implementors will therefore have to base their work on discussions document. Implementors will therefore have to base their work on
with customers until standardized requirements do become available. discussions with customers until standardized requirements become
(It is possible that regional bodies or more specialized bodies have available. (It is possible that regional bodies or more specialized
overtaken the ITU-T in this regard.) bodies have overtaken the ITU-T in this regard.)
A typical strategy for minimizing the work associated with request A typical strategy for minimizing the work associated with request
processing includes deliberate buffering of Join requests for a short processing includes deliberate buffering of join requests for a short
period in case matching Release requests are detected, followed by period in case matching Release requests are detected, followed by
discard of both requests. More generally, processing of requests discard of both requests. More generally, processing of requests
from individual subscribers may be rate limited, and the global rate from individual subscribers may be rate limited, and the global rate
of messaging to the NAS can also be limited. If the AN gets of messaging to the NAS can also be limited. If the AN gets
overloaded, deliberate dropping of stale requests can be implemented, overloaded, deliberate dropping of stale requests can be implemented,
for some definition of "stale". for some definitions of "stale".
8. Security Considerations 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 ANCP as a means of denial of service (e.g., through direction of
direction of multicast streams onto the target) or theft of service. 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 TLV or Request-Source-IP TLV in the Multicast Admission Control
presents privacy issues. An attacker able to get access to the message presents privacy issues. An attacker able to get access to
contents of this message would, like the content provider, be able to the contents of this message would, like the content provider, be
track consumption of multicast content to the individual device and able to track consumption of multicast content to the individual
potentially to individual persons if they are associated with device and potentially to individual persons if they are associated
particular devices. To make the connection between devices and with 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
access are between the subscriber and the AN, at the AN and at the access are between the subscriber and the AN, at the AN and at the
NAS. Moreover, if the MAC or IP address are transmitted onwards from NAS. Moreover, if the MAC or IP address are transmitted onwards from
the NAS to AAA in a request for policy, that whole onward path has to the NAS to AAA in a request for policy, that whole onward path has to
be examined for vulnerability. be examined for vulnerability.
The question is how many of these potential points of attack can be The question is how many of these potential points of attack can be
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 the 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 [RFC6320]. 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 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] 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 mandates use of IPsec, TLS/TCP, or DTLS/SCTP for that purpose. If
RADIUS is used, the operator should deploy TLS transport as specified RADIUS is used, the operator should deploy TLS transport as specified
in [RFC6614]. 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 TLV or Request-Source-IP TLV.
9. IANA Considerations 9. IANA Considerations
IANA NOTE: Please replace XXXX with the RFC number of this document. This document defines the following additional values within the
"ANCP Message Types" registry:
This document defines the following additional values within the ANCP
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 7256 |
| | | | | | | |
| 145 | Multicast Admission Control | RFC XXXX | | 145 | Multicast Admission Control | RFC 7256 |
| | | | | | | |
| 146 | Bandwidth Reallocation Request | RFC XXXX | | 146 | Bandwidth Reallocation Request | RFC 7256 |
| | | | | | | |
| 147 | Bandwidth Transfer | RFC XXXX | | 147 | Bandwidth Transfer | RFC 7256 |
| | | | | | | |
| 148 | Delegated Bandwidth Query | RFC XXXX | | 148 | Delegated Bandwidth Query | RFC 7256 |
| | | | | | | |
| 149 | Multicast Flow Query | RFC XXXX | | 149 | Multicast Flow Query | RFC 7256 |
| | | | | | | |
| 150 | Committed Bandwidth Report | RFC XXXX | | 150 | Committed Bandwidth Report | RFC 7256 |
+--------------+--------------------------------+-----------+ +--------------+--------------------------------+-----------+
This document defines the following additional values for the ANCP This document defines the following additional values for the "ANCP
Result Code registry. In support of these assignments, IANA is Result Codes" registry. In support of these assignments, IANA has
requested to change the lower limit of 0x100 specified by [RFC6320] changed the lower limit of 0x100 specified by [RFC6320] for
for assignments by IETF Consensus to 0x64. assignments by IETF Consensus to 0x64.
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| Result | One-Line Description | Reference | | Result | One-Line Description | Reference |
| Code | | | | Code | | |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| 0x64 | Command error. | RFC XXXX | | 0x64 | Command error. | RFC 7256 |
| | | | | | | |
| 0x65 | Invalid flow address. | RFC XXXX | | 0x65 | Invalid flow address. | RFC 7256 |
| | | | | | | |
| 0x66 | Multicast flow does not exist. | RFC XXXX | | 0x66 | Multicast flow does not exist. | RFC 7256 |
| | | | | | | |
| 0x67 | Invalid preferred bandwidth amount. | RFC XXXX | | 0x67 | Invalid preferred bandwidth amount. | RFC 7256 |
| | | | | | | |
| 0x68 | Inconsistent views of delegated | RFC XXXX | | 0x68 | Inconsistent views of delegated | RFC 7256 |
| | bandwidth amount. | | | | bandwidth amount. | |
| | | | | | | |
| 0x69 | Bandwidth request conflict. | RFC XXXX | | 0x69 | Bandwidth request conflict. | RFC 7256 |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
This document defines the following additional values for the "ANCP
This document defines the following additional values for the ANCP Command Codes" registry:
Command Code registry:
+----------------+--------------------------------------+-----------+ +----------------+--------------------------------------+-----------+
| Command Code | Command Code Directive Name | Reference | | Command Code | Command Code Directive Name | Reference |
| Value | | | | Value | | |
+----------------+--------------------------------------+-----------+ +----------------+--------------------------------------+-----------+
| 1 | Add | RFC XXXX | | 1 | Add | RFC 7256 |
| | | | | | | |
| 2 | Delete | RFC XXXX | | 2 | Delete | RFC 7256 |
| | | | | | | |
| 3 | Delete All | RFC XXXX | | 3 | Delete All | RFC 7256 |
| | | | | | | |
| 4 | Admission Control Reject | RFC XXXX | | 4 | Admission Control Reject | RFC 7256 |
| | | | | | | |
| 5 | Conditional Access Reject | RFC XXXX | | 5 | Conditional Access Reject | RFC 7256 |
| | | | | | | |
| 6 | Admission Control and Conditional | RFC XXXX | | 6 | Admission Control and Conditional | RFC 7256 |
| | Access Reject | | | | Access Reject | |
+----------------+--------------------------------------+-----------+ +----------------+--------------------------------------+-----------+
This document defines the following additional values within the
This document defines the following additional values within the ANCP "ANCP TLV Types" registry:
TLV Type Registry:
+-----------+--------------------------------+-----------+ +-----------+--------------------------------+-----------+
| Type Code | TLV Name | Reference | | Type Code | TLV Name | Reference |
+-----------+--------------------------------+-----------+ +-----------+--------------------------------+-----------+
| 0x0013 | Multicast-Service-Profile | RFC XXXX | | 0x0013 | Multicast-Service-Profile | RFC 7256 |
| | | | | | | |
| 0x0015 | Bandwidth-Allocation | RFC XXXX | | 0x0015 | Bandwidth-Allocation | RFC 7256 |
| | | | | | | |
| 0x0016 | Bandwidth-Request | RFC XXXX | | 0x0016 | Bandwidth-Request | RFC 7256 |
| | | | | | | |
| 0x0018 | Multicast-Service-Profile-Name | RFC XXXX | | 0x0018 | Multicast-Service-Profile-Name | RFC 7256 |
| | | | | | | |
| 0x0019 | Multicast-Flow | RFC XXXX | | 0x0019 | Multicast-Flow | RFC 7256 |
| | | | | | | |
| 0x0021 | List-Action | RFC XXXX | | 0x0021 | List-Action | RFC 7256 |
| | | | | | | |
| 0x0022 | Sequence-Number | RFC XXXX | | 0x0022 | Sequence-Number | RFC 7256 |
| | | | | | | |
| 0x0024 | White-List-CAC | RFC XXXX | | 0x0024 | White-List-CAC | RFC 7256 |
| | | | | | | |
| 0x0025 | MRepCtl-CAC | RFC XXXX | | 0x0025 | MRepCtl-CAC | RFC 7256 |
| | | | | | | |
| 0x0092 | Request-Source-IP | RFC XXXX | | 0x0092 | Request-Source-IP | RFC 7256 |
| | | | | | | |
| 0x0093 | Request-Source-MAC | RFC XXXX | | 0x0093 | Request-Source-MAC | RFC 7256 |
| | | | | | | |
| 0x0094 | Report-Buffering-Time | RFC XXXX | | 0x0094 | Report-Buffering-Time | RFC 7256 |
| | | | | | | |
| 0x0095 | Committed-Bandwidth | RFC XXXX | | 0x0095 | Committed-Bandwidth | RFC 7256 |
| | | | | | | |
| 0x0096 | Request-Source-Device-Id | RFC XXXX | | 0x0096 | Request-Source-Device-Id | RFC 7256 |
+-----------+--------------------------------+-----------+ +-----------+--------------------------------+-----------+
This document defines the following additional values for the ANCP This document defines the following additional values for the "ANCP
Capability Type registry: Capability Types" registry:
+-------+-------------------------+--------+------------+-----------+ +-------+-------------------------+--------+------------+-----------+
| Value | Capability Type Name | Tech | Capability | Reference | | Value | Capability Type Name | Tech | Capability | Reference |
| | | Type | Data? | | | | | Type | Data? | |
+-------+-------------------------+--------+------------+-----------+ +-------+-------------------------+--------+------------+-----------+
| 3 | NAS-Initiated | 0 | No | RFC XXXX | | 3 | NAS-Initiated Multicast | 0 | No | RFC 7256 |
| | Replication | | | | | | Replication | | | |
| | | | | | | | | | | |
| 5 | Committed Bandwidth | 0 | No | RFC XXXX | | 5 | Committed Bandwidth | 0 | No | RFC 7256 |
| | Reporting | | | | | | Reporting | | | |
| | | | | | | | | | | |
| 6 | Conditional Access With | 0 | No | RFC XXXX | | 6 | Conditional Access and | 0 | No | RFC 7256 |
| | Admission Control with | | | |
| | White and Black Lists | | | | | | White and Black Lists | | | |
| | | | | | | | | | | |
| 7 | Conditional Access With | 0 | No | RFC XXXX | | 7 | Conditional Access and | 0 | No | RFC 7256 |
| | Admission Control with | | | |
| | Grey Lists | | | | | | Grey Lists | | | |
| | | | | | | | | | | |
| 8 | Bandwidth Delegation | 0 | No | RFC XXXX | | 8 | Bandwidth Delegation | 0 | No | RFC 7256 |
+-------+-------------------------+--------+------------+-----------+ +-------+-------------------------+--------+------------+-----------+
10. 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
that formed the base of the Multicast Flow Reporting solution. proposal that formed the base of the Multicast Flow Reporting
Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided solution. Philippe Champagne, Sanjay Wadhwa, and Stefaan De Cnodder
substantial contributions on the solution for the NAS initiated provided substantial contributions on the solution for the NAS-
multicast control use case. Kristian Poscic provided the committed initiated multicast control use case. Kristian Poscic provided the
bandwidth reporting use case. committed 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.
Further thanks to Dacheng Zhang, Mehmet Ersue, and Christer Holmberg Further thanks to Dacheng Zhang, Mehmet Ersue, and Christer Holmberg
for their reviews on behalf of the Security, Operations, and Gen-Art for their reviews on behalf of the Security, Operations, and Gen-Art
directorates. Dacheng's comments led to changes at several points in directorates. Dacheng's comments led to changes at several points in
the draft, while Mehmet's led to creation of the Miscellaneous the document, while Mehmet's led to creation of the Miscellaneous
Considerations section. Finally, thanks to Brian Haberman for Considerations section. Finally, thanks to Brian Haberman for
stimulating a review of the architectural assumptions and their stimulating a review of the architectural assumptions and their
relationship to the ability of user devices to obtain access to non- relationship to the ability of user devices to obtain access to non-
IPTV multicast services. This also led to changes in the draft. IPTV multicast services. This also led to changes in the document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[PIMreg] IANA, "http://www.iana.org/assignments/pim-parameters/pim- [PIMreg] IANA, "Protocol Independent Multicast (PIM) Parameters",
parameters.xhtml", 2005. <http://www.iana.org/assignments/pim-parameters>.
[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
skipping to change at page 73, line 37 skipping to change at page 73, line 37
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
February 2010. February 2010.
[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.
11.2. Informative References 11.2. Informative References
[IEEE48] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ [IEEE48] IEEE, "Guidelines for 48-Bit Global Identifier",
EUI48.html", 2010. <http://standards.ieee.org/regauth/oui/tutorials/
EUI48.html>.
[IEEE64] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ [IEEE64] IEEE, "Guidelines for 64-Bit Global Identifier",
EUI64.html", 2010. <http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html>.
[ITU-T_G.1080] [ITU-T_G.1080]
ITU-T, "ITU-T Recommendation G.1080: Quality of experience ITU-T, "Quality of experience requirements for IPTV
requirements for IPTV services", December 2008. services", ITU-T Recommendation G.1080, December 2008.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997. 2", RFC 2236, November 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. 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
skipping to change at page 74, line 26 skipping to change at page 75, line 10
RFC 6614, May 2012. RFC 6614, May 2012.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012. "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 in 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:
o The basic subscribed service is white-listed. The AN will be o The basic subscribed service is white-listed. The AN will be
responsible for admission control for this service. responsible for admission control for this service.
o Some premium services are available, but requests for these o Some premium services are available, but requests for these
services must be referred to the policy server for proper credit services must be referred to the Policy Server for proper credit
processing. For this reason they are grey-listed. The NAS will processing. For this reason, they are grey-listed. The NAS will
be responsible for admission control for these services. be responsible for admission control for these services.
o The subscriber has asked that certain services be blocked so that o The subscriber has asked that certain services be blocked so that
his children cannot view them. These services are black-listed. his children cannot view them. These services are black-listed.
o All of the above services are Source-Specific Multicast (SSM). In o All of the above services are Source-Specific Multicast (SSM). In
addition, by means which bypass the AN, the subscriber can signal addition, by means that bypass the AN, the subscriber can signal
intent to join an on-line game service which is Any Source intent to join an on-line game service that is Any-Source
Multicast (ASM). The NAS is responsible for admission control for Multicast (ASM). The NAS is responsible for admission control for
this service. this service.
o Bandwidth delegation is in effect to share video bandwidth between o Bandwidth delegation is, in effect, to share video bandwidth
the AN and the NAS. between the AN and the NAS.
The stated conditions require the use of four of the five The stated conditions require the use of four of the five
capabilities specified in this memo. capabilities specified in this memo.
A.1. Provisioning Phase A.1. Provisioning Phase
Assume that capability negotiation has been completed between the AN Assume that capability negotiation has been completed between the AN
and NAS and that the set of negotiated capabilities includes the and NAS and that the set of negotiated capabilities includes the
following four multicast capabilities: NAS-initiated replication, following four multicast capabilities: NAS-initiated multicast
conditional access with white and black list, conditional access with replication, conditional access and admission control with white and
grey list, and bandwidth delegation. At this point, the NAS can black lists, conditional access and admission control with grey
lists, and bandwidth delegation. At this point, the NAS can
provision the service profiles on the AN and enable admission control provision the service profiles on the AN and enable admission control
at the AN for white-listed flows. To do this, the NAS sends the AN a at the AN for white-listed flows. To do this, the NAS sends the AN a
Provisioning message containing this information. An example message Provisioning message containing this information. An example message
providing the profile for our assumed subscriber is shown in providing the profile for our assumed subscriber is shown in
Figure 21. The message has the following contents: Figure 22. The message has the following contents:
o Message type is 93. o Message Type is 93.
o The Result and Result Code fields in the header are set to zeroes, o The Result and Result Code fields in the header are set to zeroes,
as specified [RFC6320]. as specified [RFC6320].
o A transaction identifier is assigned by the NAS. o A Transaction Identifier is assigned by the NAS.
o The Multicast-Service-Profile TLV (of which typically there would o The Multicast-Service-Profile TLV (of which typically there would
be multiple instances) contains a Multicast-Service-Profile-Name be multiple instances) contains a Multicast-Service-Profile-Name
TLV (with a length of 20 octets assumed for the example) and three TLV (with a length of 20 octets assumed for the example) and three
List-Action TLVs, one each for the white, grey, and black lists List-Action TLVs, one each for the white, grey, and black lists
within the profile. The white list flows come in two sets of within the profile. The white list flows come in two sets of
group addresses: 233.252.0.0/29, coming from a server at group addresses: 233.252.0.0/29, coming from a server at
192.0.2.15, and 233.252.0.32/29, coming from a server at 192.0.2.15, and 233.252.0.32/29, coming from a server at
192.0.2.16. The grey-listed flows are in the band 233.252.0.64/ 192.0.2.16. The grey-listed flows are in the band
29, coming from a server at 192.0.2.21. Finally, the black list 233.252.0.64/29, coming from a server at 192.0.2.21. Finally, the
flows are two individual flows that happen to overlap with the black list flows are two individual flows that happen to overlap
grey list band: 233.252.0.65, and 233.252.0.69, also with source with the grey list band: 233.252.0.65 and 233.252.0.69, also with
192.0.2.21. source 192.0.2.21.
o The White-List-CAC TLV indicates that the AN does admission o The White-List-CAC TLV indicates that the AN does admission
control on white-listed flows. control on white-listed flows.
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 (0x880C) | Length = 132 | | Type (0x880C) | Length = 132 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 93 | Res=0 | Result Code = 0 | | Version | Msg Type = 93 | Res=0 | Result Code = 0 |
skipping to change at page 76, line 17 skipping to change at page 77, line 4
| Multicast service profile name | | Multicast service profile name |
~ = "Cust 0127-53681-0003" ~ ~ = "Cust 0127-53681-0003" ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 | | TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 1 | Reserved = 0x0000 | | Operation = 1 | List Type = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 20 | | Address Family = 1 | List Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G Preflen = 29| S Preflen = 32| Group prefix = | | G PrefLen = 29| S PrefLen = 32| Group prefix = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 233.252.0.0 | Source prefix = | | 233.252.0.0 | Source prefix = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.15 | G Preflen = 29| S Preflen = 32| | 192.0.2.15 | G PrefLen = 29| S PrefLen = 32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group prefix = 233.252.0.32 | | Group prefix = 233.252.0.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source prefix = 192.0.2.15 | | Source prefix = 192.0.2.16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 18 | | TLV Type = List-Action 0x0021 | Embedded TLV Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 3 | Reserved = 0x0000 | | Operation = 1 | List Type = 3 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 10 | | Address Family = 1 | List Length = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G Preflen = 29| S Preflen = 32| Group prefix = / | G PrefLen = 29| S PrefLen = 32| Group prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 233.252.0.64 | Source prefix = / / 233.252.0.64 | Source prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 192.0.2.21 | Padding = 0x0000 | / 192.0.2.21 | Padding = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 | | TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 2 | Reserved = 0x0000 | | Operation = 1 | List Type = 2 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 20 | | Address Family = 1 | List Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G Preflen = 32| S Preflen = 32| Group prefix = / | G PrefLen = 32| S PrefLen = 32| Group prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 233.252.0.65 | Source prefix = / / 233.252.0.65 | Source prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 192.0.2.21 | G Preflen = 32| S Preflen = 32| / 192.0.2.21 | G PrefLen = 32| S PrefLen = 32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group prefix = 233.252.0.69 | | Group prefix = 233.252.0.69 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source prefix = 192.0.2.21 | | Source prefix = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = White-List-CAC 0x0024 | TLV Length = 0 | | Type = White-List-CAC 0x0024 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Example Provisioning Message Figure 22: 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 the 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 admission control for grey MRepCtl-CAC TLV since in our example admission control for grey-
listed flows and for NAS-initiated replication is performed by the listed flows and for NAS-initiated replication is performed 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 23.
+----------+ +---------+ +-----+ +-----+ +----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS | |Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+ +----------+ | Gateway | +-----+ +-----+
| +---------+ | | | +---------+ | |
| | | | | | | |
| | | | | | | |
| | DSL Synch. | | | | DSL Synch. | |
| |---------------->| | | |---------------->| |
| | |(M1)PORT_UP(Port ID) | | | |(M1)PORT_UP(Port ID) |
| | |-------------------->| | | |-------------------->|
| | | (*) | | | (*)
| | |(M2) PORT_MNGT | | | |(M2) PORT_MNGT |
| | | (Port ID, | | | | (Port ID, |
| | |Mcast S Profile Name,| | | |Mcast S Profile Name,|
| | |Bandwidth Allocation)| | | |Bandwidth Allocation)|
| | |<--------------------| | | |<--------------------|
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Autorization/Policy Server Authorization/Policy Server
Figure 22: Configuring an AN Port With Multicast Service Profile ID Figure 23: Configuring an AN Port with Multicast Service Profile ID
and Delegated Bandwidth Amount and Delegated Bandwidth Amount
The Port Management message will typically contain other TLVs but our The Port Management message will typically contain other TLVs, but
example (Figure 23) just shows the Target, Multicast-Service-Profile- our example (Figure 24) just shows the Target, Multicast-Service-
Name, and Bandwidth-Allocation TLVs. The Target TLV identifies the Profile-Name, and Bandwidth-Allocation TLVs. The Target TLV
subscriber line, the Multicast-Service-Profile-Name TLV is identical identifies the subscriber line, the Multicast-Service-Profile-Name
to the one contained in the Provisioning message, and the Bandwidth- TLV is identical to the one contained in the Provisioning message,
Allocation TLV provides just enough bandwidth (2000 kbits/s) for one and the Bandwidth-Allocation TLV provides just enough bandwidth (2000
channel to start with. kbits/s) for one channel to start with.
The following fields in the Port Management message header are shown The following fields in the Port Management message header are shown
with specific values either as directed by the base protocol document with specific values either as directed by the base protocol document
or for the sake of our example: or for the sake of our example:
o Message Type is 32. o Message Type is 32.
o Result is set to Nack (0x1) for this example. o Result is set to Nack (0x1) for this example.
o Result Code is 0. o Result Code is 0.
o A transaction identifier is assigned by the NAS. o A Transaction Identifier is assigned by the NAS.
o Port is set to 0. o Port is set to 0.
o Event Sequence Number, the R flag and the other bits marked x, o Event Sequence Number, the R flag and the other bits marked x,
Duration, the Event Flags, and the Flow Control Flags are all Duration, the Event Flags, and the Flow Control Flags are all
irrelevant for this function and are set to 0. irrelevant for this function and are set to 0.
o Function is set to "Configure Connection Service Data" (8). o Function is set to "Configure Connection Service Data" (8).
o X-Function is set to 0. o X-Function is set to 0.
skipping to change at page 80, line 47 skipping to change at page 80, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile name | | Multicast service profile name |
~ = "Cust 0127-53681-0003" ~ ~ = "Cust 0127-53681-0003" ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 | | Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth value = 2000 (kbits/s) | | Bandwidth value = 2000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Example Port Management Message Figure 24: Example Port Management Message
A.2. Handling a Grey-Listed Flow A.2. Handling Grey-Listed Flows
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 25 illustrates the resulting ANCP message flow for the
case of a simple join and leave, when admission control for grey- case of a simple join and leave, when admission 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 message
(M1) to the NAS. The NAS decides whether flow can be admitted, (M1) to the NAS. The NAS decides whether the 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 |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | Multicast | | | | Multicast |
skipping to change at page 81, line 44 skipping to change at page 81, line 44
| Mcast Grey Flow |<------------------| | Mcast Grey Flow |<------------------|
|<======================+ | |<======================+ |
| | | | | | | |
~ ~ ~ ~ ~ ~ ~ ~
| | | Multicast | | | | Multicast |
| Leave(Grey-Fl) | Admission | | Leave(Grey-Fl) | Admission |
|-----------+---------->| Control (M3) | |-----------+---------->| Control (M3) |
| | |------------------>| | | |------------------>|
| | | | | | | |
Grey-Fl : Multicast Flow matching an entry in grey List Grey-Fl: multicast flow matching an entry in grey list
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Authorization/Policy Server Authorization/Policy Server.
Figure 24: Successful Join/Leave Operations, Grey-Listed Flow Figure 25: Successful Join/Leave Operations, Grey-Listed Flow
The Multicast Admission Control message M1 contains: The Multicast Admission Control message M1 contains:
o an ANCP Header with: o an ANCP Header with:
* Message Type is 145; * Message Type is 145;
* Result = Ignore (0x0); * Result = Ignore (0x0); and
* a transaction identifier assigned by the AN. * a Transaction Identifier assigned by the AN.
o a Target TLV identifying the AN Port o a Target TLV identifying the AN Port
o a Command TLV containing: o a Command TLV containing:
* Command Code = "Add" (1); * Command Code = "Add" (1);
* Accounting = "No" (0); * Accounting = "No" (0);
* a Multicast-Flow embedded TLV indicating the multicast flow for * a Multicast-Flow embedded TLV indicating the multicast flow for
which the AN received the IGMP Join: flow type "SSM" (2), which the AN received the IGMP join: flow type "SSM" (2),
address family "IPv4" (1), Group address = 233.252.0.67, Source address family "IPv4" (1), Group address = 233.252.0.67, Source
Address = 192.0.2.21; Address = 192.0.2.21; and
* a Request-Source-Device-Id embedded TLV containing the IGMP * a Request-Source-Device-Id embedded TLV containing the IGMP
join source local device identifier value 5. join source local device identifier value 5.
The Multicast Admission Control message M1 is illustrated in The Multicast Admission Control message M1 is illustrated in
Figure 25: Figure 26:
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 (0x880C) | Length = 98 | | Type (0x880C) | Length = 98 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=145 | Res=0 | Result Code = 0 | | Version | Msg Type=145 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 83, line 39 skipping to change at page 83, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 | | Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 | | Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Request-Source-Device-Id 0x0092| Embedded TLV length = 4 | |Request-Source-Device-Id 0x0092| Embedded TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = 5 | | Value = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Multicast Admission Control Message Seeking To Add A Flow Figure 26: Multicast Admission Control Message Seeking to Add a Flow
The Multicast Replication Control message M2 contains: The Multicast Replication Control message M2 contains:
o an ANCP Header with: o an ANCP Header with:
* Message Type = "Multicast Replication Control" (144); * Message Type = "Multicast Replication Control" (144);
* Result= 0x1 (NAck); * Result= 0x1 (Nack); and
* a transaction identifier assigned by the NAS; * a Transaction Identifier assigned by the NAS;
o a Target TLV identifying the AN Port
o a Target TLV identifying the AN Port;
o a Command TLV containing: o a Command TLV containing:
* Command Code = "Add" (1); * Command Code = "Add" (1);
* Accounting = "Yes" (1), since in our example the operator wants * Accounting = "Yes" (1), since in our example the operator wants
accounting on this flow. accounting on this flow; and
* a Multicast-Flow embedded TLV indicating the multicast flow * a Multicast-Flow embedded TLV indicating the multicast flow
that the NAS is admitting for this access line: flow type "SSM" that the NAS is admitting for this access line: flow type "SSM"
(2), address family "IPv4" (1), Group address = 233.252.0.67, (2), address family "IPv4" (1), Group address = 233.252.0.67,
Source Address = 192.0.2.21. Source Address = 192.0.2.21.
The Multicast Admission Control message M2 is illustrated in The Multicast Admission Control message M2 is illustrated in
Figure 26. Figure 27.
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 (0x880C) | Length = 48 | | Type (0x880C) | Length = 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=144 | Res=1 | Result Code = 0 | | Version | Msg Type=144 | Res=1 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 84, line 49 skipping to change at page 84, line 52
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.67 | | Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 | | Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Multicast Replication Control Message Admitting A Flow Figure 27: Multicast Replication Control Message Admitting a Flow
The Multicast Admission Control message M3 advising the NAS that the The Multicast Admission Control message M3 advising the NAS that the
flow has been terminated contains: flow has been terminated contains:
o an ANCP Header with: o an ANCP Header with:
* Message Type is 145; * Message Type is 145;
* Result = Ignore (0x0) * Result = Ignore (0x0); and
* a transaction identifier assigned by the AN; * a Transaction Identifier assigned by the AN.
o a Target TLV identifying the access line; o a Target TLV identifying the access line
o a Command TLV containing: o a Command TLV containing:
* a Command Code = "Delete" (2); * a Command Code = "Delete" (2);
* Accounting = "No" (0); * Accounting = "No" (0);
* a Multicast-Flow embedded TLV indicating the multicast flow for * a Multicast-Flow embedded TLV indicating the multicast flow for
which the AN received the IGMP leave: flow type "SSM" (2), which the AN received the IGMP leave: flow type "SSM" (2),
address family "IPv4" (1), Group address = 233.252.0.67, Source address family "IPv4" (1), Group address = 233.252.0.67, Source
Address = 192.0.2.21. Address = 192.0.2.21; and
* a Request-Source-Device-Id embedded TLV containing the IGMP * a Request-Source-Device-Id embedded TLV containing the IGMP
leave request source, the device identified by the local value leave request source, the device identified by the local value
5. 5.
The Multicast Admission Control message M3 is illustrated in The Multicast Admission Control message M3 is illustrated in
Figure 27. Figure 28.
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 (0x880C) | Length | | Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=145 | Res=0 | Result Code = 0 | | Version | Msg Type=145 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 86, line 39 skipping to change at page 86, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 | | Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 | | Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Request-Source-Device-Id 0x0092| Embedded TLV length = 4 | |Request-Source-Device-Id 0x0092| Embedded TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = 5 | | Value = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Multicast Admission Control Message Signalling Flow Figure 28: Multicast Admission Control Message Signaling Flow
Termination Termination
A.3. Handling White-Listed Flows A.3. Handling White-Listed Flows
The NAS has enabled white list admission control on the AN, and the The NAS has enabled white list admission control on the AN, and the
bandwidth delegation capability has been negotiated. White listed bandwidth delegation capability has been negotiated. White-listed
flows in themselves require no messages to the NAS, either upon flows in themselves require no messages to the NAS, either upon
admission or upon termination, but the AN may request an increase in admission or upon termination, but the AN may request an increase in
the amount of delegated bandwidth if it needs the increase to admit a the amount of delegated bandwidth if it needs the increase to admit a
flow. flow.
Consider an example where the AN has already admitted one white- Consider an example where the AN has already admitted one white-
listed flow, thereby using up the initially provisioned amount of listed flow, thereby using up the initially provisioned amount of
delegated bandwidth (2000 kbits/s). A request is received to join a delegated bandwidth (2000 kbits/s). A request is received to join a
new flow in the white list range. The AN chooses to send a Bandwidth new flow in the white list range. The AN chooses to send a Bandwidth
Reallocation Request message to the NAS, requesting that the Reallocation Request message to the NAS, requesting that the
delegated bandwidth allocation be increased to 4000 kbits/s at a delegated bandwidth allocation be increased to 4000 kbits/s at a
minimum, and preferably to 6000 kbits/s. minimum and preferably to 6000 kbits/s.
In our example, the NAS is managing bandwidth tightly, as witnessed In our example, the NAS is managing bandwidth tightly, as witnessed
by its minimal initial allocation of just enough for one flow. It is by its minimal initial allocation of just enough for one flow. It is
willing to provide the minimum additional amount only, and therefore willing to provide the minimum additional amount only and therefore
returns a Bandwidth Transfer message where the delegated bandwidth returns a Bandwidth Transfer message where the delegated bandwidth
value is given as 4000 kbits/s. With this amount, the AN is able to value is given as 4000 kbits/s. With this amount, the AN is able to
admit the second white-listed flow. The AN could send a similar admit the second white-listed flow. The AN could send a similar
Bandwidth Transfer message back to the NAS bringing the delegated Bandwidth Transfer message back to the NAS bringing the delegated
bandwidth amount back down to 2000 kbits/s when one of the flows is bandwidth amount back down to 2000 kbits/s when one of the flows is
terminated, but this shows nothing new and is omitted. terminated, but this shows nothing new and is omitted.
As one more point of illustration, suppose that the NAS chooses to As one more point of illustration, suppose that the NAS chooses to
audit the current amount of delegated bandwidth to ensure it is audit the current amount of delegated bandwidth to ensure it is
synchronized with the AN. It sends a Delegated Bandwidth Query synchronized with the AN. It sends a Delegated Bandwidth Query
request message to the AN, and receives a Delegated Bandwidth Query Request message to the AN and receives a Delegated Bandwidth Query
response message with the current allocation as the AN sees it. Response message with the current allocation as the AN sees it.
The complete message flow is shown in Figure 28. The complete message flow is shown in Figure 29.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS | |Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | | | | | |
| Join(White-F1) | | | Join(White-F1) | |
|-----------+---------->| | |-----------+---------->| |
| | |AN performs | | | |AN performs |
| Mcast White Flow 1 | admission control | | Mcast White Flow 1 | admission control |
skipping to change at page 88, line 41 skipping to change at page 88, line 41
| | |Delegated Bandwidth| | | |Delegated Bandwidth|
| | | Query request | | | | Query request |
| | |<------------------|(M3) | | |<------------------|(M3)
| | | | | | | |
| | |Delegated Bandwidth| | | |Delegated Bandwidth|
| | | Query response | | | | Query response |
| | |------------------>|(M4) | | |------------------>|(M4)
| | | | | | | |
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Authorization/Policy Server Authorization/Policy Server.
Figure 28: Successful Join/Leave Operations, White-Listed Flow Figure 29: Successful Join/Leave Operations, White-Listed Flow
The Bandwidth Reallocation Request message (M1) is shown in The Bandwidth Reallocation Request message (M1) is shown in
Figure 29. The contents require little explanation. The Message Figure 30. The contents require little explanation. The Message
Type for the Bandwidth Reallocation Request is 146. The Result field Type for the Bandwidth Reallocation Request is 146. The Result field
is set to Ignore (0x0). Besides the Target, the message has one is set to Ignore (0x0). Besides the Target TLV, the message has one
other TLV, the Bandwidth-Request, with a TLV Type of 0x0016. The TLV other TLV, the Bandwidth-Request, with a TLV Type of 0x0016. The TLV
contains Required Amount and Preferred Amount fields, set to 4000 and contains Required Amount and Preferred Amount fields, set to 4000 and
6000 kbits/s respectively. 6000 kbits/s respectively.
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 (0x880C) | Length = 36 | | Type (0x880C) | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=146 | Res=0 | Result Code = 0 | | Version | Msg Type=146 | Res=0 | Result Code = 0 |
skipping to change at page 89, line 29 skipping to change at page 89, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID | | Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Request 0x0016 | TLV Length = 8 | | Bandwidth-Request 0x0016 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Amount = 4000 (kbits/s) | | Required Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Amount = 6000 (kbits/s) | | Preferred Amount = 6000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: Bandwidth Reallocation Request Message Figure 30: Bandwidth Reallocation Request Message
The Bandwidth Transfer message (M2) is shown in Figure 30. Again, The Bandwidth Transfer message (M2) is shown in Figure 31. Again,
the contents are easily understood. The Message Type for the the contents are easily understood. The Message Type for the
Bandwidth Transfer message is 147. The Result field is set to Bandwidth Transfer message is 147. The Result field is set to
Success (0x3). The message contains the Target TLV and the Success (0x3). The message contains the Target TLV and the
Bandwidth-Allocation TLV. The latter has a TLV Type of 0x0015 and Bandwidth-Allocation TLV. The latter has a TLV Type of 0x0015 and
contains a Delegated Amount field, set to 4000 kbits/s. contains a Delegated Amount field, set to 4000 kbits/s.
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 (0x880C) | Length = 32 | | Type (0x880C) | Length = 32 |
skipping to change at page 90, line 27 skipping to change at page 90, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID | | Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 | | Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Amount = 4000 (kbits/s) | | Delegated Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: NAS Response, Bandwidth Transfer Message Figure 31: NAS Response, Bandwidth Transfer Message
The Delegated Bandwidth Query request message (M3) is shown in The Delegated Bandwidth Query Request message (M3) is shown in
Figure 31. The Message Type for the Delegated Bandwidth Query Figure 32. The Message Type for the Delegated Bandwidth Query
request message is 148. The Result field is set to AckAll (0x2). request message is 148. The Result field is set to AckAll (0x2).
The message contains the Target TLV only. The message contains the Target TLV only.
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 (0x880C) | Length = 24 | | Type (0x880C) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=148 | Res=2 | Result Code = 0 | | Version | Msg Type=148 | Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 90, line 52 skipping to change at page 91, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 24 | |I| SubMessage Number | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 | | TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID | | Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: Delegated Bandwidth Query Request Message Figure 32: Delegated Bandwidth Query Request Message
Finally, the Delegated Bandwidth Query response message (M4) is shown Finally, the Delegated Bandwidth Query Response message (M4) is shown
in Figure 32. The Message Type for the Delegated Bandwidth Query in Figure 33. The Message Type for the Delegated Bandwidth Query
response message is 148. The Result field is set to Success (0x3). response message is 148. The Result field is set to Success (0x3).
The message contains the Target TLV and the Bandwidth-Allocation TLV The message contains the Target TLV and the Bandwidth-Allocation TLV
with the Delegated Amount field set to 4000 kbits/s. with the Delegated Amount field set to 4000 kbits/s.
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 (0x880C) | Length = 32 | | Type (0x880C) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=148 | Res=2 | Result Code = 0 | | Version | Msg Type=148 | Res=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier (copied from request) | | Partition ID | Transaction Identifier (copied from request) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 32 | |I| SubMessage Number | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 | | TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID | | Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 | | Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Amount = 4000 (kbits/s) | | Delegated Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: Delegated Bandwidth Query Response Message Figure 33: Delegated Bandwidth Query Response Message
A.4. Handling Of Black-Listed Join Requests A.4. Handling of Black-Listed Join Requests
This section introduces no new messages, since requests for flows in This section introduces no new messages, since requests for flows in
the black list are simply ignored. The one thing to point out is the the black list are simply ignored. The one thing to point out is the
overlap in our example between the set of flows in the grey list and overlap in our example between the set of flows in the grey list and
the flows in the black list. This does not create any ambiguity, the flows in the black list. This does not create any ambiguity,
since not only does the black list have priority for equally good since not only does the black list have priority for equally good
matches, but also the black list entries are more specific (group matches, but also the black list entries are more specific (group
prefix lengths of 32 versus 29 in the grey list) than the grey list prefix lengths of 32 versus 29 in the grey list) than the grey list
flow prefixes. flow prefixes.
A.5. Handling Of Requests To Join and Leave the On-Line Game A.5. Handling of Requests to Join and Leave the On-Line Game
The final class of multicast control actions in our example allows The final class of multicast control actions in our example allows
the subscriber to enter and leave the on-line game. As described at the subscriber to enter and leave the on-line game. As described at
the beginning of this example, the game uses Any Source Multicast the beginning of this example, the game uses Any-Source Multicast
(ASM). Subscriber signalling bypasses the AN, going directly to the (ASM). Subscriber signaling bypasses the AN, going directly to the
NAS (e.g., through a web interface). NAS (e.g., through a web interface).
When the subscriber requests to join the game, the NAS (after When the subscriber requests to join the game, the NAS (after
applying policy and bandwidth checks) sends a Multicast Replication applying policy and bandwidth checks) sends a Multicast Replication
Control message to the AN to enable the flow on the port concerned. Control message to the AN to enable the flow on the port concerned.
The AN knows not to apply admission control, since it has not The AN knows not to apply admission control, since it has not
received an MRepCtl-CAC TLV in the Provisioning message. When the received an MRepCtl-CAC TLV in the Provisioning message. When the
subscriber leaves, the NAS sends another Multicast Replication subscriber leaves, the NAS sends another Multicast Replication
Control message to delete the flow. This message sequence is shown Control message to delete the flow. This message sequence is shown
in Figure 33. in Figure 34.
It is possible that the NAS finds that there is not enough bandwidth It is possible that the NAS finds that there is not enough bandwidth
available to accommodate the subscriber's request. In this case, the available to accommodate the subscriber's request. In this case, the
NAS could send a Bandwidth Reallocation Request message to the AN, NAS could send a Bandwidth Reallocation Request message to the AN,
asking it to release some of the bandwidth delegated to it. This is asking it to release some of the bandwidth delegated to it. This is
not shown in the present example, since the messages are the same as not shown in the present example, since the messages are the same as
those already presented with the exception that the Preferred Amount those already presented with the exception that the Preferred Amount
in the request will be *less than* or equal to the Required amount, in the request will be *less than* or equal to the Required amount,
rather than *greater than* or equal to it. rather than *greater than* or equal to it.
skipping to change at page 92, line 49 skipping to change at page 93, line 48
| Leave game | | | Leave game | |
|-----------+------------------------------>| |-----------+------------------------------>|
| | | Multicast | | | | Multicast |
| | | Replication | | | | Replication |
| | | Control (M2) | | | | Control (M2) |
| Mcast Game Flow |<------------------| | Mcast Game Flow |<------------------|
| discontinued | | | discontinued | |
| | | | | | | |
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Authorization/Policy Server Authorization/Policy Server.
Figure 33: NAS-Initiated Flows For On-Line Gaming Figure 34: NAS-Initiated Flows for On-Line Gaming
Multicast Replication Control message (M1) in Figure 34 looks like The Multicast Replication Control message (M1) in Figure 35 looks
the message in Figure 26 with two exceptions. The first is that the like the message in Figure 27 with two exceptions. The first is that
NAS has the option to set the Result field to AckAll (0x02) if it the NAS has the option to set the Result field to AckAll (0x02) if it
needs positive reassurance that the flow has been enabled. This was needs positive reassurance that the flow has been enabled. This was
not done here to save having to depict a response differing only in not done here to save having to depict a response differing only in
the Result field. The larger difference in this example is that the the Result field. The larger difference in this example is that the
flow description in the Multicast-Flow embedded TLV is that of an ASM flow description in the Multicast-Flow embedded TLV is that of an ASM
multicast group (Flow Type = 1) with IPv4 (1) group address multicast group (Flow Type = 1) with IPv4 (1) group address
233.252.0.100. 233.252.0.100.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 93, line 43 skipping to change at page 94, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 | | Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 | | Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 1 | Addr Fam = 1 | Reserved = 0x0000 | | Flow Type = 1 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.100 | | Multicast Group Address = 233.252.0.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
Figure 34: Enabling The Subscriber To Join An On-Line Game Figure 35: Enabling the Subscriber to Join an On-Line Game
Message M2 terminating the flow when the subscriber leaves the game Message M2 terminating the flow when the subscriber leaves the game
looks the same as the message in Figure 34 with two exceptions: the looks the same as the message in Figure 35 with two exceptions: the
Command Code becomes "Delete" (2), and Accounting is set to "No" (0) Command Code becomes "Delete" (2), and Accounting is set to "No" (0)
to turn off flow accounting. Of course, the Transaction Identifier to turn off flow accounting. Of course, the Transaction Identifier
values will differ between the two messages. values will differ between the two messages.
A.6. Example Flow For Multicast Flow Reporting A.6. Example Flow for Multicast Flow Reporting
The example in this section is independent of the example in the The example in this section is independent of the example in the
preceding sections. preceding sections.
Figure 35 illustrates a message flow in a case where the NAS queries Figure 36 illustrates a message flow in a case where the NAS queries
the AN about which multicast flows are active on port 10, on port 11 the AN about which multicast flows are active on port 10, port 11,
and on port 20 of the AN. and port 20 of the AN.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS | |Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | Multicast Flow | | | | Multicast Flow |
| | | Query Request | | | | Query Request |
| | | (M1) | | | | (M1) |
| | |<------------------| | | |<------------------|
| | | | | | | |
| | | Multicast Flow | | | | Multicast Flow |
| | | Query Response | | | | Query Response |
| | | (M2) | | | | (M2) |
| | |------------------>| | | |------------------>|
| | | | | | | |
| | | | | | | |
Figure 35: Per-Port Multicast Flow Reporting Figure 36: Per-Port Multicast Flow Reporting
The Multicast Flow Query Request message (M1) is illustrated in The Multicast Flow Query Request message (M1) is illustrated in
Figure 36. The Message Type is 149. The Result field is set to Figure 37. The Message Type is 149. The Result field is set to
AckAll (0x2). Three Target TLVs are present, identifying port 10, AckAll (0x2). Three Target TLVs are present, identifying port 10,
port 20, and port 11 respectively. port 20, and port 11, respectively.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length | | Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 149| Res=1 | Result Code = 0 | | Version | Msg Type = 149| Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length | | TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 95, line 41 skipping to change at page 96, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length | | TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Access Loop Circuit ID (port11) ~ ~ Access Loop Circuit ID (port11) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 36: Multicast Flow Query Request Message For Per-Port Figure 37: Multicast Flow Query Request Message for Per-Port
Multicast Flow Reporting Multicast Flow Reporting
The Multicast Flow Query Response message (M2) is illustrated in The Multicast Flow Query Response message (M2) is illustrated in
Figure 37. It indicates that there is one active multicast flow Figure 38. It indicates that there is one active multicast flow
[(192.0.2.1, 233.252.0.4)] on port 10, no active multicast flow on [(192.0.2.1, 233.252.0.4)] on port 10, no active multicast flow on
port 20 and two active multicast flows [(192.0.2.1, 233.252.0.4) and port 20, and two active multicast flows [(192.0.2.1, 233.252.0.4) and
(192.0.2.2, 233.252.0.10)] on port 11. (192.0.2.2, 233.252.0.10)] on port 11.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length | | Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 149|Rslt=3 | Result Code = 0 | | Version | Msg Type = 149|Rslt=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
skipping to change at page 97, line 13 skipping to change at page 98, line 22
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| 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 38: 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 45 Allee des Ormes
Sophia Antipolis 06410 Mougins 06250
France France
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com EMail: flefauch@cisco.com
Roberta Maglione Roberta Maglione
Cisco Systems Cisco Systems
181 Bay Street 181 Bay Street
Toronto, ON M5J 2T3 Toronto, ON M5J 2T3
Canada Canada
Email: robmgl@cisco.com EMail: robmgl@cisco.com
Tom Taylor Tom Taylor
Huawei Technologies Huawei Technologies
Ottawa Ottawa
Canada Canada
Email: tom.taylor.stds@gmail.com EMail: tom.taylor.stds@gmail.com
 End of changes. 536 change blocks. 
998 lines changed or deleted 1001 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/