draft-ietf-ancp-mc-extensions-01.txt   draft-ietf-ancp-mc-extensions-02.txt 
ANCP F. Le Faucheur ANCP F. Le Faucheur
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track R. Maglione Intended status: Standards Track R. Maglione
Expires: April 29, 2010 Telecom Italia Expires: September 9, 2010 Telecom Italia
T. Taylor T. Taylor
Huawei Huawei
October 26, 2009 March 8, 2010
Additional Multicast Control Extensions for ANCP Multicast Control Extensions for ANCP
draft-ietf-ancp-mc-extensions-01.txt draft-ietf-ancp-mc-extensions-02.txt
Abstract
This document specifies the extensions to the Access Node Control
Protocol required for support of the multicast use cases defined in
the Access Node Control Protocol framework document. Those use cases
are organized into the following ANCP capabilities:
o NAS-initiated multicast replication;
o conditional access with white and black lists;
o conditional access with grey lists;
o bandwidth delegation.
These capabilities may be combined according to the rules given in
this specification.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document specifies the extensions to the Access Node Control described in the BSD License.
Protocol required for support of the multicast use cases defined in
the Access Node Control Protocol framework document. Those use cases
are organized into the following ANCP capabilities:
o NAS-initiated multicast replication;
o conditional access with white and black lists;
o conditional access with grey lists;
o bandwidth delegation.
These capabilities may be combined according to the rules given in This document may contain material from IETF Documents or IETF
this specification. Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 10 3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 8
3.1. NAS Initiated Multicast Replication Control Use Case . . . 10 3.1. NAS Initiated Multicast Replication Control Use Case . . . 8
3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11 3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 9
3.2. Conditional Access and Admission Control Use Case . . . . 11 3.2. Conditional Access and Admission Control Use Case . . . . 9
3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 12 3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 10
3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 13 3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 11
3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 13 3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11
4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 14 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 13
4.1.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 14 4.1.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 13
4.1.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 15 4.1.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 14
4.2. Port Management Message . . . . . . . . . . . . . . . . . 16 4.2. Port Management Message . . . . . . . . . . . . . . . . . 15
4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 16 4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 15
4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 17 4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 16
4.3. Multicast Replication Control Message . . . . . . . . . . 17 4.3. Multicast Replication Control Message . . . . . . . . . . 16
4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 21 4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 21
4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 22 4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 21
4.4. Multicast Admission Control Message . . . . . . . . . . . 24 4.4. Multicast Admission Control Message . . . . . . . . . . . 23
4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 25 4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 24
4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 26 4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 25
4.5. Bandwidth Reallocation Request Message . . . . . . . . . . 27 4.5. Bandwidth Reallocation Request Message . . . . . . . . . . 26
4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 28 4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 27
4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 28 4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 27
4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . . 30 4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . . 29
4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 31 4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 30
4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 31 4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 30
4.7. Delegated Bandwidth Query Request Message . . . . . . . . 32 4.7. Delegated Bandwidth Query Request Message . . . . . . . . 31
4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 33 4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 32
4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 33 4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 32
4.8. Delegated Bandwidth Query Response Message . . . . . . . . 33 4.8. Delegated Bandwidth Query Response Message . . . . . . . . 32
4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 34 4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 32
4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 34 4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 33
4.9. Multicast Flow Query Request and Response Messages . . . . 35 4.9. Multicast Flow Query Request and Response Messages . . . . 33
4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 35 4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 34
4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 36 4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 35
5. ANCP TLVs and Sub-TLVs . . . . . . . . . . . . . . . . . . . . 38 5. ANCP TLVs For Multicast . . . . . . . . . . . . . . . . . . . 37
5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 38 5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 37
5.2. Command Number TLV . . . . . . . . . . . . . . . . . . . . 41 5.2. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 38
5.3. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 41 5.3. List-Action TLV . . . . . . . . . . . . . . . . . . . . . 38
5.4. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . . 42 5.4. Sequence-Number TLV . . . . . . . . . . . . . . . . . . . 41
5.5. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 42 5.5. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 42
5.6. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 42 5.6. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . . 42
5.7. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 43 5.7. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 43
5.8. Request-Source-IP sub-TLV . . . . . . . . . . . . . . . . 43 5.8. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 43
5.9. Request-Source-MAC sub-TLV . . . . . . . . . . . . . . . . 44 5.9. Request-Source-IP TLV . . . . . . . . . . . . . . . . . . 44
5.10. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 45 5.10. Request-Source-MAC TLV . . . . . . . . . . . . . . . . . . 44
6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . . 46 5.11. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 45
6.1. Required Protocol Support . . . . . . . . . . . . . . . . 46 6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . . 47
6.1.1. Protocol Requirements For NAS-initiated Replication . 46 6.1. Required Protocol Support . . . . . . . . . . . . . . . . 47
6.1.2. Protocol requirements For Conditional Access With 6.1.1. Protocol Requirements For NAS-initiated Replication . 47
White and Black Lists . . . . . . . . . . . . . . . . 47 6.1.2. Protocol Requirements For Conditional Access With
6.1.3. Protocol requirements For Conditional Access With White and Black Lists . . . . . . . . . . . . . . . . 48
Grey Lists . . . . . . . . . . . . . . . . . . . . . . 48 6.1.3. Protocol Requirements For Conditional Access With
6.1.4. Protocol requirements For Delegated Bandwidth . . . . 49 Grey Lists . . . . . . . . . . . . . . . . . . . . . . 49
6.1.4. Protocol Requirements For Delegated Bandwidth . . . . 50
6.2. Capability-Specific Procedures for Providing Multicast 6.2. Capability-Specific Procedures for Providing Multicast
Service . . . . . . . . . . . . . . . . . . . . . . . . . 50 Service . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2.1. Procedures For NAS-initiated Replication . . . . . . . 50 6.2.1. Procedures For NAS-initiated Replication . . . . . . . 51
6.2.2. Procedures For Conditional Access With Black and 6.2.2. Procedures For Conditional Access With Black and
White Lists . . . . . . . . . . . . . . . . . . . . . 51 White Lists . . . . . . . . . . . . . . . . . . . . . 52
6.2.3. Procedures For Conditional Access With Grey Lists . . 52 6.2.3. Procedures For Conditional Access With Grey Lists . . 54
6.2.4. Procedures For Delegated Bandwidth . . . . . . . . . . 53 6.2.4. Procedures For Delegated Bandwidth . . . . . . . . . . 55
6.3. Combinations of Multicast Capabilities . . . . . . . . . . 54 6.3. Combinations of Multicast Capabilities . . . . . . . . . . 56
6.3.1. Combination of NAS-Initiated Replication with 6.3.1. Combination of Conditional Access With White and
Other Capabilities . . . . . . . . . . . . . . . . . . 54 Black Lists and Conditional Access With Grey Lists . . 56
6.3.2. Conditional Access With White, Black, and Grey 6.3.2. Combination of Conditional Access With Delegated
Lists . . . . . . . . . . . . . . . . . . . . . . . . 55 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 57
6.3.3. Conditional Access Combined With Delegated 6.3.3. Combination of NAS-Initiated Replication with
Bandwidth . . . . . . . . . . . . . . . . . . . . . . 56 Other Capabilities . . . . . . . . . . . . . . . . . . 57
7. Security Considerations . . . . . . . . . . . . . . . . . . . 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 59
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
10.1. Normative References . . . . . . . . . . . . . . . . . . . 63 10.1. Normative References . . . . . . . . . . . . . . . . . . . 64
10.2. Informative References . . . . . . . . . . . . . . . . . . 63 10.2. Informative References . . . . . . . . . . . . . . . . . . 64
Appendix A. Example of Messages and Message Flows . . . . . . . . 65 Appendix A. Example of Messages and Message Flows . . . . . . . . 66
A.1. Multicast Conditional Access and CAC without AN A.1. Provisioning Phase . . . . . . . . . . . . . . . . . . . . 66
bandwidth delegation . . . . . . . . . . . . . . . . . . . 65 A.2. Handling a Grey-Listed Flow . . . . . . . . . . . . . . . 72
A.1.1. List/Profile Provisioning . . . . . . . . . . . . . . 65 A.3. Handling White-Listed Flows . . . . . . . . . . . . . . . 77
A.1.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 67 A.4. Handling Of Black-Listed Join Requests . . . . . . . . . . 82
A.1.3. Successful Join/Leave Operations . . . . . . . . . . . 67 A.5. Handling Of Requests To Join and Leave the On-Line Game . 82
A.1.4. Admission Control Reject without NAS Response . . . . 73 A.6. Example Flow For Multicast Flow Reporting . . . . . . . . 85
A.1.5. Admission Control Reject with NAS Response . . . . . . 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89
A.2. Example Flows For bandwidth delegation . . . . . . . . . . 79
A.2.1. Activation and Provisioning of total multicast
Bandwidth . . . . . . . . . . . . . . . . . . . . . . 80
A.2.2. Successful Request For More Multicast Bandwidth . . . 81
A.2.3. Failed Autonomous Transfer With Reset . . . . . . . . 83
A.3. Example Flows For Multicast Flow Reporting . . . . . . . . 86
A.3.1. Per Port Multicast Flow Reporting . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91
1. Introduction 1. Introduction
[I-D.ietf-ancp-framework] defines a framework and requirements for an [I-D.ietf-ancp-framework] defines a framework and requirements for an
Access Node control mechanism between a Network Access Server (NAS) Access Node control mechanism between a Network Access Server (NAS)
and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer
(DSLAM)) in a multi-service reference architecture in order to (DSLAM)) in a multi-service reference architecture in order to
perform QoS-related, service-related and subscriber-related perform QoS-related, service-related and subscriber-related
operations. [I-D.ietf-ancp-protocol] specifies a protocol for Access operations. [I-D.ietf-ancp-protocol] specifies a protocol for Access
Node Control in broadband networks in line with this framework. Node Control in broadband networks in line with this framework.
skipping to change at page 7, line 40 skipping to change at page 5, line 40
o conditional access with grey lists; o conditional access with grey lists;
o bandwidth delegation. o bandwidth delegation.
NAS-initiated multicast replication assumes that multicast "join" and NAS-initiated multicast replication assumes that multicast "join" and
"leave" requests are terminated on the NAS, or that the NAS receives "leave" requests are terminated on the NAS, or that the NAS receives
requests to establish multicast sessions through other means (e.g., requests to establish multicast sessions through other means (e.g.,
application-level signalling). The NAS sends commands to the AN to application-level signalling). The NAS sends commands to the AN to
start or stop replication of specific multicast flows on specific start or stop replication of specific multicast flows on specific
subscriber ports. This use case is described briefly in the next-to- subscriber ports. This use case is described briefly in the next-to-
last paragraph of section 3.4 of [I-D.ietf-ancp-framework]. last paragraph of Section 3.4 of [I-D.ietf-ancp-framework].
Conditional access is described in sections 3.4.1 and 3.4.2.3 of Conditional access is described in Sections 3.4.1 and 3.4.2.3 of
[I-D.ietf-ancp-framework], with the latter section particularly [I-D.ietf-ancp-framework], with the latter section particularly
applicable to operation with white and black lists only. In case of applicable to operation with white and black lists only. In case of
"conditional access with white and black lists", multicast join and "conditional access with white and black lists", multicast join and
leave requests are terminated at the AN and accepted or ignored in leave requests are terminated at the AN and accepted or ignored in
accordance with the direction provided by white and black lists accordance with the direction provided by white and black lists
respectively. The white and black lists are provisioned per port at respectively. The white and black lists are provisioned per port at
startup time and may be modified thereafter. The NAS may enable startup time and may be modified thereafter. The NAS may enable
admission control of White-listed flows by appropriate provisioning. admission control of white-listed flows by appropriate provisioning.
If the bandwidth delegation capability has also been negotiated, that
capability provides a means to adjust the multicast bandwidth limits
at the AN.
Conditional access with grey lists is similar to conditional access Conditional access with grey lists is similar to conditional access
with white lists, except that before accepting any request matching a with white lists, except that before accepting any request matching a
grey list entry, the AN sends a request to the NAS for permission to grey list entry, the AN sends a request to the NAS for permission to
replicate the flow. Again, the NAS can enable admission control of replicate the flow. Again, the NAS can enable admission control of
Grey-listed flows at the AN. It can control the application of grey-listed flows at the AN.
admission control on a per-flow basis.
Bandwidth delegation is described in section 3.4.2.1 of Bandwidth delegation is described in Section 3.4.2.1 of
[I-D.ietf-ancp-framework]. It allows flexible sharing of total video [I-D.ietf-ancp-framework]. It allows flexible sharing of total video
bandwidth on an access line between the AN and the NAS. One bandwidth on an access line between the AN and the NAS. One
application of such bandwidth sharing is where the AN does multicast application of such bandwidth sharing is where the AN does multicast
admission control, while the NAS or Policy Server does unicast admission control, while the NAS or Policy Server does unicast
admission control. In that case, bandwidth delegation allows dynamic admission control. In that case, bandwidth delegation allows dynamic
sharing of bandwidth between unicast and multicast video traffic on sharing of bandwidth between unicast and multicast video traffic on
each access line. each access line.
The formal specification of the behaviours associated with each of The formal specification of the behaviours 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 behaviour 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 section multicast accounting and reporting services described in Section
3.4.3 of [I-D.ietf-ancp-framework]. Because of this common content 3.4.3 of [I-D.ietf-ancp-framework]. Because of this common content
and because of other protocol overlaps between the different and 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.
2. Terminology 2. Terminology
skipping to change at page 11, line 9 skipping to change at page 9, line 9
single copy of the multicast stream towards the AN, which in turn single copy of the multicast stream towards the AN, which in turn
performs replication to multiple subscribers as instructed by the NAS performs replication to multiple subscribers as instructed by the NAS
via ANCP. The NAS first performs conditional access and multicast via ANCP. The NAS first performs conditional access and multicast
admission control when processing multicast join requests, and only admission control when processing multicast join requests, and only
creates replication state in the AN if admission succeeds. creates replication state in the AN 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). The AN uses a Generic or leave one (or more) multicast flow(s). In the example message
Response message to convey the outcome of the directive. Figure 1 flow, the AN uses a Generic Response message to convey the outcome of
illustrates such an ANCP message exchange as well as the associated the directive. Figure 1 illustrates such an ANCP message exchange as
AN behavior. well as the associated AN behavior.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<-------------------->| NAS | |Subscriber| | Home | | AN |<-------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | (*)
| | | Multicast-Replication-Crl | | | | Multicast-Replication-Crl |
| | | (Target,add, Flow 1) | | | | (Target,add, Flow 1) |
| | |<--------------------------| | | |<--------------------------|
| Mcast Flow 1 | | | Mcast Flow 1 | |
|<==========================+ | |<==========================+ |
| | | Generic Response | | | | Generic Response |
| | |-------------------------->| | | |-------------------------->|
| | | | | | | |
| | | | | | | |
~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | |
| | | Multicast-Replication-Crl | | | | Multicast-Replication-Crl |
| | | (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
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 enduser In this scenario, on detecting a join/leave request from an enduser
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
skipping to change at page 12, line 44 skipping to change at page 11, line 32
| Leave(Gr-Flow1) | Admission-Control | | Leave(Gr-Flow1) | Admission-Control |
|------------+---------->| (Target,delete,Gr-Flow1) | |------------+---------->| (Target,delete,Gr-Flow1) |
| | |-------------------------->| | | |-------------------------->|
| <Stop Replication of X | | <Stop Replication of X |
| Mcast Gr-Flow1> | | | Mcast Gr-Flow1> | |
| | | | | | | |
Gr-Flow1: a multicast flow matching the grey list for that port Gr-Flow1: a multicast flow matching the grey list for that port
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Authorization/Policy Server 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.
skipping to change at page 14, line 25 skipping to change at page 13, line 25
the AN. the AN.
The present document specifies that the Provisioning message MAY be The present document specifies that the Provisioning message MAY be
used by the NAS to provision multicast-related information (e.g. used by the NAS to provision multicast-related information (e.g.
multicast service profiles). The ANCP Provisioning message payload multicast service profiles). The ANCP Provisioning message payload
MAY contain: MAY contain:
o one or more instances of the Multicast-Service-Profile TLV. The o one or more instances of the Multicast-Service-Profile TLV. The
Multicast-Service-Profile TLV is defined in the present document Multicast-Service-Profile TLV is defined in the present document
in Section 5.1. Each instance of the Multicast-Service-Profile in Section 5.1. Each instance of the Multicast-Service-Profile
TLV contains a Multicast Service Profile name and one or more list TLV contains a multicast service profile name and one or more list
actions. A list action consists of an action (add, delete, actions. A list action consists of an action (add, delete,
replace), a list type (White, Black, or Grey), and list content replace), a list type (White, Black, or Grey), and list content
(multicast source and group addresses). (multicast source and group addresses).
o an instance of the White-List-CAC TLV. The White-List-CAC TLV is o an instance of the White-List-CAC TLV. The White-List-CAC TLV is
defined in section TLV_White_AC. If present, this TLV indicates defined in Section 5.6. If present, this TLV indicates that the
that the AN is required to do admission control before replicating AN is required to do admission control before replicating White-
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 TLV_MRepCtl_AC. If present, this TLV indicates defined in Section 5.7. If present, this TLV indicates that the
that the AN may be required to do admission control before AN is required to do admission control before replicating flows
replicating flows specified in Multicast Replication Control specified in Multicast Replication Control messages.
messages.
See Section 6 for information on which multicast capabilities require See Section 6 for information on which multicast capabilities require
support of these TLVs in the Provisioning message. support of these TLVs in the Provisioning message.
4.1.1. Sender Behaviour 4.1.1. Sender Behaviour
When directed by the Policy Server or by management action, the NAS When directed by the Policy Server or by management action, the NAS
sends the Provisioning message to initially provision or to update sends the Provisioning message to initially provision or to update
the White, Black, and/or Grey multicast channel lists associated with the White, Black, and/or Grey multicast channel lists associated with
a set of named multicast service profiles, or to enable the AN to a set of named multicast service profiles, or to enable the AN to
skipping to change at page 15, line 30 skipping to change at page 14, line 29
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 with includes NAS-initiated replication control or conditional access with
Grey lists. Grey lists.
4.1.2. Receiver Behaviour 4.1.2. Receiver Behaviour
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
The AN MUST ignore instances of the Multicast-Service-Profile TLV according to the contents of the associated List-Action TLVs. The AN
referring to any list type (White, Black, or Grey) that is not MUST process List-Action TLVs in the order in which they appear
within the message. The AN MUST ignore instances of the List-Action
TLV referring to any list type (White, Black, or Grey) that is not
supported by the set of multicast capabilities negotiated between the supported by the set of multicast capabilities negotiated between the
NAS and the AN. NAS and the AN.
When a new Multicast Service Profile is identified by a Multicast- When a new multicast service profile is identified by a Multicast-
Service-Profile TLV, the initial state of all lists associated with Service-Profile TLV, the initial state of all lists associated with
that profile according to the negotiated set of multicast that profile according to the negotiated set of multicast
capabilities is empty until changed by the contents of Multicast- capabilities is empty until changed by the contents of Multicast-
Service-Profile TLVs. Service-Profile TLVs.
The receipt of a Provisioning message containing updates to an
existing multicast service profile subsequent to startup will cause
the AN to review the status of active flows on all ports to which
that profile has been assigned. For further details, see Section 6.
If the White-List-CAC and/or MRepCtl-CAC TLV is present in the If the White-List-CAC and/or MRepCtl-CAC TLV is present in the
Provisioning message and the respective associated capabilities have Provisioning message and the respective associated capabilities have
been negotiated, the AN prepares to do connection admission control been negotiated, the AN prepares (or continues) to do connection
on the indicated class(es) of flow. admission control on the indicated class(es) of flow. If one or both
of these TLVs was present in an earlier Provisioning message but is
absent in the latest message received, the AN ceases to do connection
admission control on the indicated class(es) of flow.
As indicated in [I-D.ietf-ancp-protocol], the AN MUST NOT reply to As indicated in [I-D.ietf-ancp-protocol], the AN MUST NOT reply to
the Provisioning message if it processed it successfully. If an the Provisioning message if it processed it successfully. If an
error prevents successful processing of the message content, the AN error prevents successful processing of the message content, the AN
MUST return a Generic Response message as defined in MUST return a Generic Response message as defined in
[I-D.ietf-ancp-protocol], containing a Status-Info TLV with the [I-D.ietf-ancp-protocol], containing a Status-Info TLV with the
appropriate content describing the error. For this purpose, the appropriate content describing the error. For this purpose, the
presence of a list typein a Multicast-Service-Profile TLV which was presence of a list type in a Multicast-Service-Profile TLV which was
ignored because it was not supported by the negotiated set of ignored because it was not supported by the negotiated set of
capabilities is not considered to be an error. capabilities is not considered to be an error.
Editor's note: that means that if a NAS mistakenly adds the wrong Editor's note: that means that if a NAS mistakenly adds the wrong
list types there will be no debugging feedback. On the other list types there will be no debugging feedback. On the other
hand, this adds flexibility for handling pre-assembled sets of hand, this adds flexibility for handling pre-assembled sets of
list updates being sent out to multiple ANs. If there are no list updates being sent out to multiple ANs. If there are no
comments on this feature/bug, this Editor's note will be removed comments on this feature/bug, this Editor's note will be removed
in the next version of the draft. in the next version of the draft.
When a new Multicast Service Profile is identified by a Multicast-
Service-Profile TLV, the initial state of all lists associated with
that profile according to the negotiated set of multicast
capabilities is empty until changed by the contents of Multicast-
Service-Profile TLVs.
4.2. Port Management Message 4.2. Port Management Message
As specified in [I-D.ietf-ancp-protocol], the NAS may send line As specified in [I-D.ietf-ancp-protocol], the NAS may send line
configuration information to the AN ("ANCP based Line Configuration" configuration information to the AN ("ANCP based Line Configuration"
use case) using GSMP Port Management messages modified to contain an use case) using GSMP Port Management messages modified to contain an
extension block. Section 5.4.3 of [I-D.ietf-ancp-protocol] defines a extension block. Section 5.4.3 of [I-D.ietf-ancp-protocol] defines a
number of TLVs that can be included in the Extension Value field number of TLVs that can be included in the Extension Value field
inside a Port Management message to support line configuration. inside a Port Management message to support line configuration.
This document specifies that the Port Management message MAY also This document specifies that the Port Management message MAY also
include the following TLVs: include either or both of the following TLVs:
o "Multicast-Service-Profile-Name" TLV (defined in Section 5.7). o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This
This TLV associates a Multicast Service Profile with the Access TLV associates a Multicast Service Profile with the Access Port
Port specified by the extension block. specified by the extension block.
o "Bandwidth-Allocation" TLV (defined in Section 5.3). 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 Port. admission control at the Access Port.
4.2.1. Sender Behaviour 4.2.1. Sender Behaviour
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 Port specified in initialize parameters associated with the Access Port 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. The NAS MUST NOT Bandwidth-Allocation TLV, reset these parameters. If the NAS
include a TLV unless it is supported by the set of multicast includes a Multicast-Service-Profile-Name TLV in the Port Management
message, the name MUST match a profile name provided in a Multicast-
Service-Profile TLV in a prior Provisioning message. The NAS MUST
NOT include a TLV unless it is supported by the set of multicast
capabilities negotiated between the NAS and the AN. See Section 6 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 Behaviour
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 Port. This association replaces any previous association. Access Port. This association replaces any previous association.
That is, a given Access Port is associated with at most one Multicast That is, a given Access Port is associated with at most 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
As specified in [I-D.ietf-ancp-framework], if a join request is later flows on the target port. For further details see Section 6.
received by the AN for a multicast flow that is part of multiple
lists in the Multicast Service Profile associated with the Access
Port, then the most specific match MUST be used by the AN. If the
most specific match occurs in multiple lists, the Black list entry
MUST take precedence over the Grey list, which MUST take precedence
over the White list. If the requested multicast flow is not part of
any list, the AN SHOULD ignore the join request.
If the Port Management message contains a Bandwidth-Allocation TLV, If the Port Management message contains a Bandwidth-Allocation TLV,
the AN adopts this as the current value of its total multicast the AN adopts this as the current value of its total multicast
bandwidth limit for the Access Port. If the AN has already committed bandwidth limit for the target port. If the AN has already committed
multicast bandwidth exceeding the amount given in the Bandwidth- multicast bandwidth exceeding the amount given in the Bandwidth-
Allocation TLV, the AN SHOULD NOT discontinue any multicast streams Allocation TLV, the AN SHOULD NOT discontinue any multicast streams
in order to bring bandwidth down to within the new limit. However, in order to bring bandwidth down to within the new limit. However,
the AN MUST NOT admit new multicast streams that are subject to the AN MUST NOT admit new multicast streams that are subject to
admission control until it can do so within the limit specified by admission control until it can do so within the limit specified by
the Bandwidth-Allocation TLV. the Bandwidth-Allocation TLV.
If the Port Management request cannot be processed due to error and If the Port Management request cannot be processed due to error and
the Result field of the request is Nack (0x1) or AckAll (0x2), the AN the Result field of the request is Nack (0x1) or AckAll (0x2), the AN
SHOULD add a Status-Info TLV to the Extension Value field in its SHOULD add a Status-Info TLV to the Extension Value field in its
reply if this will provide useful information beyond what is provided reply if this will provide useful information beyond what is provided
by the Code value returned in the response header. by the Code value returned in the response header. In particular, if
the name within the Multicast-Service-Profile-Name TLV does not match
a profile name given in a prior Provisioning message, the AN SHOULD
return a reply where the Code field in the header indicates "Invalid
TLV value" (85), the Error Message field in the Status-Info TLV
contains the text "Multicast profile name not provisioned", and the
Status-Info TLV contains a copy of the Multicast-Service-Profile-Name
TLV.
4.3. Multicast Replication Control Message 4.3. Multicast Replication Control Message
This section defines a new message called the Multicast Replication This section defines a new message called the Multicast Replication
Control message. The Multicast Replication Control message is sent Control message. The Multicast Replication Control message is sent
by the NAS to the AN with one or more directives to add (join) or by the NAS to the AN with one or more directives to add (join) or
delete (leave) a multicast flow on a target object identified in the delete (leave) a multicast flow on a target object identified in the
content of the message. content of the message.
The Message Type for the Multicast Replication Control message is The Message Type for the Multicast Replication Control message is
0x90. 144.
The ANCP Multicast Replication Control message payload contains the The ANCP Multicast Replication Control message payload contains the
following TLVs: following TLVs:
o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol]. o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol].
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
[I-D.ietf-ancp-protocol] and identifies the AN port subject to the [I-D.ietf-ancp-protocol] 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 o Command TLV: The Command TLV is defined in
[I-D.ietf-ancp-protocol]. It MUST be present. It MAY appear [I-D.ietf-ancp-protocol]. It MUST be present. It MAY appear
multiple times. Each Command TLV contains a multicast flow multiple times.
directive for the target.
The contents of the Command TLV for the Multicast Replication Control
Message are defined in Figure 4 and subsequent text.
0 1 2 3 As [I-D.ietf-ancp-protocol] indicates, the contents of the Command
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 Info field within the Command TLV are specific to the message in
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ which the TLV occurs. For the Multicast Replication Control Message,
| Command Code |R O M Flags | Command Length | these contents consist of:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Flow Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-\ /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Cont'd) ... / \ | Multicast Flow Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-\ /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Cont'd) ... / \ | Sub-TLVs ... |
+-+-+-+-+-+-+-+-+-+-+-+-+\ /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Cont'd) ... / \ | Padding to 32-bit boundary |
+-+-+-+-+-+-+-+-+-+-+-+-+\ /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Contents of the Command TLV in the Multicast Replication o a Command Code field;
Control Message
Command Code: o an Accounting field;
Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete
All.
Command Length: o an instance of the Multicast-Flow TLV.
Length in bytes of the Command including multicast flow
address, but excluding the Command Code header and flags.
Flags: Figure 4 illustrates the complete Command TLV with the contents
8 bit General purpose Flag field. Currently the following specific to the Multicast Replication Control message.
flags are defined:
R - Resource Admitted Flag. Set to 1 in an add 1 2 3
command to indicate that the flow resources have 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
been reserved by admission control. Cleared to 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
otherwise. | TLV Type = Command | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Command Code | Accounting | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Flow TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other embedded TLV Type | Other embedded TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Other embedded TLV data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
O - Flow Accounting. When set in add command Figure 4: Contents of the Command TLV in the Multicast Replication
indicates that byte accounting for the flow is to Control Message
commence.
M - When set, indicates that the multicast flow is Command Code:
SSM; the Command MUST then specify both the Command directive:
source and the group address. When not set,
indicates that the multicast flow is ASM; the
Command MUST then specify the group address only,
omitting the Source Address field.
Multicast Flow Source Address: 0x01 - Add;
a field containing three sub-fields as illustrated in
Figure 5, giving the source address for an SSM flow. This
field MUST be present if the M flag is set, and MUST NOT be
present if the M flag is cleared.
Multicast Flow Group Address: 0x02 - Delete;
a field containing three sub-fields as illustrated in
Figure 5, giving the group address for the multicast flow.
This field MUST be present.
The address family of the group address MAY differ from the address 0x03 - Delete All;
family of the source address, if present.
For future extensibility, each Command TLV MAY also have additional 0x04 - Admission Control Reject;
sub-TLVs appended following the command and multicast flow
information (shown as "Sub-TLVs" in Figure 4). Unrecognized sub-TLVs
SHOULD be silently discarded.
If needed, padding is done at the end of the command data so that the 0x05 - Conditional Access Reject;
TLV is 32-bit aligned.
As shown in Figure 5, each address entry in the Command TLV consists 0x06 - Admission Control and Conditional Access
of the following three sub-fields with no intervening padding: Reject.
Address Family: Directives 0x04 through 0x06 are used as described in
The address family of the address with values as defined in Section 4.4.2
[IANAAEA].
Encoding Type: Accounting:
The type of encoding used within a specific Address Family. The Meaningful only when the Command Code is "Add" (0x01). In
value `0' is reserved for this field, and represents the native that case, 0x00 indicates no flow accounting, 0x01
encoding of the Address Family. This is consistent with the indicates that octet accounting for the flow is to
address encoding specified in [RFC4601]. commence. The Accounting field MUST be set to 0x00 for
other Command Code values.
Address: Reserved:
The address as represented by the given Address Family and Reserved for future use. MUST be set to 0x0000 by the
Encoding Type. This is consistent with the address encoding sender and ignored by the receiver.
specified in [RFC4601].
0 1 2 3 Multicast-Flow TLV:
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 An instance of the Multicast-Flow TLV (Section 5.11)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ specifying the flow to be added or deleted. The Multicast-
| Addr Family | Encoding Type | IP Address | Flow TLV MUST be omitted if the Command Code has value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/-+-+-+-+-+-+-+-+ "Delete All" (0x03).
| IP Address (Cont'd) ... \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/-+-+-+-+-+-+-+-+
Figure 5: Structure of the Address Fields in the Command TLV Other embedded TLV:
No other embedded TLVs are currently specified within the
Multicast Replication Control message/Command TLV.
Unrecognized embedded TLVs 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 SSM flows message that would result in a swap from multicast SSM flows
192.0.2.1, 233.252.0.2, to 192.0.2.2, 233.252.0.3 on the Target 192.0.2.1, 233.252.0.2, to 192.0.2.2, 233.252.0.3 on the Target
identified by the "Access Loop Circuit ID": identified by the "Access Loop Circuit ID":
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 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length | | Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=90 | 0x02 | Code | | Vers | Sub |MessageType=144| 0x02 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0001 | | Partition ID | Transaction Identifier = 0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Target 0x1000 | Target TLV Length | | 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 ~ ~ Access Loop Circuit ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Command TLV | Command-TLV Length | | Type = Command TLV | Command-TLV Length = 0x0014 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x02 |0 0 1 | Command Length | | Cmd Code=0x02 |Acctg = 0x00 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | |TLV Type = Multicast-Flow | TLV Length = 0x000C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Mcast Source (Ctnd) 192.0.2.1 | AddrFamily 01 | EncType 0x0 | |Flow Type=0x02 |AddrFam = 0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast Flow : 233.252.0.2 | | Multicast Group Address: 233.252.0.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Type = Command-TLV | Command-TLV Length | | Source Address = 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Type = Command-TLV | Command-TLV Length = 0x0014 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 |0 0 1 | Command Length | | Cmd Code=0x01 |Acctg = 0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 | |TLV Type = Multicast-Flow | TLV Length = 0x000C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Mcast Source (Ctnd) 192.0.2.2 | AddrFamily 01 | EncType 0x0 | |Flow Type=0x02 |AddrFam = 0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast Flow: 233.252.0.3 | | Multicast Group Address = 233.252.0.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address = 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
4.3.1. Sender Behaviour 4.3.1. Sender Behaviour
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 NAS initiated Multicast Control use case presented in
[I-D.ietf-ancp-framework] and summarized in Section 3.1. In that [I-D.ietf-ancp-framework] and summarized in Section 3.1. In that
skipping to change at page 22, line 19 skipping to change at page 21, line 27
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 [I-D.ietf-ancp-framework] and summarized in Section 3.2. presented in [I-D.ietf-ancp-framework] and summarized in Section 3.2.
In that case, the NAS MUST set the Result field to NAck (0x1). In that case, the NAS MUST set the Result field to NAck (0x1).
In either case, the sender MUST populate the Code field with the In either case, the sender MUST populate the Code field with the
value 0x000 and the ANCP Transaction Identifier field with a unique value 0x000 and the ANCP Transaction Identifier field with a unique
value, as described in section 5.4.5 of [I-D.ietf-ancp-protocol]. value, as described in section 5.4.5 of [I-D.ietf-ancp-protocol].
Each Multicast Replication Control Message MAY 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.
The NAS MAY choose to perform admission control before adding a
particular flow even if admission control has been enabled on the AN.
If it does so, it MUST set the R flag in the Command TLV concerned.
Conversely, if admission control has been enabled on the AN, the NAS
MAY choose to have the AN do admission control by clearing the R
flag.
Note that clearing the R flag causes the AN to allocate resources
for the flow out of its bandwidth budget as opposed to any
bandwidth budget managed for the same access line at the NAS.
4.3.2. Receiver Behaviour 4.3.2. Receiver Behaviour
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 flags or by optional attributes received in controlled or affected by attributes received in the Multicast
the Multicast Replication Control message, SHALL be as set by the Replication Control message, SHALL be as set by the last command or
last command or message referring to that target and flow and message referring to that target and flow and containing the
containing the controlling flag or optional attribute. As an controlling attribute. As an example, successive Multicast
example, successive Multicast Replication Control messages containing Replication Control messages containing add commands for a given port
add commands for a given port and flow, but differing only in the and flow, but differing only in the Accounting field setting SHALL be
accounting flag setting SHALL be interpreted to mean that the state interpreted to mean that the state of the accounting feature is as
of the accounting feature is as set in the final command received, set in the final command received, but all other features are as set
but all other features are as set in the initial message. in the initial 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 0x01 for the first command. Control message, starting from 0x01 for the first command.
If admission control for Multicast Replication Control messages has If a Command TLV adds a flow and the AN is performing admission
not been enabled (through provisioning of the MRepCtl_CAC TLV, the AN control for Multicast Replication Control messages, then the AN MUST
MUST ignore the R flag in Command TLVs. Otherwise, if a Command TLV perform admission control before replicating the flow. If the
adds a flow, the R flag within the TLV is not set, and the AN is admission control check fails, the AN MUST treat the failure as an
performing admission control for Multicast Replication Control error as described below. The appropriate Code value for the
messages, then the AN MUST perform admission control before response is 18 (0x012) "Insufficient resources".
replicating the flow. If the admission control check fails, the AN
MUST treat the failure as an error as described below. The
appropriate Code value for the response is 18 (0x012) "Insufficient
resources".
If the AN processes the complete Multicast Replication Control If the AN processes the complete Multicast Replication Control
message successfully and the Result field of the Multicast message successfully and the Result field of the Multicast
Replication Control message was set to AckAll (0x2), the AN MUST Replication Control message was set to AckAll (0x2), the AN MUST
respond with a Generic Response message where the Result field is set respond with a Generic Response message where the Result field is set
to Success (0x3), the Code field is set to 0x000, and the Transaction to Success (0x3), the Code field is set to 0x000, and the Transaction
Identifier field is copied from the Multicast Replication Control Identifier field is copied from the Multicast Replication Control
message. The body of the response MAY be empty or MAY be copied from message. The body of the response MAY be empty or MAY be copied from
the Multicast Replication Control message. the Multicast Replication Control message.
If the AN processes the complete Multicast Replication Control
message successfully and the Result field of the Multicast
Replication Control message was set to Nack (0x1), the AN MUST NOT
respond to the message.
The processing/execution of multiple commands contained in a single The processing/execution of multiple commands contained in a single
Multicast Control message MUST be interrupted at the first error Multicast Control message MUST be interrupted at the first error
encountered, and the remaining commands in the Multicast Replication encountered, and the remaining commands in the Multicast Replication
Control message discarded. Control message discarded.
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 (0x1) or AckAll(0x2), the AN MUST generate a Generic Response message
message providing error information to the NAS. This specification providing error information to the NAS. This specification
identifies the following new Code values beyond those specified in identifies the following new Code values beyond those specified in
[I-D.ietf-ancp-protocol], which MAY be used in a Generic Response [I-D.ietf-ancp-protocol], which MAY be used in a Generic Response
sent in reply to a Multicast Replication Control message: sent in reply to a Multicast Replication Control message:
0x100 Command error. This SHOULD be reported for the following 100 Command error. This SHOULD be reported for the case that an
cases: invalid command code has been received.
* invalid command code;
* undefined flag set.
0x101 Bad flow address. This SHOULD be reported for the following 101 Bad flow address. This SHOULD be reported for the following
cases: cases:
* unsupported address family; * unsupported address family;
* unsupported address encoding; * source address present for an ASM flow, or absent for an SSM
flow.
* source address present when M flag cleared, or absent when M
flag set.
0x102 Multicast flow does not exist. This SHOULD be reported if the 102 Multicast flow does not exist. This SHOULD be reported if the
NAS attempts to delete a flow that is not enabled. NAS attempts to delete a flow that is not enabled.
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 Code values MUST Control message and containing one of the above Code values MUST
include a Status-Info TLV which includes one or two sub-TLVs as include a Status-Info TLV which includes one or two embedded TLVs as
follows: follows:
o a Command Number TLV as described in Section 5.2, 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;
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 that the Error Message field of the Status-Info TLV MAY be
used to report more details than implied by the Code value in the used to report more details than implied by the Code value in the
message header. For example, the Code value could be 0x101 and message header. For example, the Code value could be 101 and the
the Error Message field could contain the text: "Source address Error Message field could contain the text: "Source address
present when M flag cleared". 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 0x92. The Message Type for the Multicast Admission Control message is 145.
The ANCP Multicast Admission Control message payload contains two The ANCP Multicast Admission Control message payload contains two
TLVs: TLVs:
o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol]. o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol].
It MUST appear once and only once in the Multicast Admission It MUST appear once and only once in the Multicast Admission
Control message. It is encoded as specified in Control message. It is encoded as specified in
[I-D.ietf-ancp-protocol] and identifies the AN port subject to the [I-D.ietf-ancp-protocol] and identifies the AN port subject to the
request for admission or release. request for admission or release.
skipping to change at page 25, line 25 skipping to change at page 24, line 13
(e.g. to carry both a leave from one group and a join to another (e.g. to carry both a leave from one group and a join to another
group for the same Target). It is expected that this would group for the same Target). It is expected that this would
support a similar notion of strict sequenced processing as support a similar notion of strict sequenced processing as
currently defined for handling multiple directives in the currently defined for handling multiple directives in the
Multicast Replication Control message whereby all directives Multicast Replication Control message whereby all directives
following the first directive that can not be executed are not following the first directive that can not 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
Multicast Replication Control message, with the following additions:
o a Request-Source-IP TLV MAY be appended to the Command TLV as an
additional embedded TLV;
o similarly, a Request-Source-MAC TLV MAY be appended to the Command
TLV as an additional embedded TLV.
Note that the Command TLV length includes the length of any embedded
TLVs, including the embedded TLV headers.
4.4.1. Sender Behaviour 4.4.1. Sender Behaviour
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 5.4.5 unique value, as described in section 5.4.5
of[I-D.ietf-ancp-protocol] . of[I-D.ietf-ancp-protocol] .
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 R flag MUST be set to 0; o the Accounting field MUST be set to 0;
o the O flag MUST be set to 0;
o the Command Code field MUST be set to "0x01 - Add" when the o the Command Code field MUST be set to "0x01 - Add" when the
message conveys a Join , to "0x02 - Delete" when the message message conveys a Join , to "0x02 - Delete" when the message
conveys a Leave and to "0x03 - Delete All" when the message conveys a Leave and to "0x03 - Delete All" when the message
conveys a Leave of all channels (on the target); conveys a Leave of all channels (on the target);
o The M Flag, Multicast Source Address and Multicast Flow Address of o The Multicast-Flow TLV within the Command TLV identifies the
the Command TLV identify the multicast flow subject to the request multicast flow subject to the request for admission or release.
for admission or release. When the Command Code is 0x03, the M When the Command Code is 0x03, the Multicast-Flow TLV is
Flag, Multicast Source address, and Multicast Flow Address are meaningless and MUST be omitted.
meaningless and MUST be set to all zeroes.
o a Request-Source-IP sub-TLV (as defined in Section 5.8) MAY be o the Request-Source-IP embedded TLV MAY be included by the AN to
included by the AN to convey the IP address of the sender of the convey the IP address of the sender of the join/leave message
join/leave message (e.g. IGMP/MLD Join/Leave) that triggered the (e.g. IGMP/MLD Join/Leave) that triggered the AN to include the
AN to include the corresponding Command TLV in the Admission corresponding Command TLV in the Admission Control message. If it
Control message. If it appears more than once, only the first appears more than once, only the first instance is considered
instance is considered meaningful and the other instances are meaningful and the other instances are ignored.
ignored.
o a Request-Source-MAC sub-TLV (as defined in Section 5.9) MAY be o the Request-Source-MAC embedded TLV MAY be included by the AN to
included by the AN to convey the MAC address of the sender of the convey the MAC address of the sender of the join/leave message
join/leave message (e.g. IGMP/MLD Join/Leave) that triggered the (e.g. IGMP/MLD Join/Leave) that triggered the AN to include the
AN to include the corresponding Command TLV in the Admission corresponding Command TLV in the Admission Control message. If it
Control message. If it appears more than once, only the first appears more than once, only the first instance is considered
instance is considered meaningful and the other instances are meaningful and the other instances are ignored.
ignored.
4.4.2. Receiver Behaviour 4.4.2. Receiver Behaviour
On receipt of an Multicast Admission Control message, the NAS: On receipt of an Multicast Admission Control message, the NAS:
o MUST ignore the Result field; o MUST ignore the Result field;
o if the directive in the Multicast Admission Control message is o if the directive in the Multicast Admission Control message is
"0x02 - Delete" or "0x03 - Delete All" and is processed correctly "0x02 - Delete" or "0x03 - Delete All" and is processed correctly
by the NAS, the NAS MUST NOT generate any ANCP message in response by the NAS, the NAS MUST NOT generate any ANCP message in response
skipping to change at page 26, line 44 skipping to change at page 25, line 38
Multicast Replication Control in response to the Multicast Multicast Replication Control 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 generated by the NAS (distinct * MUST contain a Transaction ID generated by the NAS (distinct
non-zero, and linearly incremented by NAS for each request per non-zero, and linearly incremented by NAS for each request per
adjacency); adjacency);
* MUST contain the directive as accepted by the NAS. The R flag * MUST contain the directive as accepted by the NAS. The NAS MAY
in the returned Command TLV MUST have value 0 if the NAS modify the Accounting field if flow accounting is required.
intends the AN to perform admission control before installing
the flow, 1 otherwise. Note that the AN will ignore the R flag
unless the MRepCtl_CAC TLV has been provisioned on the AN.
o if the directive in the Multicast Admission Control message is o if the directive in the Multicast Admission Control message is
"0x01 - Add", is processed correctly but not accepted by the NAS "0x01 - Add", is processed correctly but not accepted by the NAS
(i.e. it does not pass the admission control or conditional access (i.e. it does not pass the admission control or conditional access
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 message. message in response to the Multicast Admission Control message.
This optional message can be used by the AN to maintain statistics This optional message can be used by the AN to maintain statistics
about admission control reject and, in the future, when the about admission control rejections.
protocol between the subscriber and the AN allows explicit
notification of join reject (e.g.
[I-D.morin-mboned-igmpmld-error-feedback]). When used in this
situation, the Multicast Replication Control message:
* MUST contain a Result set to 0x00; In the future, the AN may be able to notify the subscriber that
the request was rejected (e.g. using
[I-D.morin-mboned-igmpmld-error-feedback]).
When used in this situation, the Multicast Replication Control
message:
* MUST contain a Result set to 0x0;
* MUST contain a Transaction ID generated by the NAS (distinct * MUST contain a Transaction ID generated by the NAS (distinct
non-zero, and linearly incremented by NAS for each request per non-zero, and linearly incremented by NAS for each request per
adjacency); adjacency);
* 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 "0x04 - TLV and Command TLV) but with a Command Code set to "0x04 -
Admission Control Reject", "0x05 - Conditional Access Reject" Admission Control Reject", "0x05 - Conditional Access Reject",
or "0x06 - Admission Control and Conditional Access Reject". or "0x06 - Admission Control and Conditional Access Reject".
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 multicast
flow does not exist etc.), the NAS MUST generate a Generic flow does not exist etc.), the NAS MUST generate a Generic
Response message (defined in [I-D.ietf-ancp-protocol]) with Response message (defined in [I-D.ietf-ancp-protocol]) with
appropriate content indicating the reason for the failure. appropriate content indicating the reason for the failure.
4.5. Bandwidth Reallocation Request Message 4.5. Bandwidth Reallocation Request Message
skipping to change at page 27, line 49 skipping to change at page 26, line 44
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 5.4.5.1.1 of [I-D.ietf-ancp-protocol]), o the Target TLV (section 5.4.5.1.1 of [I-D.ietf-ancp-protocol]),
specifying a single access line; specifying a single access line;
o the Bandwidth-Request TLV (Section 5.6), 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
0x94. 146.
4.5.1. Sender Behaviour 4.5.1. Sender Behaviour
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 The choice of "total bandwidth" rather than "incremental
skipping to change at page 28, line 47 skipping to change at page 27, line 44
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 Code the Bandwidth Transfer message MUST be set to Success (0x3), the Code
field MUST be set to 0x000, and the Bandwidth-Allocation TLV field MUST be set to 0x000, and the Bandwidth-Allocation TLV
(Section 5.3) MUST contain the new value of total multicast (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 Code field MUST be set to message MUST be set to Failure (0x4), the Code field MUST be set to
0x000, and the Bandwidth Allocation TLV MUST contain the value of the 0x000, and the Bandwidth Allocation TLV MUST contain the value of the
currently allocated amount of delegated bandwidth as the responder currently allocated amount of delegated bandwidth as the responder
views it. 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 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.
skipping to change at page 29, line 41 skipping to change at page 28, line 39
While the cases just described are an error condition, the success While the cases just described are an error condition, the success
response achieves a graceful recovery. 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
Code value set to 0x105 "Bandwidth request conflict". Code value set to 105 "Bandwidth request conflict".
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
skipping to change at page 30, line 24 skipping to change at page 29, line 22
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 Code values applicable This specification provides three new Code values applicable
specifically to the contents of the Bandwidth-Request TLV. These specifically to the contents of the Bandwidth-Request TLV. These
Code values by their nature MUST only be used when the error is being Code values by their nature MUST only be used when the error is being
reported in a Bandwidth Transfer message rather than a Generic reported in a Bandwidth Transfer message rather than a Generic
Response message. Response message.
0x103 invalid preferred bandwidth amount. This indicates that the 103 invalid preferred bandwidth amount. This indicates that the
preferred and required amounts of bandwidth in the TLV do not have preferred and required amounts of bandwidth in the TLV do not have
the numerical relationship described in the previous section. the numerical relationship described in the previous section.
0x104 inconsistent views of delegated bandwidth amount. This will 104 inconsistent views of delegated bandwidth amount. This will
appear only in a Bandwidth Transfer message from the NAS to the AN appear only in a Bandwidth Transfer message from the NAS to the AN
in the case where the NAS has an outstanding Bandwidth in the case where the NAS has an outstanding Bandwidth
Reallocation Request. The recommended procedure for recovery is Reallocation Request. The recommended procedure for recovery is
described in Section 4.6.2. described in Section 4.6.2.
0x105 bandwidth request conflict. The NAS has rejected the AN's 105 bandwidth request conflict. The NAS has rejected the AN's
request for more bandwidth because the NAS has an outstanding request for more bandwidth because the NAS has an outstanding
bandwidth request. bandwidth request.
4.6. Bandwidth Transfer Message 4.6. Bandwidth Transfer Message
The Bandwidth Transfer message is used to transfer video bandwidth The Bandwidth Transfer message is used to transfer video bandwidth
from the sender to the peer for a specific access line. This message from the sender to the peer for a specific access line. This message
MAY be sent either from the AN or from the NAS. As described in the MAY be sent either from the AN or from the NAS. As described in the
previous section, it is the required response to a valid Bandwidth previous section, it is the required response to a valid Bandwidth
Reallocation Request message. Reallocation Request message.
skipping to change at page 31, line 9 skipping to change at page 30, line 6
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 This allows the receiver to distinguish between an autonomous
transfer and a response to a previous Bandwidth Reallocation transfer and a response to a previous Bandwidth Reallocation
Request, for purposes of validation. Request, for purposes of validation.
The Message Type for the Bandwidth Transfer message is 0x95. 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.3). The o an instance of the Bandwidth-Allocation TLV (Section 5.5). The
bandwidth value in the Bandwidth-Allocation TLV is the new amount bandwidth value in the Bandwidth-Allocation TLV is the new amount
of delegated bandwidth allocated to the target. of delegated bandwidth allocated to the target.
4.6.1. Sender Behaviour 4.6.1. Sender Behaviour
When sending a Bandwidth Transfer message where the Result value is When sending a Bandwidth Transfer message where the Result value is
Ignore (0x0) or Success (0x3), the following relationships MUST hold: Ignore (0x0) or Success (0x3), the following relationships MUST hold:
o if the message is sent by the NAS, the bandwidth value in the o if the message is sent by the NAS, the bandwidth value in the
Bandwidth-Allocation TLV MUST be greater than or equal to the Bandwidth-Allocation TLV MUST be greater than or equal to the
skipping to change at page 32, line 15 skipping to change at page 31, line 13
enforce. enforce.
4.6.2.2. Behaviour of the AN 4.6.2.2. Behaviour 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 Code field equal to 0x104 field equal to Failure (0x4) and a Code field equal to 104
"Inconsistent views of delegated bandwidth amount" or 0x105 "Inconsistent views of delegated bandwidth amount" or 105 "Bandwidth
"Bandwidth request conflict". If Code value 0x104 is received, the request conflict". If Code value 104 is received, the AN MUST issue
AN MUST issue a Delegated Bandwidth Query Request message to a Delegated Bandwidth Query Request message to determine the NAS's
determine the NAS's current view of the amount of delegated current view of the amount of delegated bandwidth. The AN MUST
bandwidth. The AN MUST update its own view based on the value update its own view based on the value returned in the Delegated
returned in the Delegated Bandwidth Query Response. If Code value Bandwidth Query Response. If Code value 105 is received, the AN
0x105 is received, the AN SHOULD carry out this procedure unless it SHOULD carry out this procedure unless it can account for the
can account for the discrepancy as a result of a transfer of discrepancy as a result of a transfer of bandwidth to the NAS that
bandwidth to the NAS that was carried out just before the incoming was carried out just before the incoming Bandwidth Transfer message
Bandwidth Transfer message was processed. was processed.
The two Code values indicate a race condition where the AN may The two Code values indicate a race condition where the AN may
have just completed a transfer of bandwidth to the NAS. As a have just completed a transfer of bandwidth to the NAS. As a
result, the value given in the Bandwidth Transfer message may be result, the value given in the Bandwidth Transfer message may be
outdated, and the AN needs to query the NAS to find its latest 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 as the result of the procedures just described the AN determines
that it has over-committed multicast bandwidth, it MUST NOT terminate that it has over-committed multicast bandwidth, it MUST NOT terminate
any currently-active programs, but MUST NOT honour any more "join" any currently-active programs, but MUST NOT honour any more "join"
requests until it is possible to do so within the limit set by its requests until it is possible to do so within the limit set by its
current value of delegated bandwidth. current value of delegated bandwidth.
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 0x96. 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 Behaviour
skipping to change at page 33, line 32 skipping to change at page 32, line 29
Transaction-Id field MUST be copied from the request message. The Transaction-Id field MUST be copied from the request message. The
body of the response MUST contain the Target TLV, copied from the body of the response MUST contain the Target TLV, copied from the
request message. Finally, the body of the response MUST contain a request message. Finally, the body of the response MUST contain a
Bandwidth-Allocation TLV, containing the current amount of delegated Bandwidth-Allocation TLV, containing the current amount of delegated
bandwidth from the point of view of the receiver of the request. bandwidth from the point of view of the receiver of the request.
If the contents of the Delegated Bandwidth Query Request message are If the contents of the Delegated Bandwidth Query Request message are
in error, the receiver MUST return a Delegated Bandwidth Query in error, the receiver MUST return a Delegated Bandwidth Query
Response message with the Result field in the header set to Failure Response message with the Result field in the header set to Failure
(0x3). The Code field MUST be set to the value that indicates the (0x3). The Code field MUST be set to the value that indicates the
nature of the error (e.g., 0x004 "Unrecognized target"). The nature of the error (e.g., 4 "Unrecognized target"). The
Transaction-Id field MUST be copied from the request. The body of Transaction-Id field MUST be copied from the request. The body of
the response MUST contain the Target TLV copied from the request. the response MUST contain the Target TLV copied from the request.
This MAY be followed by a Status-Info TLV giving further infromation This MAY be followed by a Status-Info TLV giving further information
about the error. 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. The response to a valid request
contains two TLVs: contains two TLVs:
o the Target TLV, copied from the request; o the Target TLV, copied from the request;
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 0x96. is 148.
4.8.1. Sender Behaviour 4.8.1. Sender Behaviour
Sender behaviour for the Delegated Bandwidth Query Response message Sender behaviour for the Delegated Bandwidth Query Response message
is specified in Section 4.7.2. is specified in Section 4.7.2.
4.8.2. Receiver Behaviour 4.8.2. Receiver Behaviour
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 following actions apply.
skipping to change at page 34, line 35 skipping to change at page 33, line 30
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, containing 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. Behaviour 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 currently committed more than this amount to active programs, it MUST
NOT cease replicating the flows concerned, but MUST NOT honour any NOT cease replicating the flows concerned, but MUST NOT honour any
more Join requests until possible to do so within the new limit. more Join requests until possible to do so within the new limit.
A race condition is possible, where the AN sends a query, the NAS A race condition is possible, where the AN sends a query, the NAS
requests more bandwidth, then receives and responds to the query, requests more bandwidth, then receives and responds to the query,
then receives the Bandwidth Transfer message responding to its then receives the Bandwidth Transfer message responding to its
request. It is up to the AN to take appropriate action in this request. It is up to the AN to take appropriate action in this
skipping to change at page 35, line 15 skipping to change at page 34, line 7
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 is sent by the NAS to request information about the multicast
flows that are active on the AN. The Multicast Flow Query Response flows that are active on the AN. The Multicast Flow Query Response
is sent in response by the AN to provide the requested information to is sent in response by the AN to provide the requested information to
the NAS. 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 0x97. 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 Response depend
on the nature of the query, as described below. on the nature of the query, as described below.
4.9.1. Sender Behaviour 4.9.1. Sender Behaviour
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 Code field MUST be set to 0x000. Result field to AckAll (0x2). The Code field MUST be set to 0x000.
The sender MUST populate the ANCP Transaction Identifier field with a The sender MUST populate the ANCP Transaction Identifier field with a
unique value, as described in section 5.4.5 of [I-D.ietf-ancp- unique value, as described in section 5.4.5 of [I-D.ietf-ancp-
skipping to change at page 35, line 40 skipping to change at page 34, line 32
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
and every port of the AN. and every port of the AN.
To retrieve the AN's view of which multicast flows are currently To retrieve the AN's view of which multicast flows are currently
active on one (or multiple) given port(s) of the AN, the Multicast active on a given port of the AN, the NAS MUST include a Target TLV
Flow Query Request payload MUST contain the following TLVs: in the Multicast Flow Query Request payload identifying that port.
The Target TLV is encoded as specified in [I-D.ietf-ancp-protocol].
o Target TLV. It MUST appear at least once. Each occurence
identifies one AN port for which information on active multicast
flows is queried. It is encoded as specified in
[I-D.ietf-ancp-protocol].
To retrieve the AN's view of which ports one (or multiple) given To retrieve the AN's view of the ports currently receiving a given
multicast flow(s) is (are) currently active on, the Multicast Flow multicast flow, the NAS MUST include a Multicast-Flow TLV in the
Query Request payload MUST contain the following TLVs: Multicast Flow Query Request payload identifying that flow. The
Multicast-Flow TLV is encoded as specified in Section 5.11.
o Multicast-Flow TLV. It MUST appear at least once. Each occurence The NAS MAY include multiple Target TLVs or multiple Multicast-Flow
identifies one multicast flow for which information is queried. TLVs in the Multicast Flow Query Request, but MUST NOT include both
It is encoded as specified in Section 5.10. Target and Multicast-Flow TLVs in the same message.
To retrieve the AN's view of all the multicast flows currently active To retrieve the AN's view of all of the multicast flows currently
on each port of the AN, the Multicast Flow Query Request payload MUST active on each port of the AN, the NAS MUST send a Multicast Flow
NOT contain any instance of the Target TLV or the Multicast-Flow TLV. Query Request which does not contain any instance of the Target TLV
or the Multicast-Flow TLV.
4.9.2. Receiver Behaviour 4.9.2. Receiver Behaviour
The AN MUST respond to a Multicast Flow Query Request message that The AN MUST respond to a Multicast Flow Query Request message that
has a valid format and a valid content with a Multicast Flow Query has a valid format and a valid content with a Multicast Flow Query
Response message. The Result field in the response MUST be set to Response message. The Result field in the response MUST be set to
Success (0x3). The Code field MUST be set to 0x000. The Success (0x3). The Code field MUST be set to 0x000. The
Transaction-Id field MUST be copied from the request. Transaction-Id field MUST be copied from the request.
If the Multicast Flow Query Request contained one (or more) Target If the Multicast Flow Query Request contained one (or more) Target
skipping to change at page 36, line 39 skipping to change at page 35, line 31
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 contained 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 Target TLV in the o Multicast-Flow TLV. This MUST be identical to the Multicast-Flow
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 contained no Target TLV and no
Multicast Flow TLV, the AN MUST include, for each AN port, the Multicast Flow TLV, the AN MUST include, for each AN port currently
following set of TLVs: 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 are in error, the
AN MUST reply with a Multicast Flow Query Response message with the AN MUST reply with a Multicast Flow Query Response message with the
Result field set to Failure (0x4) and the Code field set to indicate Result field set to Failure (0x4) and the Code field set to indicate
the nature of the error. If the request contained multiple instances the nature of the error. If the request contained multiple instances
of the Target TLV or the Multicast-Flow TLV and one of these is in of the Target TLV or the Multicast-Flow TLV and one of these is in
error, the response message MUST contain the results for the error, the response message MUST contain the results for the
preceding instances of the TLV as if there had been no error. These preceding instances of the TLV as if there had been no error. These
successful results MUST be followed by the TLV in error, copied from successful results MUST be followed by the TLV in error, copied from
the request. The AN MUST NOT do further processing of the request. the request. The AN MUST NOT do further processing of the request.
The AN MAY add a Status-Info TLV to provide further information on The AN MAY add a Status-Info TLV to provide further information on
the nature of the error. the nature of the error.
5. ANCP TLVs and Sub-TLVs The amount of information in the response to the Multicast Flow Query
Request may be very large. The AN MAY pass the information in a
series of Multicast Flow Query Response messages so that the control
channel to the NAS is not blocked for too long by transmission of a
single very large message. To support this, the receiver MUST set
the I flag and Submessage Number fields in the header of each
Multicast Flow Query Response message making up the complete response
in accordance with the usage of these fields as described in Section
3.1.1 of [RFC3292]. That is, the initial Multicast Flow Query
Response message in the sequence MUST have the I flag set (0x1) and
the Submessage Number field value equal to the total number of
messages making up the complete response. The remaining messages in
the sequence MUST have the I flag cleared (0x0) and the Submessage
Number field value set to the sequence number of the message within
the complete sequence, counting from 2 for the second message in the
sequence. Moreover, every message in the sequence except the last
one MUST have the Result field value equal to "More" (0x5). The
final message in the response MUST have the Result field set to
Success (0x3) or Failure (0x4) as the case may be. The ordering of
the messages in the sequence MUST be such that they present the
contents in the same order as if all of the information had been
presented in just one message, according to the rules described
above.
This section defines new ANCP TLVs and sub-TLVs or extends existing 5. ANCP TLVs For Multicast
ones.
This section defines new ANCP TLVs for the control of multicast
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 is illustrated in Figure 6. It The Multicast-Service-Profile TLV is illustrated in Figure 5. It
consists of a TLV header, a Multicast-Service-Profile-Name sub-TLV, consists of a TLV header encapsulating a single instance of the
and one or more List-Action sub-TLVs. The sub-TLVs are packed Multicast-Service-Profile-Name TLV and one or more instances of the
consecutively with no intervening padding. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Mcast Service Profile | TLV Length | |TLV Type = Mcast Serv Profile | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Service-Profile-Name Sub-TLV | | Multicast-Service-Profile-Name TLV |
| Sub-TLV type = 0x01 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action Sub-TLV | | List-Action TLV |
| Sub-TLV type = 0x02 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action Sub-TLV | | List-Action TLV |
| Sub-TLV type = 0x02 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Multicast-Servive-Profile TLV Figure 5: Multicast-Service-Profile TLV
Multicast Service Profile TLV Type: The Multicast-Service-Profile TLV has the following fields:
TLV (0x13) : indicating that this is a Multicast Service o The Multicast-Service-Profile TLV Type is 0x13.
Profile TLV
The Multicast-Service-Profile-Name sub-TLV is shown in Figure 7. It o The TLV length is determined by the contents following the TLV
consists of an eight-bit sub-TLV identifier with value 0x01, an header.
eight-bit length field, and an identifier. The length field gives
the length of the identifier in octets. The identifier consists of
an opaque sequence of octets used to refer to the profile when
activating it for a given target within a Port Management message
(see Section 4.2). The identifier MUST be unique over all profiles
provisioned to the same AN partition.
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 o The Multicast-Service-Profile-Name TLV is described in
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Section 5.2. The Multicast-Service-Profile-Name TLV MUST contain
| Type = 0x01 | Length | Identifier ... an identifier which is unique over all profiles provisioned to the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ same AN partition. This identifier will be used to refer to the
profile when activating it for a given target within a Port
Management message (see Section 4.2).
Figure 7: Multicast-Service-Profile-Name sub-TLV o The List-Action TLV is described in Section 5.3. The List-Action
TLV(s) provide the content of a newly defined multicast service
profile or modify the existing content. If more than one List-
Action TLV is present, the order of the TLVs may be significant,
since List-Action TLVs are processed in the order in whch they
appear.
The List-Action sub-TLV is shown in Figure 8. It consists of an 5.2. Multicast-Service-Profile-Name TLV
eight-bit sub-TLV identifier with value 0x02, a four-bit action
field, a four-bit list type field, a sixteen-bit length, and a
sequence of multicast flow fields organized by address family.
Either an IPv4 list or an IPv6 list or both MAY be present in the
sub-TLV.
1 2 3 The Multicast-Service-Profile-Name TLV carries the identifier of a
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 multicast service profile provisioned on the AN. It is illustrated
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in Figure 6.
| Type = 0x02 | Oper | LType | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Version | List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Version | List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: List-Action Sub-TLV 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = MSP Name | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields within the List-Action TLV are defined as follows: Figure 6: Multicast-Service-Profile-Name TLV
Type: always 0x02. The Multicast-Service-Profile-Name TLV has the following fields:
Oper: operation to be performed. The possible values are Add (0x1), o The Multicast-Service-Profile-Name TLV Type is 0x18.
Delete (0x2), or Replace (0x3). The operation indicates whether
the listed multicast flows are to be added to the list identified
by the list type field within the profile identified by the
Multicast-Service-Profile-Name sub-TLV, deleted from that list, or
whether the listed flows should replace the current contents of
the identified list.
Ltype: the list type being modified by this list action. The o TLV Length: up to 255 octets.
possible values are White (0x1), Black (0x2), or Grey (0x3).
Length: the length (in octets) of the contents of the List-Action o Multicast service profile identifier: an opaque sequence of bits
sub-TLV following the Length field itself. identifying a specific multicast service profile.
IP Version: the IP version of the set of multicast flow fields that The identifier could have the form of human-readable text or an
follow. Possible values are 0x0000 (IPv4) or 0x0001 (IPv6). As arbitrary binary value, depending on the operator's practices.
indicated above, either an IPv4 list or an IPv6 list or both MAY
be present in the sub-TLV.
List length: the length (in octets) of the list of multicast flow 5.3. List-Action TLV
fields following the list length field.
Multicast flow field: a field identifying one or more multicast The List-Action TLV identifies multicast flows to be added to or
removed from a list of White-, Black-, or Grey-listed flows. It is
meaningful only in association with a Multicast-Service-Profile-Name
TLV identifying the profile to which the List-Action TLV applies.
Such an association can be achieved by placing both TLVs in the same
base message payload or as embedded TLVs of another TLV such as the
Multicast-Service-Profile. The List-Action TLV is shown in Figure 7.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action TLV | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation | List Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: List-Action TLV
The List-Action TLV contains the following fields:
o The List-Action TLV Type is 0x21.
o TLV Length: length of the subsequent contents.
o Operation: operation to be performed upon the White, Black, or
Grey list identified by the List Type field within the profile
identified by the associated Multicast-Service-Profile-Name
embedded TLV. The possible values are:
* Add (0x01): the multicast flow fields are to be added to the
list.
* Delete (0x02): the multicast flow fields are to be removed from
the list. Each multicast flow field in the List-Action MUST
match exactly an existing entry in the list concerned. Thus to
remove part of the range provided by a wildcarded list entry,
it is necessary to remove the entire entry and add back the
remaining partial range(s).
* Replace (0x03): the multicast flow fields replace the existing
contents of the list.
o List Type: the list type being modified by this List-Action. The
possible values are White (0x01), Black (0x02), or Grey (0x03).
o Reserved: a sender MUST set this field to 0x0000. A receiver MUST
ignore the contents of this field.
o Address Family: the IP version of the set of multicast flow fields
that follow, encoded according to [PIMreg]. Possible values are
0x0001 (IPv4) or 0x0002 (IPv6). Either an IPv4 list or an IPv6
list or both MAY be present in the List-Action TLV.
o Number of flow fields: the number of multicast flow fields of the
given address family which follow.
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 0-16 octet group prefix, and
a 0-16 octet source prefix, as shown in Figure 9. a 0-16 octet source prefix, as shown in Figure 8.
Each multicast flow field refers either to a Single Source Multicast Each multicast flow field refers either to a Source-Specific
(SSM) channel or to an Any Source Multicast (ASM) group. The scope Multicast (SSM) channel or to an Any Source Multicast (ASM) group.
of the designation may be broadened to multiple channels or groups The scope of the designation may be broadened to multiple channels or
through use of prefix length values smaller than the total address groups through use of prefix length values smaller than the total
length for the given address family. Multicast flow fields MUST be address length for the given address family. Multicast flow fields
placed consecutively within the sub-TLV without intervening padding MUST be placed consecutively within the embedded TLV without
except to round out individual addresses to the nearest octet intervening padding except to round out individual addresses to the
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 8:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 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 8: 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 0x00 for either the Group PrefLen (prefix length) or the A value of 0x00 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 0x00 is provided for a will match (wild card). If the value 0x00 is provided for a
particular prefix length, the corresponding prefix MUST be omitted particular prefix length, the corresponding prefix MUST be omitted
from the field contents. In particular, a value of 0x00 for the from the field contents. In particular, a value of 0x00 for the
Source PrefLen indicates an ASM multicast entry, and the Source Source PrefLen indicates an ASM multicast entry, and the Source
Prefix will be absent. Prefix will be absent.
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.2. Command Number TLV 5.4. Sequence-Number TLV
The Command Number TLV conveys the sequence number of a specific The Sequence-Number TLV conveys a sequence number of some sort. The
specific meaning of the sequence number is message-specific. Within
this specification, the Sequence-Number TLV is used as a embedded TLV
within a Status-Info TLV, in a Generic Response reporting a failed
command within a Multicast Replication Control or Multicast Admission command within a Multicast Replication Control or Multicast Admission
Request message. Within this specification, the Command Number TLV Request message. It identifies the sequence number within the
itself is used as a sub-TLV within a Status-Info TLV, in a Generic message of the command that failed.
Response reporting a failed command.
The Command TLV has the format shown in Figure 10. The sequnce The Sequence-Number TLV has the format shown in Figure 9.
number field is the sequence number of a specific command within a
request, where numbering starts from 1 for the first command.
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 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|TLV Type = Command Number | TLV Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = Sequence-Number | TLV Length = 4 |
| Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Structure of the Command Number TLV Figure 9: Sequence-Number TLV
5.3. Bandwidth-Allocation TLV The Sequence-Number TLV has the following fields:
o The Sequence-Number TLV Type is 0x22.
o TLV length is 0x0004.
o Sequence number: the sequence number of a specific entity within a
series, where numbering starts from 1 for the first entity in the
series. Represented as a 32-bit binary number, most significant
bit first.
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. The TLV Type for the Bandwidth-Allocation format shown in Figure 10.
TLV is 0x15.
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 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|TLV Type = BW-Allocation | TLV Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = BW-Allocation | TLV Length = 4 |
| Delegated amount (kbits/s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delegated amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: The Bandwidth-Allocation TLV Figure 10: The Bandwidth-Allocation TLV
5.4. White-List-CAC TLV The Bandwidth-Allocation TLV has the following fields:
o The Bandwidth-Allocation TLV Type is 0x15.
o TLV length is 4.
o Delegated amount: the bandwidth amount delegated to the AN for
admission of multicast video on a given port, kilobits per second.
Presented as a 32-bit binary value, most significant bit first.
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 11.
The White-List-CAC TLV contains no data, thus its TLV Length field 1 2 3
MUST have value 0. 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 = White-List-CAC | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5. MRepCtl-CAC TLV Figure 11: White-List-CAC TLV
The White-List-CAC TLV contains the following fields:
o The White-List-CAC TLV Type is 0x24.
o TLV length is 0, since the TLV contains no data other than the TLV
header.
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. provisioned are specified in Section 6. The MRepCtl-CAC TLV is
illustrated in Figure 12.
The MRepCtl-CAC TLV contains no data, thus its TLV Length field MUST 1 2 3
have value 0. 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 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.6. Bandwidth-Request TLV Figure 12: MRepCtl-CAC TLV
The MRepCtl-CAC TLV contains the following fields:
o The MRepCtl-CAC TLV Type is 0x25.
o TLV length is 0, since the TLV contains no data other than the TLV
header.
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 12. The TLV The Bandwidth-Request TLV has the format shown in Figure 13.
Type for the Bandwidth-Request TLV is 0x16.
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 = 0x16 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: The Bandwidth-Request TLV
5.7. Multicast-Service-Profile-Name TLV
The Multicast-Service-Profile-Name TLV carries the identifier of a
multicast service profile provisioned on the AN.
o Type (Multicast-Service-Profile-Name = 0x18): Reference to a 1 2 3
multicast service profile on the AN, that defines a White, Black, 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
and/or Grey List depending on the set of negotiated capabilities. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Request | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Length : (up to 255 octets) Figure 13: The Bandwidth-Request TLV
o Value : opaque sequence of octets identifying a specific profile. The Bandwidth-Request TLV has the following fields:
This MUST match one of the multicast service profile names
provisioned on the AN in a Provisioning message or by other means.
5.8. Request-Source-IP sub-TLV o The Bandwidth-Request TLV Type is 0x16.
[I-D.ietf-ancp-protocol] defines the Command TLV that can be used in o The TLV length is 8 octets.
a Multicast Replication Control message and (as defined in this
document) in the Admission Control message. The Command TLV MAY
include sub-TLVs immediately following the Command Info field.
This document defines the new Request-Source-IP sub-TLV. o Required amount: the minimum or maximum amount, depending on
whether the sender is the AN or the NAS respectively, of delegated
video bandwidth that is being requested, in kilobits per second.
Presented as a 32-bit binary value, most significant bit first.
The Request-Source-IP sub-TLV MAY be included in a Command TLV inside o Preferred amount: the preferred amount of delegated video
an Admission Control message. bandwidth that is being requested, in kilobits per second.
Presented as a 32-bit binary value, most significant bit first.
The Request-Source-IP sub-TLV is illustrated below: 5.9. Request-Source-IP TLV
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 The Request-Source-IP TLV provides the IP address of the entity that
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ originated a specific request to join or leave a multicast channel.
|sub-TLV Type = Request-Source-IP | Request-S-IP sub-TLV Length | The TLV is illustrated in Figure 14.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request-Source-IP sub-TLV Type: 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Request-Source-IP | TLV length = 4 or 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
sub-TLV (0x92) indicating the contents to be a Request- Figure 14: Request-Source-IP TLV
Source-IP sub-TLV.
Request-Source-IP sub-TLV Length: The Request-Source-IP TLV contains the following fields:
Combined length in bytes of the data inside sub-TLV. o The Request-Source-IP TLV Type is 0x92.
Excludes the sub-TLV Header.
Address Family, Encoding type and Unicast Address: o TLV length is 4 for an IPv4 address or 16 for an IPv6 address.
Contains the IP address of the sender of the join/leave o Unicast address: IP address of the source of a multicast flow join
message (e.g. IGMP/MLD Join/Leave) that triggered the AN request, in network byte order.
to include the corresponding Command TLV in an Admission
Control message. The IP address is encoded as per
[IANAAEA].
5.9. Request-Source-MAC sub-TLV 5.10. Request-Source-MAC TLV
This document defines the new Request-Source-MAC sub-TLV. The Request-Source-MAC TLV provides the MAC address of the entity
that originated a specific request to join or leave a multicast
channel. The TLV is illustrated in Figure 15.
The Request-Source-MAC sub-TLV MAY be included in a Command TLV 1 2 3
inside an Admission Control message. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type=Request-Source-MAC | TLV Length = 6 or 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IEEE MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Request-Source-MAC sub-TLV is illustrated below: Figure 15: Request-Source-MAC TLV
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 The Request-Source-MAC TLV contains the following fields:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|sub-TLV Type=Request-Source-MAC |Request-S-MAC sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request-Source-MAC sub-TLV Type: o The Request-Source-MAC TLV Type is 0x93.
sub-TLV (0x93) indicating the contents to be a Request- o TLV length is either 6 octets (MAC-48 or EUI-48) or 8 octets
Source-MAC sub-TLV. (EUI-64).
Request-Source-MAC sub- TLV Length: o IEEE MAC Address: MAC address of the device originating the
request to join a multicast flow. Within the address, bytes and
bits respectively shall be ordered from most to least significant,
consistently with [IEEE48] for MAC-48 and EUI-48, and with
[IEEE64] for EUI-64.
Combined length in bytes of the data inside sub-TLV. EUI-48 and EUI-64 are registered trademarks of the IEEE.
Excludes the sub-TLV Header.
TBD: 5.11. Multicast-Flow TLV
Contains the IEEE MAC address of the sender of the join/ The Multicast-Flow TLV specifies a multicast flow in terms of its
leave message (e.g. IGMP/MLD Join/Leave) that triggered multicast group address and, if applicable, its unicast source
the AN to include the corresponding Command TLV in an address. It is illustrated in Figure 16.
Admission Control message. The IP address is encoded as
per TBD.
5.10. Multicast-Flow TLV 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Multicast-Flow | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Addr Family | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Unicast Source Address (for SSM flows only) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document defines the new Multicast-Flow TLV. Figure 16: Multicast-Flow TLV
The Multicast-Flow TLV MAY be included in a Multicast Flow Query The Multicast-Flow TLV has the following fields:
Request or Response message as specified in Section 4.9.
The Multicast-Flow TLV is illustrated below: o The Multicast-Flow TLV Type is 0x19.
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 o TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow) to
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 36 (for an IPv6 SSM flow.
|TLV Type = Multicast-Flow | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Multicast Flow Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Flow Source Address (Cont'd) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Multicast Flow Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Flow Group Address (Cont'd) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding to 32-bit boundary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multicast-Flow TLV o Flow Type: 0x01 for Any Source Multicast (ASM), 0x02 for Specific-
Source Multicast (SSM).
Multicast-Flow TLV Type: o Addr Family: address family of the multicast source and group
addresses, encoded in accordance with the IANA PIM Address Family
registry ([PIMreg]). 0x01 indicates IPv4, 0x02 indicates IPv6.
TLV (0x19) : indicating that this is a Multicast-Flow TLV o Reserved: MUST be set to 0x0000 by the sender and MUST be ignored
by the receiver.
Multicast-Flow TLV Length: One possible use for this field in the future is to indicate
the presence of PIM Join attributes attached to the source
address (see [RFC5384]). The applicability of PIM attributes
in the context of ANCP is for further study.
Length in bytes of the Value field of the TLV. Excludes o Multicast Group Address: a multicast group address within the
the TLV Header (Type and Length). given address family. The group address MUST always be present.
Addr Family, Encoding Type, Multicast Flow Source Address, Multicast o Unicast Source Address: unicast address within the given address
Flow Group Address and Padding are encoded as specified for the family. If the Flow Type is 0x01 (ASM), a source address MUST NOT
corresponding field of the Command TLV in Section 4.3. be present. If the Flow Type is 0x02 (SSM), a source address MUST
be present.
6. Multicast Capabilities 6. Multicast Capabilities
Section 5.3 of [I-D.ietf-ancp-protocol] defines a capability Section 5.3 of [I-D.ietf-ancp-protocol] defines a capability
negotiation mechanism as well as a number of capabilities. This negotiation mechanism as well as a number of capabilities. This
section defines four new capabilities in support of different modes section defines four new capabilities in support of different modes
of multicast operation: of multicast operation:
o NAS-initiated replication (capability type 0x05); o NAS-initiated replication (capability type 0x05);
skipping to change at page 46, line 36 skipping to change at page 47, line 36
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.
Note that if a request contains content that is not supported Note that if a request contains content that is not supported
(according to the tables in Section 6.1) by the negotiated set of (according to the tables in Section 6.1) by the negotiated set of
multicast capabilities, the appropriate response is to return a multicast capabilities, the appropriate response is to return a
Generic Response message indicating Failure (0x4) with an appropriate Generic Response message indicating Failure (0x4) with an appropriate
code value (e.g., 0x84 "TLV or value not supported by negotiated code value (e.g., 84 "TLV or value not supported by negotiated
capability set"). The body of the message MUST contain a Status-Info capability set"). The body of the message MUST contain a Status-Info
TLV. See Sections 5.4.5.1 and 5.4.5.2 in [I-D.ietf-ancp-protocol] TLV. See Sections 5.4.5.1 and 5.4.5.2 in [I-D.ietf-ancp-protocol]
for more details. for more details.
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 four 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.
6.1.1. Protocol Requirements For NAS-initiated Replication 6.1.1. Protocol Requirements For NAS-initiated 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. replication multicast capability.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Reference | Protocol Element | | Reference | Protocol Element |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with MRepCtl_CAC TLV | | Section 4.1 | Provisioning message with MRepCtl-CAC TLV |
| | | | | |
| Section 4.2 | Port Management message with Bandwidth-Allocation | | Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV. | | | TLV. |
| | | | | |
| Section 4.3 | Multicast Replication Control message | | Section 4.3 | Multicast Replication Control message |
| | | | | |
| Section 4.9 | Multicast Flow Query Request and Response messages | | Section 4.9 | Multicast Flow Query Request and Response messages |
| | | | | |
| Section 5.2 | Command Number TLV | | Section 5.4 | Command Number TLV |
| | | | | |
| Section 5.5 | MRepCtl-CAC TLV | | Section 5.7 | MRepCtl-CAC TLV |
| | | | | |
| Section 5.10 | Multicast-Flow TLV | | Section 5.11 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 1: Protocol Support Requirements For NAS-initiated Replication Table 1: Protocol Requirements For NAS-initiated Replication
6.1.2. Protocol requirements For Conditional Access With White and 6.1.2. Protocol Requirements For Conditional Access With White and
Black Lists Black Lists
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 conditional access Section 5 that MUST be implemented to support the conditional access
with white and black lists multicast capability. with white and black lists multicast capability.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Reference | Protocol Element | | Reference | Protocol Element |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with | | Section 4.1 | Provisioning message with |
| | Multicast-Service-Profile TLV, White and Black | | | Multicast-Service-Profile TLV, White and Black |
| | lists only, and White-List-CAC TLV | | | lists only, and White-List-CAC TLV |
| | | | | |
| Section 4.2 | Port Management message with | | Section 4.2 | Port Management message with |
| | Multicast-Service-Profile-Name and | | | Multicast-Service-Profile-Name and |
| | Bandwidth-Allocation TLVs. | | | Bandwidth-Allocation TLVs. |
| | | | | |
| Section 4.9 | Multicast Flow Query Request and Response messages | | Section 4.9 | Multicast Flow Query Request and Response messages |
| | | | | |
| Section 5.1 | Multicast-Service-Profile TLV, White and Black | | Section 5.1 | Multicast-Service-Profile TLV |
| | lists only |
| | | | | |
| Section 5.3 | Bandwidth-Allocation TLV | | Section 5.2 | Multicast-Service-Profile-Name TLV |
| | | | | |
| Section 5.4 | White-List-CAC TLV | | Section 5.3 | List-Action TLV, White and Black lists only |
| | | | | |
| Section 5.7 | Multicast-Service-Profile-Name TLV | | Section 5.5 | Bandwidth-Allocation TLV |
| | | | | |
| Section 5.10 | Multicast-Flow TLV | | Section 5.6 | White-List-CAC TLV |
| | |
| Section 5.11 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 2: Protocol Support Requirements For Conditional Access with Table 2: Protocol Requirements For Conditional Access with White and
White and Black Lists Black Lists
6.1.3. Protocol requirements For Conditional Access With Grey Lists 6.1.3. Protocol Requirements For Conditional Access With Grey Lists
Table 3 specifies the protocol elements within Section 4 and Table 3 specifies the protocol elements within Section 4 and
Section 5 that must be implemented to support the conditional access Section 5 that MUST be implemented to support the conditional access
with grey lists multicast capability. with grey lists multicast capability.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Reference | Protocol Element | | Reference | Protocol Element |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with | | Section 4.1 | Provisioning message with |
| | Multicast-Service-Profile TLV, Grey lists only, | | | Multicast-Service-Profile TLV, Grey lists only, |
| | and MRepCtl_CAC TLV | | | and MRepCtl-CAC TLV |
| | | | | |
| Section 4.2 | Port Management message with | | Section 4.2 | Port Management message with |
| | Multicast-Service-Profile-Name and | | | Multicast-Service-Profile-Name and |
| | Bandwidth-Allocation TLVs. | | | Bandwidth-Allocation TLVs. |
| | | | | |
| Section 4.3 | Multicast Replication Control message | | Section 4.3 | Multicast Replication Control message |
| | | | | |
| Section 4.4 | Multicast Admission Control Message | | Section 4.4 | Multicast Admission Control Message |
| | | | | |
| Section 4.9 | Multicast Flow Query Request and Response messages | | Section 4.9 | Multicast Flow Query Request and Response messages |
| | | | | |
| Section 5.1 | Multicast-Service-Profile TLV, Grey lists only | | Section 5.1 | Multicast-Service-Profile TLV, Grey lists only |
| | | | | |
| Section 5.2 | Command Number TLV | | Section 5.2 | Multicast-Service-Profile-Name TLV |
| | | | | |
| Section 5.3 | Bandwidth-Allocation TLV | | Section 5.3 | List-Action TLV, Grey lists only |
| | | | | |
| Section 5.5 | MRepCtl-CAC TLV | | Section 5.4 | Command Number TLV |
| | | | | |
| Section 5.7 | Multicast-Service-Profile-Name TLV | | Section 5.5 | Bandwidth-Allocation TLV |
| | | | | |
| Section 5.8 | Request-Source-IP sub-TLV | | Section 5.7 | MRepCtl-CAC TLV |
| | | | | |
| Section 5.9 | Request-Source-MAC sub-TLV | | Section 5.9 | Request-Source-IP TLV |
| | | | | |
| Section 5.10 | Multicast-Flow TLV | | Section 5.10 | Request-Source-MAC TLV |
| | |
| Section 5.11 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 3: Protocol Support Requirements For Conditional Access with Table 3: Protocol Requirements For Conditional Access with Grey Lists
Grey Lists
6.1.4. Protocol requirements For Delegated Bandwidth 6.1.4. Protocol Requirements For Delegated Bandwidth
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 delegated bandwidth Section 5 that MUST be implemented to support the delegated bandwidth
multicast capability. multicast capability.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Reference | Protocol Element | | Reference | Protocol Element |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Section 4.2 | Port Management message with Bandwidth-Allocation | | Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV. | | | TLV. |
| | | | | |
| Section 4.5 | Bandwidth Reallocation Request Message | | Section 4.5 | Bandwidth Reallocation Request Message |
| | | | | |
| Section 4.6 | Bandwidth Transfer Message | | Section 4.6 | Bandwidth Transfer Message |
| | | | | |
| Section 4.7 | Delegated Bandwidth Query Request Message | | Section 4.7 | Delegated Bandwidth Query Request Message |
| | | | | |
| Section 4.8 | Delegated Bandwidth Query Response Message | | Section 4.8 | Delegated Bandwidth Query Response Message |
| | | | | |
| Section 4.9 | Multicast Flow Query Request and Response messages | | Section 4.9 | Multicast Flow Query Request and Response messages |
| | | | | |
| Section 5.3 | Bandwidth-Allocation TLV | | Section 5.5 | Bandwidth-Allocation TLV |
| | | | | |
| Section 5.6 | Bandwidth-Request TLV | | Section 5.8 | Bandwidth-Request TLV |
| | | | | |
| Section 5.10 | Multicast-Flow TLV | | Section 5.11 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 4: Protocol Support Requirements For Delegated Bandwidth Table 4: Protocol Requirements For Delegated Bandwidth
6.2. Capability-Specific Procedures for Providing Multicast Service 6.2. Capability-Specific Procedures for Providing Multicast Service
This section describes multicast service procedures for each This section describes multicast service procedures for each
capability as if it were the only multicast capability within the capability as if it were the only multicast capability within the
negotiated set. Procedures involving combinations of multicast negotiated set. Procedures involving combinations of multicast
capabilities are described in Section 6.3. capabilities are described in Section 6.3.
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
skipping to change at page 50, line 52 skipping to change at page 52, line 5
6.2.1. Procedures For NAS-initiated Replication 6.2.1. Procedures For NAS-initiated Replication
NAS-initiated replication MAY be negotiated to support a mode of NAS-initiated replication MAY be negotiated to support a mode of
operation where IGMP/MLD requests are terminated on the NAS. operation where IGMP/MLD requests are terminated on the NAS.
Alternatively, it MAY be negotiated to allow the NAS to respond to Alternatively, it MAY be negotiated to allow the NAS to respond to
requests sent by other means (e.g., through application signalling) requests sent by other means (e.g., through application signalling)
that require the replication of multicast channels to a given access that require the replication of multicast channels to a given access
line. line.
The NAS MAY enable admission control at the AN for Nas-initiated 6.2.1.1. Provisioning
replication. To do this, it MUST include the MRepCtl-CAC TLV in a
Provisioning message sent to the AN. It MUST also include a The NAS MAY perform admission control for NAS-initiated replication.
Bandwidth-Allocation TLV in a Port Management message for each access In this case, it MUST NOT include the MRepCtl-CAC TLV in a
line. Provisioning message sent to the AN. Alternatively, the NAS MAY
enable admission control at the AN for NAS-initiated replication. To
do this, it MUST include the MRepCtl-CAC TLV in a Provisioning
message sent to the AN and it MUST also include a Bandwidth-
Allocation TLV in a Port Management message for each access line.
6.2.1.2. Multicast Service Procedures
The procedures associated with NAS-initiated replication are The procedures associated with NAS-initiated replication are
straightforward. To initiate replication, the NAS MUST send a straightforward. To initiate replication, the NAS MUST send a
Multicast Replication Control message to the AN, containing one or Multicast Replication Control message to the AN, containing one or
more commands adding flows, as described in section ReplicSend. If more commands adding flows, as described in Section 4.3.1. To
it does admission control itself, it MUST set the R flag in the Add terminate replication the NAS MUST send a Multicast Replication
commands. If it has enabled admission control in the AN and wishes Control message where the commands delete instead of adding the
the AN to perform admission control for the flows, it MUST clear the flows. The AN acts upon these messages as specified in
R flag in the Command TLV requesting the flow addition. To terminate Section 4.3.2.
replication the NAS MUST send a a Multicast Replication Control
message where the commands delete instead of adding them flows.
6.2.2. Procedures For Conditional Access With Black and White Lists 6.2.2. Procedures For Conditional Access With Black and White Lists
6.2.2.1. Provisioning 6.2.2.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. Service-Profile-Name TLV. The NAS MAY change the multicast service
profile for a given access line at any time by sending a Port
Management message identifying a new multicast service profile.
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 provisioning, which includes the White-List-CAC described in Section 4.1, which includes the White-List-CAC TLV and
TLV. It MUST also provide a multicast bandwidth allocation for each it MUST provide a multicast bandwidth allocation for each access line
access line by including a Bandwidth-Allocation TLV in a Port by including a Bandwidth-Allocation TLV in a Port Management message.
Management message.
6.2.2.2. Multicast Service Procedures 6.2.2.2. Multicast Service Procedures
The conditional access with White and Black lists capability assumes The conditional access with White and Black lists capability assumes
that IGMP/MLD requests are terminated on the AN. When the AN that IGMP/MLD requests are terminated on the AN. When the AN
receives a "join" request, it MUST check to see whether the requested receives a "join" request, it MUST check to see whether the requested
flow is White-listed or Black-listed as described below. Requests flow is White-listed or Black-listed as described below. Requests
for Black-listed flows MUST be discarded. If the NAS has enabled for Black-listed flows MUST be discarded. If the NAS has enabled
admission control on the given access line as described in the admission control on the AN as described in the previous section, but
previous section, but the flow would cause the amount of committed a White-listed flow would cause the amount of committed multicast
multicast bandwidth to exceed the provisioned limit, the request MUST bandwidth to exceed the provisioned limit, the request MUST be
be discarded. Flows passing these checks are replicated to the discarded. The AN replicates flows passing these checks to the
access line. access line.
To determine if a requested flow is White-listed, the AN searches for To determine if a requested flow is White-listed, the AN searches for
a best match to the flow in the applicable multicast service profile. a best match to the flow in the applicable multicast service profile.
Matching is done on the prefixes specified in the profile, ignoring Matching is done on the prefixes specified in the profile, ignoring
the address bits of lower order than those in the prefix. the address bits of lower order than those in the prefix.
If the requested multicast flow matches multiple lists associated If the requested multicast flow matches multiple lists associated
with the access line, then the most specific match will be considered with the access line, then the most specific match will be considered
by the AN. If the most specific match occurs in multiple lists, the by the AN. If the most specific match occurs in multiple lists, the
Black list entry takes precedence over the White list. In this Black list entry takes precedence over the White list. In this
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 flow address (i.e., on G of <S,G>) multicast flow address (i.e., on G of <S,G>)
o then, most specific match (longest prefix length) on the multicast 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
multicast service profile, the AN MUST review the status of active
flows on all ports to which the updated profile is currently
assigned. Similarly, if a Port Management message assigns a new
multicast service profile to a given port, the AN MUST review all
active flows on that port. If the most specific match for any flow
is a Black list entry, the flow MUST be terminated immediately. If
any of the remaining flows do not match an entry in the White list,
they also MUST be terminated immediately. White listed flows MUST be
allowed to continue.
6.2.3. Procedures For Conditional Access With Grey Lists 6.2.3. Procedures For Conditional Access With Grey Lists
6.2.3.1. Provisioning 6.2.3.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. Service-Profile-Name TLV. The NAS MAY change profiles on the line by
sending a subsequent Port Management message identifying a new
The NAS can enable admission control at the AN for Grey-listed flows. profile.
To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning The NAS MAY perform admission control for grey-listed flows. In that
message sent to the AN. It MUST also provide a Bandwidth-Allocation case, the NAS MUST NOT include the MRepCtl-CAC TLV in a Provisioning
TLV in a Port Management message for each access line. message sent to the AN. Alternatively, the NAS MAY enable admission
control at the AN for Grey-listed flows. To do this, it MUST include
the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST
also provide a Bandwidth-Allocation TLV in a Port Management message
for each access line.
6.2.3.2. Multicast Service Procedures 6.2.3.2. Multicast Service Procedures
The conditional access with Grey lists capability assumes that IGMP/ The conditional access with Grey lists capability assumes that IGMP/
MLD requests are terminated on the AN. When the AN receives a "join" MLD requests are terminated on the AN. When the AN receives a "join"
request, it MUST determine whether there is a match to the requested request, it MUST determine whether there is a match to the requested
flow in the Grey list of the multicast service profile provisioned flow in the Grey list of the multicast service profile provisioned
against the given access line. If there is no match, the request is against the given access line. If there is no match, the request is
discarded. Otherwise, the AN MUST send a Multicast Admission Control discarded. Otherwise, the AN MUST send a Multicast Admission Control
message to the NAS with content identifying the access line and the message to the NAS with content identifying the access line and the
multicast flow to be added. As indicated in Section 4.4, the AN MAY multicast flow to be added. As indicated in Section 4.4, the AN MAY
add information identifying the requestor by IP address and/or MAC add information identifying the requestor by IP address and/or MAC
address. address.
If the NAS decides to enable the flow, it MUST send a Multicast If the NAS decides to enable the flow, it MUST send a Multicast
Replication Control request to the AN to replicate the flow to the Replication Control request to the AN to replicate the flow to the
access line with the Result field set to Nack (0x1), as described in access line with the Result field set to Nack (0x1), as described in
section ReplicSend. If admission control has been enabled at the AN Section 4.3.1.
for flows added by Multicast Replication Control messages, the NAS
MAY invoke admission control for a specific flow at the AN by
clearing the R flag in the Command TLV that adds the flow.
When the AN receives the Multicast Replication Control request, it When the AN receives the Multicast Replication Control request, it
performs admission control if admission control has been enabled and performs admission control if admission control has been enabled as
invoked by the clearing of the R flag. If admitting the flow would described in the previous section. If admitting the flow would cause
cause the committed multicast bandwidth at the access line to exceed the committed multicast bandwidth at the access line to exceed the
the provisioned limit, the AN reports an error to the NAS as provisioned limit, the AN reports an error to the NAS as described in
described in section ReplicRecv. Otherwise it replicates the Section 4.3.2. Otherwise it replicates the multicast flow as
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
multicast service profile, the AN MUST review the status of active
flows on all ports to which the updated profile has been assigned.
Similarly, if a Port Management message that assigns a new profile to
a given port, the AN MUST review all active flows on that port. In
either case, if any flow does not match an entry in the Grey list, it
MUST be terminated immediately.
6.2.4. Procedures For Delegated Bandwidth 6.2.4. Procedures For Delegated Bandwidth
6.2.4.1. Provisioning 6.2.4.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. (If it fails to do so and a containing the Bandwidth-Allocation TLV.
value has not been provisioned on the AN by other means, the AN will
be forced to request a bandwidth allocation as soon as it receives a If it fails to do so and a value has not been provisioned on the
"join" request.) AN by other means, the AN will be forced to request a bandwidth
allocation as soon as it receives a "join" request.
The NAS MAY at any time force an update of the amount of delegated
bandwidth by the same means.
6.2.4.2. Multicast Service Procedures 6.2.4.2. Multicast Service Procedures
The delegated bandwidth capability assumes that IGMP/MLD requests are The delegated bandwidth capability assumes that IGMP/MLD requests are
terminated on the AN. When the AN receives a "join" request, it 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
skipping to change at page 54, line 46 skipping to change at page 56, line 29
As a further aid to synchronization, either the NAS or the AN MAY As a further aid to synchronization, either the NAS or the AN MAY
from time to time check the peer's view of the amount of delegated from time to time check the peer's view of the amount of delegated
bandwidth using the Delegated Bandwidth Query message. bandwidth using the Delegated Bandwidth Query message.
The NAS or AN MAY at any time release bandwidth to the peer using an The NAS or AN MAY at any time release bandwidth to the peer using an
autonomous Bandwidth Transfer message. The contents of this message autonomous Bandwidth Transfer message. The contents of this message
are described in Section 4.6. are described in Section 4.6.
6.3. Combinations of Multicast Capabilities 6.3. Combinations of Multicast Capabilities
6.3.1. Combination of NAS-Initiated Replication with Other Capabilities 6.3.1. Combination of Conditional Access With White and Black Lists and
Conditional Access With Grey Lists
NAS-initiated replication can coexist with the other capabilities,
but some means must exist to prevent double replication of flows.
The simplest way to do this is to terminate all IGMP/MLD requests on
the AN, so that NAS-initiated replication is stimulated by signalling
through other channels. Other arrangements are possible, but need
not be discussed here.
Assuming the necessary separation of responsibilities, the only point
of interaction between NAS-initiated replication and the other
multicast capabilities is in the area of admission control.
Specifically, inclusion of the MRepCtl-CAC TLV in a Provisiong
message enables admission control for flows added by Multicast
Replication Control messages, regardless of whether they are part of
NAS-initiated replication or Grey list multicast service processing.
The NAS can control whether the AN does admission control for
individual flows by its setting or clearing of the R flag in the
Command TLV. It is up to the NAS to choose how video bandwidth will
be allocated between itself and the AN, and to choose which
allocation must support specific requests.
6.3.2. Conditional Access With White, Black, and Grey Lists
If conditional access with White and Black lists is combined with If conditional access with White and Black lists is combined with
conditional access with Grey lists, provisioning of the multicast conditional access with Grey lists, provisioning of the multicast
service profiles is as described in Section 6.2.2.1 except that service profiles is as described in Section 6.2.2.1 except that
multicast service profiles will also include Grey lists. Admission multicast service profiles will also include Grey lists. Admission
control is enabled independently for White lists by including the control is enabled independently on the AN for White lists by
White-list-CAC TLV in the Provisioning message and for Grey lists by including the White-list-CAC TLV in the Provisioning message and for
including the MRepCtl-CAC TLV in the Provisioning message. The Grey lists by including the MRepCtl-CAC TLV in the Provisioning
Bandwidth-Allocation TLV provisions an amount that applies to both message. The Bandwidth-Allocation TLV provisions an amount that
White- and Grey- listed flows if admission control is enabled for applies to both White- and Grey- listed flows if admission control is
both. enabled for both.
With regard to multicast service procedures, one point of difference With regard to multicast service procedures, one point of difference
from the individual capabilities must be noted. This is an from the individual capabilities must be noted. This is an
interaction during the profile matching procedure. The AN MUST seek interaction during the profile matching procedure. The AN MUST seek
the best match amongst multiple lists as described in the best match amongst multiple lists as described in
Section 6.2.2.2. However, if there are multiple matches of equal Section 6.2.2.2. However, if there are multiple matches of equal
precision, the order of priority is Black list first, Grey list precision, the order of priority is Black list first, Grey list
second, and White list last. second, and White list last.
Once profile matching has been completed, processing of a "join" Once profile matching has been completed, processing of a "join"
request is as described in Section 6.2.2.2 for White or Black listed request is as described in Section 6.2.2.2 for White or Black listed
flows or Section 6.2.3.2 for Grey listed flows. Requests that do not flows or Section 6.2.3.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. Thus the AN needs to retain the fact that indicating the deletion. Thus the AN needs to retain the fact that
the flow was Grey-listed for the life of the flow. the flow was Grey-listed for the life of the flow.
6.3.3. Conditional Access Combined With Delegated Bandwidth If the AN receives a Provisioning message which updates an existing
multicast service profile, the AN MUST review the status of active
flows on all ports to which the updated profile is currently
assigned. Similarly, if a Port Management message assigns a new
multicast service profile to a given port, the AN MUST review all
active flows on that port. If any flow has its most specific match
in a Black list entry, it MUST be terminated immediately. If any of
the remaining flows do not match an entry in the White or Grey list,
they MUST also be terminated immediately. Finally, if any remaining
flows were originally admitted because they were White-listed, but
after the change they are Grey-listed, the AN MUST generate a
Multicast Flow Query response message autonomously as if it were
responding to a Multicast Flow Query request, listing all such flows.
These flows MUST be allowed to continue until the NAS or the
subscriber terminates them. Flows with their most specific match in
the White list MUST be allowed to continue.
If either or both conditional access capabilities are combined with The autonomously-generated Multicast Flow Query response message MUST
the delegated bandwidth capability, the AN always does admission be formatted as if it were a successful response to a request
control. Delegated bandwith simply provides a means for flexible containing no Target and no Multicast-Flow TLV, as described in
sharing of video bandwidth between the AN and the NAS or Policy Section 4.9.2, with the exception that the Transaction-Id MUST be set
Server. The provisioning, admission, and bandwidth management to all zeroes.
procedures of Section 6.2.4 apply in addition to the procedures in
Section 6.2.2, Section 6.2.3, or Section 6.3.2 as applicable. 6.3.2. Combination of Conditional Access With Delegated Bandwidth
The provisioning and bandwidth management procedures of Section 6.2.4
apply in addition to the procedures in Section 6.2.2, Section 6.2.3,
or Section 6.3.1 as applicable. Admission control follows the rules
for conditional access in terms of matching flows against White and
Black and/or Grey lists and performing or not performing bandwidth
checks at the AN, but the amount of bandwidth used by the AN to
perform admission control is negotiable as described in
Section 6.2.4.2.
6.3.3. Combination of NAS-Initiated Replication with Other Capabilities
NAS-initiated replication can coexist with the other capabilities,
but some means must exist to prevent double replication of flows.
The simplest way to do this is to terminate all IGMP/MLD requests on
the AN, so that NAS-initiated replication is stimulated only by
signalling through other channels. Other arrangements are possible,
but need not be discussed here.
Assuming the necessary separation of responsibilities, the only point
of interaction between NAS-initiated replication and the other
multicast capabilities is in the area of admission control.
Specifically, inclusion of the MRepCtl-CAC TLV in a Provisioning
message and the Bandwidth-Allocation TLV in a Port Management message
enables admission control by the AN for flows added by Multicast
Replication Control messages, regardless of whether they are part of
NAS-initiated replication or Grey list multicast service processing.
Conversely, non inclusion of the MRepCtl-CAC TLV in Provisioning
messages to the AN enables admission control by the NAS for flows
added by Multicast Replication Control messages, regardless of
whether they are part of NAS- initiated replication or Grey list
multicast service processing. Admission Control for white flows can
also be enabled independently on the AN by inclusion by the NAS of
the White-List-CAC TLV in the Provisioning message.
7. Security Considerations 7. Security Considerations
The security considerations of ANCP are discussed in The security considerations of ANCP are discussed in
[I-D.ietf-ancp-protocol] and in [I-D.ietf-ancp-security-threats]. [I-D.ietf-ancp-protocol] and in [I-D.ietf-ancp-security-threats].
[Probably need to say more, but will do so later.]
8. IANA Considerations 8. IANA Considerations
This document defines the following additional values within the This document defines the following additional values within the
GSMPv3 Message Type Name Space registry: GSMPv3 Message Type Name Space registry, under the new heading
"Multicast Extensions To ANCP/GSMPv3":
+--------------------------------+--------+---------------+ +---------------------------+---------------+--------+--------------+
| Message | Number | Source | | Message Name | Message | Status | Reference |
+--------------------------------+--------+---------------+ | | Number | | |
| Multicast Replication Control | 90 | This document | +---------------------------+---------------+--------+--------------+
| | | | | Multicast Replication | 144 | | This |
| Multicast Status | 91 | This document | | Control | | | document |
| | | | | | | | |
| Multicast Admission Control | 92 | This document | | Multicast Admission | 145 | | This |
| | | | | Control | | | document |
| Bandwidth Reallocation Request | 94 | This document | | | | | |
| | | | | Bandwidth Reallocation | 146 | | This |
| Bandwidth Transfer | 95 | This document | | Request | | | document |
| | | | | | | | |
| Delegated Bandwidth Query | 96 | This document | | Bandwidth Transfer | 147 | | This |
| | | | | | | | document |
| Multicast Flow Query | 97 | This document | | | | | |
+--------------------------------+--------+---------------+ | Delegated Bandwidth Query | 148 | | This |
| | | | document |
| | | | |
| Multicast Flow Query | 149 | | This |
| | | | document |
+---------------------------+---------------+--------+--------------+
This document defines the following values for the ANCP Status-Info This document defines the following additional values for the GSMPv3
Result Code Registry : Failure Response Message Name Space registry:
+----------------------------------------------+--------+-----------+ +-------+--------------------------------------------+--------------+
| Status | Number | Reference | | Value | Failure Response Message Name | Reference |
+----------------------------------------------+--------+-----------+ +-------+--------------------------------------------+--------------+
| Command not supported | 0x02 | This | | 100 | Command error. | This |
| | | document | | | | document |
| | | | | | | |
| Flag set but not supported | 0x03 | This | | 101 | Bad flow address. | This |
| | | document | | | | document |
| | | | | | | |
| Unsupported Address Family | 0x05 | This | | 102 | Multicast flow does not exist. | This |
| | | document | | | | document |
| | | | | | | |
| Malformed flow address | 0x06 | This | | 103 | Invalid preferred bandwidth amount. | This |
| | | document | | | | document |
| | | | | | | |
| Configuration error (such as Port not | 0x0a | This | | 104 | Inconsistent views of delegated bandwidth | This |
| enabled for multicast) | | document | | | amount. | document |
| | | | | | | |
| Multicast flow does not exist | 0x0b | This | | 105 | Bandwidth request conflict. | This |
| | | document | | | | document |
| | | | +-------+--------------------------------------------+--------------+
| Unsupported address encoding | 0x0c | This |
| | | document |
| | | |
| Additional info needed to execute command | 0x0d | This |
| (payload MAY contain an indication of the | | document |
| expected info) | | |
| | | |
| Multicast flow count exceeded | 0x0e | This |
| | | document |
| | | |
| M Flag set, but no IP Source address | 0x0f | This |
| provided | | document |
| | | |
| Invalid preferred bandwidth amount | 0x11 | This |
| | | document |
| | | |
| bandwidth delegation not activated | 0x12 | This |
| | | document |
| | | |
| Delegated bandwidth reset required | 0x13 | This |
| | | document |
+----------------------------------------------+--------+-----------+
This document defines the following additional values within the ANCP This document defines the following additional values within the ANCP
TLV Type Registry: TLV Type Registry:
+--------------------------------+-----------+---------------+ +--------------------------------+-----------+---------------+
| TLV Name | Type Code | Reference | | TLV Name | Type Code | Reference |
+--------------------------------+-----------+---------------+ +--------------------------------+-----------+---------------+
| Multicast-Service-Profile | 0x13 | This document | | Multicast-Service-Profile | 0x13 | This document |
| | | | | | | |
| Bandwidth-Delegation-Control | 0x14 | This document |
| | | |
| Bandwidth-Allocation | 0x15 | This document | | Bandwidth-Allocation | 0x15 | This document |
| | | | | | | |
| Bandwidth-Request | 0x16 | This document | | Bandwidth-Request | 0x16 | This document |
| | | | | | | |
| Bandwidth-Status | 0x17 | This document |
| | | |
| Multicast-Service-Profile-Name | 0x18 | This document | | Multicast-Service-Profile-Name | 0x18 | This document |
| | | | | | | |
| Multicast-Flow | 0x19 | This document | | Multicast-Flow | 0x19 | This document |
| | | |
| List-Action | 0x21 | This document |
| | | |
| Sequence-Number | 0x22 | This document |
| | | |
| White-List-CAC | 0x24 | This document |
| | | |
| MRepCtl-CAC | 0x25 | This document |
| | | |
| Request-Source-IP | 0x92 | This document |
| | | |
| Request-Source-MAC | 0x93 | This document |
+--------------------------------+-----------+---------------+ +--------------------------------+-----------+---------------+
This document defines the following values for the ANCP Command Code This document defines the following additional values for the ANCP
registry: Command Code registry:
+-------------------------------------+----------------+------------+ +-------------------------------------+----------------+------------+
| Command Code Directive Name | Command Code | Reference | | Command Code Directive Name | Command Code | Reference |
| | Value | | | | Value | |
+-------------------------------------+----------------+------------+ +-------------------------------------+----------------+------------+
| Add | 0x01 | This | | Add | 0x01 | This |
| | | document | | | | document |
| | | | | | | |
| Delete | 0x02 | This | | Delete | 0x02 | This |
| | | document | | | | document |
skipping to change at page 60, line 49 skipping to change at page 62, line 28
| Admission Control Reject | 0x04 | This | | Admission Control Reject | 0x04 | This |
| | | document | | | | document |
| | | | | | | |
| Conditional Access Reject | 0x05 | This | | Conditional Access Reject | 0x05 | This |
| | | document | | | | document |
| | | | | | | |
| Admission Control and Conditional | 0x06 | This | | Admission Control and Conditional | 0x06 | This |
| Access Reject | | document | | Access Reject | | document |
+-------------------------------------+----------------+------------+ +-------------------------------------+----------------+------------+
This document defines the following additional values to the ANCP This document defines the following additional values for the ANCP
sub-TLV Type registry: Capability registry:
+--------------------+-----------+---------------+ +-----------------------------------+------------------+------------+
| sub-TLV Name | Type Code | Reference | | Capability Type Name | Capability Type | Reference |
+--------------------+-----------+---------------+ | | Code | |
| Request-Source-IP | 0x92 | This document | +-----------------------------------+------------------+------------+
| | | | | NAS-initiated replication | 0x5 | This |
| Request-Source-MAC | 0x93 | This document | | | | document |
+--------------------+-----------+---------------+ | | | |
| Conditional access with white and | 0x6 | This |
| black lists | | document |
| | | |
| Conditional access with grey | 0x7 | This |
| lists | | document |
| | | |
| Bandwidth delegation | 0x8 | This |
| | | document |
+-----------------------------------+------------------+------------+
9. Acknowledgements 9. Acknowledgements
The authors would like to acknowledge Wojciech Dec for providing The authors would like to acknowledge Wojciech Dec for providing
useful input to this document, Robert Rennison for his help in useful input to this document, Robert Rennison for his help in
shaping the definition of the Multicast-Service-Profile TLV, Shridhar shaping the definition of the Multicast-Service-Profile TLV, Shridhar
Rao for his comments and suggestions and Aniruddha A for his proposal Rao for his comments and suggestions and Aniruddha A for his proposal
that formed the base of the Multicast Flow Reporting solution. that formed the base of the Multicast Flow Reporting solution.
Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided
substantial contributions on the solution for the NAS initiated substantial contributions on the solution for the NAS initiated
multicast control use case. multicast control use case.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ancp-framework] [I-D.ietf-ancp-framework]
Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks", Control Mechanism in Broadband Multi-Service Networks",
draft-ietf-ancp-framework-12 (work in progress), draft-ietf-ancp-framework-13 (work in progress),
October 2009. February 2010.
[I-D.ietf-ancp-protocol] [I-D.ietf-ancp-protocol]
Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., Voigt, Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., Voigt,
N., and R. Maglione, "Protocol for Access Node Control N., and R. Maglione, "Protocol for Access Node Control
Mechanism in Broadband Networks", Mechanism in Broadband Networks",
draft-ietf-ancp-protocol-07 (work in progress), draft-ietf-ancp-protocol-09 (work in progress),
October 2009. February 2010.
[IEEE48] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/
EUI48.html", 2010.
[IEEE64] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html", 2010.
[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, Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999. October 1999.
[RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
"General Switch Management Protocol (GSMP) V3", RFC 3292,
June 2002.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ancp-security-threats] [I-D.ietf-ancp-security-threats]
Moustafa, H., Tschofenig, H., and S. Cnodder, "Security Moustafa, H., Tschofenig, H., and S. Cnodder, "Security
Threats and Security Requirements for the Access Node Threats and Security Requirements for the Access Node
Control Protocol (ANCP)", Control Protocol (ANCP)",
draft-ietf-ancp-security-threats-08 (work in progress), draft-ietf-ancp-security-threats-08 (work in progress),
July 2009. July 2009.
[I-D.morin-mboned-igmpmld-error-feedback] [I-D.morin-mboned-igmpmld-error-feedback]
Morin, T. and B. Haberman, "IGMP/MLD Error Feedback", Morin, T. and B. Haberman, "IGMP/MLD Error Feedback",
draft-morin-mboned-igmpmld-error-feedback-02 (work in draft-morin-mboned-igmpmld-error-feedback-02 (work in
progress), November 2008. progress), November 2008.
[IANAAEA] "http://www.iana.org/assignments/address-family-numbers", [PIMreg] IANA, "http://www.iana.org/assignments/pim-parameters/
2005. pim-parameters.xhtml", 2005.
[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.
Appendix A. Example of Messages and Message Flows [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format",
This section provides example message flows. RFC 5384, November 2008.
A.1. Multicast Conditional Access and CAC without AN bandwidth
delegation
This section describes ANCP operations when multicast flows are Appendix A. Example of Messages and Message Flows
subject to multicast Conditional Access and Admission Control without
bandwidth delegation.
A.1.1. List/Profile Provisioning This appendix provides an example in which most of the possible
message flows for multicast control are illustrated. This appendix
is for informational purposes only. In case of discrepancy with text
of the body of this document, the text in the body of the document is
to be considered as the normative text.
The AN provisioning is performed by NAS using a Provisioning message Assume the following, for a given access port:
that contains White/Black/Grey lists and their corresponding
"Multicast Service Profile Name". To indicate to the AN that it need
not perform any CAC operation on those flows, the Provisioning
message also conveys an indication that bandwidth delegation is to be
deactivated. The corresponding message flow is illustrated in
Figure 13.
+----------+ +---------+ +-----+ +-----+ o The basic subscribed service is white-listed. The AN will be
|Subscriber| | Home | | AN | | NAS | responsible for admission control for this service.
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | |(M1) Provisioning |
| | | (Mcast S Prof name, |
| | | White List, |
| | | Grey List, |
| | | Black List, |
| | | Bw Del Deactivated) |
| | |<--------------------|
Figure 13: Provisioning AN with White/Grey/Black Lists for o Some premium services are available, but requests for these
Conditional Access services must be referred to the policy server for proper credit
processing. For this reason they are grey-listed. The NAS will
be responsible for admission control for these services.
The Provisioning message M1 contains: o The subscriber has asked that certain services be blocked so that
his children cannot view them. These services are black-listed.
o an ANCP Header with: o All of the above services are Source-Specific Multicast (SSM). In
addition, by means which bypass the AN, the subscriber can signal
intent to join an on-line game service which is Any-Source
Multicast (ASM). The NAS is responsible for admission control for
this service.
* Message-Type = 93 - Provisioning o Bandwidth delegation is in effect to share video bandwidth between
the AN and the NAS.
* Result= 0x00 The stated conditions require the use of all four of the capabilities
specified in this memo.
* Transaction-ID = Transaction-ID maintained by NAS A.1. Provisioning Phase
o a Multicast-Service-Profile TLV containing: Assume that capability negotiation has been completed between the AN
and NAS and that the set of negotiated capabilities includes the
following four multicast capabilities: NAS-initiated replication,
conditional access with white and black list, conditional access with
grey list, and bandwidth delegation. At this point, the NAS can
provision the service profiles on the AN and enable admission control
at the AN for white-listed flows. To do this, the NAS sends the AN a
Provisioning message containing this information. An example message
providing the profile for our assumed subscriber is shown in
Figure 17. The message has the following contents:
* a Multicast-Service-Profile-Name sub-TLV o Message type is 93.
* an Empty White-List in our example (and hence no White-List o The Result and Code fields in the header are set to zeroes, as
sub-TLV) specified in the ANCP base protocol document.
* a Grey-List sub-TLV containing a catch-all entry for IPv4 (in o A Transaction identifier is assigned by the NAS.
our example)
* an Empty Black-List in our example (and hence no Black-List o The Multicast-Service-Profile TLV (of which typically there would
sub-TLV) be multiple instances) contains a Multicast-Service-Profile-Name
TLV (with a length of 20 octets assumed for the example) and three
List-Action TLVs, one each for the White, Grey, and Black lists
within the profile. The White list flows come in two sets of
group addresses: 233.252.0.0/29, coming from a server at
192.0.2.15, and 233.252.0.32/29, coming from a server at
192.0.2.16. The Grey listed flows are in the band
233.252.0.64/29, coming from a server at 192.0.2.21. Finally, the
Black list flows are two individual flows that happen to overlap
with the Grey list band: 233.252.0.65, and 233.252.0.69, also with
source 192.0.2.21.
The Provisioning message M1 is illustrated below: o The White-List-CAC TLV indicates that the AN does admission
control on White-listed flows.
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 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length = 132 |
| Vers | Sub |MessageType=93 | 0x00 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | Msg Type = 93 | 0x00 | Code = 0x000 |
| Partition ID | Transaction Identifier = 0008 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier |
|I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length = 132 |
| Mcast-Service-Prof TLV Type | Mcast-Service-Prof TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M-Serv-Prof TLV Type = 0x13 | TLV Length = 112 |
| sub-TLV Type = 0x0001 | sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M-S-Prof-Name TLV Type = 0x18 | Embedded TLV Length = 20 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Multicast service profile name ~ | Multicast service profile name |
| | ~ = "Cust 0127-53681-0003" ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| sub-TLV Type = 0x0003 | sub-TLV Length = 0x06 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List-Action TLV Type = 0x21 | Embedded TLV Length = 28 |
| IP ver = 0x00 | List length = 0x02 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Oper = 0x01 |Lst Typ = 0x01 | Reserved = 0x0000 |
| Grp PLen=0x00 | Src PLen=0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family = 0x01 | List Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G Preflen = 29| S Preflen = 32| Group prefix = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 233.252.0.0 | Source prefix = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.15 | G Preflen = 29| S Preflen = 32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group prefix = 233.252.0.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source prefix = 192.0.2.15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action TLV Type = 0x21 | Embedded TLV Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Oper = 0x01 |Lst Typ = 0x03 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 0x01 | List Length = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G Preflen = 29| S Preflen = 32| Group prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 233.252.0.64 | Source prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 192.0.2.21 | Padding = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action TLV Type = 0x21 | Embedded TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Oper = 0x01 |Lst Typ = 0x02 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 0x01 | List Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G Preflen = 32| S Preflen = 32| Group prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 233.252.0.65 | Source prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 192.0.2.21 | G Preflen = 32| S Preflen = 32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group prefix = 233.252.0.69 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source prefix = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|White-List-CAC TLV Type = 0x24 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14 TLV lengths are given in decimal for easier understanding. 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 included in
the length of that List-Action TLV. Note also that the Length field
in the message header, unlike those in the TLVs, includes the message
header itself, as required by [RFC3292]. Finally, note that the
Provisioning message does not include a MRepCtl-CAC TLV since in our
example admission control for Grey listed flows and for NAS-initiated
replication is performed by the NAS.
A.1.2. Profile Mapping Figure 17: Example Provisioning Message
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_MNGT 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. The corresponding message flow is associated to that port along with the initial amount of delegated
illustrated in Figure 15. bandwidth. The corresponding message flow is illustrated in
Figure 18.
+----------+ +---------+ +-----+ +-----+ +----------+ +---------+ +-----+ +-----+
|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)|
| | |<--------------------| | | |<--------------------|
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Autorization/Policy Server Autorization/Policy Server
Figure 15: Associating Profile ID to AN Port Figure 18: Configuring an AN Port With Multicast Service Profile ID
and Delegated Bandwidth amount
A.1.3. Successful Join/Leave Operations The Port Management message will typically contain other TLVs but our
example (Figure 19) just shows the Target, Multicast-Service-Profile-
Name, and Bandwidth-Allocation TLVs. The Target TLV identifies the
subscriber line, the Multicast-Service-Profile-Name TLV is identical
to the one contained in the Provisioning message, and the Bandwidth-
Allocation TLV provides just enough bandwidth (2000 kbits/s) for one
channel to start with.
The message flows in Figure 16 illustrates the ANCP message flow in The following fields in the Port Management message header are shown
case of a simple join and leave for a multicast flow that matches the with specific values either as directed by the base protocol document
grey list and when the "bandwidth delegation" mechanism is not or for the sake of our example:
activated in the AN. In that case the AN queries the NAS that
performs Conditional Access and Admission Control. o Message Type is 32.
o Result is set to Nack (0x01) for this example.
o Code is 0x000.
o Port is set to 0.
o Event Sequence Number, the R flag and the other bits marked x,
Duration, the Event Flags, and the Flow Control Flags are all
irrelevant for this function and are set to 0.
o Function is set to 0x8, "Configure Connection Service Data".
o X-Function is set to 0.
o Tech Type is 0x05 (DSL).
o Block lengths are calculated assuming a Circuit-Id length of 4 in
our example. Recall that the example Multicast-Service-Profile-
Name TLV length is 20.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length = 84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type = 32 | 0x01 | Code = 0x000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Duration = 0 | Function = 0x8| X-Function = 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Flow Control Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Msg Type = 32 |Tech Type=0x05 | Blk Len = 56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs = 3 | Extension Block length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target TLV Type = 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M-S-Prof-Name TLV Type = 0x18 | TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile name |
~ = "Cust 0127-53681-0003" ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BW Alloc TLV Type = 0x15 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth value = 0x000007D0 (2000 kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Example Port Management Message
A.2. Handling a Grey-Listed Flow
Suppose now that the subscriber chooses to watch the premium channel
characterized by source 192.0.2.21, group 233.252.0.67. Upon
receiving the Join request, the AN matches it against the multicast
service profile for the port and determines that it is a Grey-listed
flow. Figure 20 illustrates the resulting ANCP message flow for the
case of a simple join and leave, when admission control for Grey-
listed flows is not activated on the AN. To start the flow, the AN
sends a Multicast Admission Control request (M1) to the NAS. The NAS
decides whether flow can be admitted, applying both policy and
bandwidth criteria. It returns its decision (positive in this
example) in a Multicast Replication Control message (M2). Later,
when the subscriber leaves the flow, the AN informs the NAS by
sending another Multicast Admission Control message.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS | |Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | | | | | Multicast |
| Join(Grey-Fl) | Admission | | Join(Grey-Fl) | Admission |
|-----------+---------->| Control (M1) | |-----------+---------->| Control (M1) |
| | |------------------>| | | |------------------>|
| | | | | | | | (NAS performs
| | | Multicast | | | | Multicast | admission
| | | Replication (*) | | | Replication (*) control)
| | | Control (M2) | | | | Control (M2) |
| Mcast Grey Flow |<------------------| | Mcast Grey Flow |<------------------|
|<======================+ | |<======================+ |
| | | | | | | |
~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | 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
(bandwidth delegation not activated on AN)
(*) 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 16: Successful Join/Leave Operations Figure 20: 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 = 92 - Multicast Admission Control * Message-Type = 145 - Multicast Admission Control;
* Result= 0x00 * Result= 0x0 (Ignore);
* Transaction-ID = Transaction-ID maintained by AN * Transaction-ID = Transaction-ID maintained by 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:
* a Command Code = Add * Command Code = Add (0x01);
* R = 0
* O = 0 * Accounting = 0;
* the multicast flow for which the IGMP Join was received by AN= * a Multicast-Flow embedded TLV indicating the SSM multicast flow
(192.0.2.1, 233.252.2.2) (Flow Type = 0x02) for which the AN received the IGMP Join:
IPv4 (0x01) Group address= 233.252.0.67, IPv4 (0x01) Source
Address = 192.0.2.21;
* a Request-Source-IP sub-TLV containing the IGMP join source IP * a Request-Source-IP embedded TLV containing the IGMP join
(192.0.2.100). source IP (192.0.2.100).
The Multicast Admission Control message M1 is illustrated below: The Multicast Admission Control message M1 is illustrated below:
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 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length = 98 |
| Vers | Sub |MessageType=92 | 0x00 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | Msg Type=145 | 0x0 | Code = 0x000 |
| Partition ID | Transaction Identifier = 0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier |
|I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length = 98 |
| Type = 0x1000 (Target) | Target TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x1000 (Target) | Target TLV Length = 8 |
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Access Loop Circuit ID ~ | Access Loop Circuit ID |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command TLV Type = 0x11 | TLV Length = 28 |
| Type = 0xTBD (Command) TLV | Command-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cmd Code=0x01 |Acctg = 0x00 | Reserved = 0x0000 |
| Cmd Code=0x01 |0 0 1 | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 |
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 |
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ | Multicast Group Address = 233.252.0.67 |
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast Source Address = 192.0.2.21 |
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ | Req-Src-IP TLV Type = 0x92 | Embedded TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Address = 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 90 - Multicast Replication Control * Message Type = 144 - Multicast Replication Control;
* Result= 0x00 * Result= 0x1 (NAck);
* Transaction-ID = Transaction-ID maintained by NAS * Transaction-ID = Transaction-ID maintained by 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:
* a Command Code = Add * Command Code = Add (0x01);
* R= 1 (since in our example the flow resources have been
admitted by NAS)
* O = 0 (since in our example flow accounting is not required) * Accounting = 1 (begin flow accounting), since in our example
the operator wants accounting on this flow.
* the multicast flow for which the IGMP Join was received by AN= * a Multicast-Flow embedded TLV indicating the SSM multicast flow
(192.0.2.1, 233.252.2.2) (Flow Type = 0x02) that the NAS is admitting for this access
port: IPv4 (0x01) Group address= 233.252.0.67, IPv4 (0x01)
Source Address = 192.0.2.21.
* a Request-Source-IP sub-TLV containing the IGMP join source IP The Multicast Admission Control message M2 is illustrated below.
(192.0.2.100).
The Multicast Admission Control message M2 is illustrated below: 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length = 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type=144 | 0x1 | Code = 0x000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command TLV Type = 0x11 | TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 | Acctg = 0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Figure 21: Multicast Replication Control Message Admitting A Flow
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=90 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0009 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xTBD (Command) TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 |1 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
The Multicast Admission Control message M3 contains: The Multicast Admission Control message M3 advising the NAS that the
flow has been terminated contains:
o an ANCP Header with: o an ANCP Header with:
* Message-Type = 92 - Multicast Admission Control * Message-Type = 145 - Multicast Admission Control
* Result= 0x00 * Result= 0x0 (Ignore)
* Transaction-ID = Transaction-ID maintained by AN * Transaction-ID = Transaction-ID maintained by 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:
* a Command Code = Delete * a Command Code = Delete (0x02);
* R = 0
* O = 0
* the multicast flow for which the IGMP leave was received by AN=
(192.0.2.1, 233.252.2.2)
* a Request-Source-IP sub-TLV containing the IGMP join source IP
(192.0.2.100).
The Multicast Admission Control message M3 is illustrated below:
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 (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=92 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0002 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xTBD (Command) TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x02 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = 0xTBD (Request-S.) TLV | Request-S.-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
A.1.4. Admission Control Reject without NAS Response
The message flow in Figure 17 illustrates the ANCP message flow in
case of a join that is rejected by the NAS because of admission
control and without explicit response from the NAS. In that case,
the multicast flow is never replicated simply by virtue of the NAS
not requesting replication.
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(Grey-Fl) | Admission |
|-----------+---------->| Control (M1) |
| | |------------------>|
| | | |
| | | (*)
| | | |
| Mcast Grey Flow | |
| not replicated x |
| | | |
Grey-Fl : Multicast Flow matching an entry in Grey List
(bandwidth delegation not activated on AN)
(*) The NAS may optionally seek direction from an external
Autorization/Policy Server
Figure 17: Admission Control Reject without NAS Response
The Multicast Admission Control message M1 contains:
o an ANCP Header with:
* Message-Type = 92 - Multicast Admission Control
* Result= 0x00
* Transaction-ID = Transaction-ID maintained by AN * Accounting = 0;
o a Target TLV identifying the AN Port * a Multicast-Flow embedded TLV indicating the SSM multicast flow
(Flow Type = 0x02) for which the AN received the IGMP leave:
IPv4 (0x01) Group address= 233.252.0.67, IPv4 (0x01) Source
Address = 192.0.2.21.
o a Command TLV containing: * a Request-Source-IP embedded TLV containing the IGMP leave
request source, IPv4 (0x01) address 192.0.2.100.
* a Command Code = Add The Multicast Admission Control message M3 is illustrated below.
* R = 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type=145 | 0x0 | Code = 0x000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command TLV Type = 0x11 | TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x02 |Acctg = 0x00 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Req-Src-IP TLV Type = 0x92 | Embedded TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Address = 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* O = 0 Multicast Admission Control Message Signalling flow Termination
* the multicast flow for which the IGMP join was received by AN= A.3. Handling White-Listed Flows
(192.0.2.1, 233.252.2.3).
* a Request-Source-IP sub-TLV containing the IGMP join source IP The NAS has enabled White list admission control on the AN, and the
(192.0.2.100). bandwidth delegation capability has been negotiated. White listed
flows in themselves require no messages to the NAS, either upon
admission or upon termination, but the AN may request an increase in
the amount of delegated bandwidth if it needs the increase to admit a
flow.
The Multicast Admission Control message M1 is illustrated below: Consider an example where the AN has already admitted one White-
listed flow, thereby using up the initially provisioned amount of
delegated bandwidth (2000 kbits/s). A request is received to join a
new flow in the White list range. The AN chooses to send a Bandwidth
Reallocation Request message to the NAS, requesting that the
delegated bandwidth allocation be increased to 4000 kbits/s at a
minimum, and preferably to 6000 kbits/s.
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 In our example, the NAS is managing bandwidth tightly, as witnessed
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ by its minimal initial allocation of just enough for one flow. It is
| Type (0x88-0C) | Length | willing to provide the minimum additional amount only, and therefore
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ returns a Bandwidth Transfer message where the delegated bandwidth
| Vers | Sub |MessageType=92 | 0x00 | Code | 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
| Partition ID | Transaction Identifier = 0003 | Bandwidth Transfer message back to the NAS bringing the delegated
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bandwidth amount back down to 2000 kbits/s when one of the flows is
|I| SubMessage Number | Length | terminated, but this shows nothing new and is omitted.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xTBD (Command) TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
A.1.5. Admission Control Reject with NAS Response As one more point of illustration, suppose that the NAS chooses to
audit the current amount of delegated bandwidth to ensure it is
synchronized with the AN. It sends a Delegated Bandwidth Query
request message to the AN, and receives a Delegated Bandwidth Query
response message with the current allocation as the AN sees it.
The message flow in Figure 18 illustrates the ANCP message flow in The complete message flow is shown in Figure 22.
case of a join that is rejected by the NAS because of admission
control and with explicit response from the NAS. In that case, the
multicast flow is not replicated by virtue of the NAS explicitely
signaling to the AN that the multicast flow is not to be replicated.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS | |Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | | | | | |
| Join(Grey-Fl) | Admission | | Join(White-F1) | |
|-----------+---------->| Control (M1) | |-----------+---------->| |
| | |------------------>| | | |AN performs |
| Mcast White Flow 1 | admission control |
|<======================+ |
| | | | | | | |
| | | Multicast (*) | Join(White-F2) | |
| | | Replication | |-----------+---------->|No bandwidth left |
| | | Control (M2) | | | | |
| Mcast Grey Flow |<------------------| | | |Bandwidth |
| not replicated x | | | | Reallocation Req |
| | |------------------>|(M1)
| | | |
| | | (*)
| | |Bandwidth Transfer |
| AN can now |<------------------|(M2)
| admit flow | |
| Mcast White Flow 2 | |
|<======================+ |
| | | |
~ ~ ~ ~
| | |Delegated Bandwidth|
| | | Query request |
| | |<------------------|(M3)
| | | |
| | |Delegated Bandwidth|
| | | Query response |
| | |------------------>|(M4)
| | | | | | | |
Grey-Fl : Multicast Flow matching an entry in Grey List
(bandwidth delegation not activated on AN)
(*) 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 18: Admission Control Reject with NAS Response
The Multicast Admission Control message M1 contains:
o an ANCP Header with:
* Message-Type = 92 - Multicast Admission Control
* Result= 0x00
* Transaction-ID = Transaction-ID maintained by AN
o a Target TLV identifying the AN Port
o a Command TLV containing:
* a Command Code = Add
* R = 0
* O = 0
* the multicast flow for which the IGMP join was received by AN=
(192.0.2.1, 233.252.2.4).
* a Request-Source-IP sub-TLV containing the IGMP join source IP
(192.0.2.100).
The Multicast Admission Control message M1 is illustrated below:
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 (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=92 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xTBD (Command) TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
The Multicast Replication Control message M2 contains:
o an ANCP Header with:
* Message-Type = 90 - Multicast Replication Control
* Result= 0x00
* Transaction-ID = Transaction-ID maintained by NAS
o a Target TLV identifying the AN Port
o a Command TLV containing:
* a Command Code = Admission Control Reject (since in our example
the flow is rejected by NAS because of bandwidth admission
control and not because of conditional access)
* R= 0 (since in our example the flow resources have not been
admitted by NAS)
* O = 0 (since in our example flow accounting is not required)
* the multicast flow (192.0.2.1, 233.252.2.4)
* a Request-Source-IP sub-TLV containing the IGMP join source IP
(192.0.2.100).
The Multicast Admission Control message M2 is illustrated below:
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 (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=90 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0010 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xTBD (Command) TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0xTBD|0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
A.2. Example Flows For bandwidth delegation
As noted in TBD, the operation of bandwidth delegation is
supplemental to the operation of request processing in the absence of
bandwidth delegation. Thus the same flows shown in the previous
section continue to hold, except that the AN does multicast call
admission before doing grey and white list processing. The example
flows of this section are therefore limited to the incremental
operations of bandwidth delegation. They include initial
provisioning, a successful request from the AN for an increase in
total multicast bandwidth, an autonomous transfer of the borrowed
bandwidth back to the NAS, and the initiation of the bandwidth reset
procedure [text to be modified] by the NAS when it finds that the
amount of total multicast bandwidth passed by the AN is larger than
its current view of that amount.
A.2.1. Activation and Provisioning of total multicast Bandwidth Figure 22: Successful Join/Leave Operations, Grey-Listed Flow
Activation of bandwidth delegation occurs at the level of the AN as a The Bandwidth Reallocation Request message (M1) is shown in
whole and is done by including a Bandwidth-Delegation-Control TLV in Figure 23. The contents require little explanation. The Message
the Provisioning message with the E-flag set to 1. The message flow Type for the Bandwidth Reallocation Request is 146. The Result field
is as shown in Figure 13. In place of Figure 14 we have the is set to 0x0 (Ignore). Besides the Target, the message has one
following content within the Provisioning message: other TLV, the Bandwidth-Request, with a TLV Type of 0x16. The TLV
contains Required Amount and Preferred Amount fields, set to 4000 and
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 (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=93 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0008 | | Type (0x88-0C) | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | | Vers | Sub | Msg Type=146 | 0x0 | Code = 0x000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Service-Prof TLV Type | Mcast-Service-Prof TLV Length | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLV Type = 0x0001 | sub-TLV Length | |I| SubMessage Number | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Type = 0x1000 (Target) | Target TLV Length = 8 |
~ Multicast service profile name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLV Type = 0x0003 | sub-TLV Length = 0x06 | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP ver = 0x00 | List length = 0x02 | | Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Grp PLen=0x00 | Src PLen=0x00 | Padding = 0x00 | |Bandwidth-Req TLV Type = 0x16 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Band-Del-Control | TLV Length = 0x04 | | Required Amount = 0x00000FA0 (4000 kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Reserved = 0x00 | Reserved = 0x00 | | Preferred Amount = 0x00001770 (6000 kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19 Figure 23: Bandwidth Reallocation Request Message
Once bandwidth delegation has been activated, the NAS must provision The Bandwidth Transfer message (M2) is shown in Figure 24. Again,
the amount of total multicast bandwidth for each access line (unless the contents are easily understood. The Message Type for the
it is pre-configured on the AN). This requires a Port Management Bandwidth Transfer message is 147. The Result field is set to
message with a Bandwidth-Allocation TLV. The same Port Management Success (0x3). The message contains the Target TLV and the
message may be used to provision other information, such as the Bandwidth-Allocation TLV. The latter has a TLV Type of 0x15 and
multicast service profile name applicable to the access line. The contains a Delegated Amount field, set to 4000 kbits/s.
information flow is therefore similar to that in Figure 15. In the
following figure, an initial allocation of 8000 kbits/s is provided.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type = 32 |Rslt =1| Code = 0 | | Type (0x88-0C) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Duration | Func = 8 | X-Func = 0 | | Vers | Sub | Msg Type=147 | 0x3 | Code = 0x000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Flow Control Flags | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Msg Type = 32 | Tech Type = 5 | Block Len = 0 | |I| SubMessage Number | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs = 2 | Ext Block length | | Type = 0x1000 (Target) | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x01 | Access-Loop-Cct-ID length | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Access Loop Circuit ID |
~ Access-Loop-Circuit-ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Bandwidth-Alloc | TLV length = 4 | |BW-Allocation TLV Type = 0x15 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount = 8000 | | Delegated Amount = 0x00000FA0 (4000 kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Port Management Message Allocating total multicast Figure 24: NAS Response, Bandwidth Transfer Message
Bandwidth
A.2.2. Successful Request For More Multicast Bandwidth
Suppose that the AN allocates all 8000 kbits/s of its total multicast The Delegated Bandwidth Query request message (M3) is shown in
amount and receives a Join request requiring another 2000 kbits/s. Figure 25. The Message Type for the Delegated Bandwidth Query
The AN issues a Bandwidth Reallocation Request message where the request message is 148. The Result field is set to AckAll (0x2).
required amount field is set to acquire this amount of additional The message contains the Target TLV only.
bandwidth. Since the request is framed in terms of total total
multicast bandwidth, required amount is 10000 kbits/s. Suppose that
the AN is configured with a policy that causes it to request enough
for one additional channel as a preferred amount. Hence the
preferred amount is set to 12000 kbits/s. The Bandwidth Reallocation
Request message has the following format:
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | MsgTyp = 94 |Rslt=0 | Code = 0 | | Type (0x88-0C) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length | | Vers | Sub | Msg Type=148 | 0x2 | Code = 0x000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |I| SubMessage Number | Length = 24 |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Request | TLV Length = 8 | | Type = 0x1000 (Target) | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required amount = 10000 | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred amount = 12000 | | Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Example Bandwidth Reallocation Request Message Figure 25: Delegated Bandwidth Query Request Message
In response to this request, the NAS is willing to grant the full Finally, the Delegated Bandwidth Query response message (M4) is shown
preferred amount. (It could have granted any value between 10000 and in Figure 26. The Message Type for the Delegated Bandwidth Query
12000, or it could have rejected the request.) The Bandwidth response message is 148. The Result field is set to Success (0x3).
Transfer message sent as a response indicates that the new total The message contains the Target TLV and the Bandwidth-Allocation TLV
multicast bandwidth amount is 12000 kbits/s, as shown in the next with the Delegated Amount field set to 4000 kbits/s.
figure.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | MsgTyp = 95 |Rslt=3 | Code = 0 | | Type (0x88-0C) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Vers | Sub | Msg Type=148 | 0x3 | Code = 0x000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | | Partition ID | Transaction Identifier (copied from request) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length | |I| SubMessage Number | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | | Type = 0x1000 (Target) | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Alloc | TLV Length = 4 | | Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount = 12000 | |BW-Allocation TLV Type = 0x15 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Amount = 0x00000FA0 (4000 kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Example Bandwidth Transfer Message (Success Response) Figure 26: Delegated Bandwidth Query Response Message
A.2.3. Failed Autonomous Transfer With Reset A.4. Handling Of Black-Listed Join Requests
Suppose the AN decides after an interval that it should return 2000 This section introduces no new messages, since requests for flows in
kbits/s of the 4000 kbits/s that it acquired from the NAS in the the Black list are simply ignored. The one thing to point out is the
previous transaction. It therefore issues a Bandwidth Transfer overlap in our example between the set of flows in the Grey list and
message of its own. This message differs from the message in the flows in the Black list. This does not create any ambiguity,
Figure 22 in two ways. First, because this is an autonomous transfer since not only does the Black list have priority for equally good
rather than a response, the Result field in the header is set to matches, but also the Black list entries are more specific (group
Ignore (0x0). Secondly, the Delegated amount is reduced to 10000 prefix lengths of 32 versus 29 in the Grey list) than the Grey list
kbits/s. flow prefixes.
Now suppose that somehow the NAS forgot that it passed an additional A.5. Handling Of Requests To Join and Leave the On-Line Game
4000 kbits/s to the AN. Thus its current view of the amount of total
multicast bandwidth is 8000 kbits/s. The 10000 kbits/s appearing in
the Bandwidth Transfer message is higher than this, so there is
clearly a disgareement between the NAS and the AN. The NAS chooses
to initiate the reset procedure, perhaps because it is close to
committing all of its available video bandwidth for unicast service.
As the initial step in this procedure, it issues a Multicast Status
message indicating that a reset of the total multicast amount is
required. This is shown in the following figure.
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 The final class of multicast control actions in our example allows
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the subscriber to enter and leave the on-line game. As described at
| Type (0x88-0C) | Length | the beginning of this example, the game uses Any Source Multicast
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (ASM). Subscriber signalling bypasses the AN, going directly to the
| Vers | Sub |MessageType=91 | 0x4 | Code = 0 | NAS (e.g., through a web interface).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-info-TLV=TBD | Status-TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rslt Code = xx | Cmd No = 1 | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4) if Length > 0 |
+---------------------------------------------------------------+
| TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Alloc | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount = 8000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Result Code field within the Status-Info TLV contains the value: When the subscriber requests to join the game, the NAS (after
total multicast bandwidth reset required (0xTBD). applying policy and bandwidth checks) sends a Multicast Replication
Control message to the AN to enable the flow on the port concerned.
The AN knows not to apply admission control, since it has not
received an MRepCtl-CAC TLV in the Provisioning message. When the
subscriber leaves, the NAS sends another Multicast Replication
Control message to delete the flow. This message sequence is shown
in Figure 27.
Figure 23: Example Initiation of Multicast Bandwidth Reset It is possible that the NAS finds that there is not enough bandwidth
available to accommodate the subscriber's request. In this case, the
NAS could send a Bandwidth Reallocation Request message to the AN,
asking it to release some of the bandwidth delegated to it. This is
not shown in the present example, since the messages are the same as
those already presented with the exception that the Preferred Amount
in the request will be *less than* or equal to the Required amount,
rather than *greater than* or equal to it.
The NAS stops processing video service requests for the given access +----------+ +-------+ +-----+ ANCP +-----+
line when it sends this message. Similarly, the AN stops processing |Subscriber| | Home | | AN |<---------->| NAS |
multicast video service requests when it receives the message. [To +----------+ |Gateway| +-----+ +-----+
think about: can service requests that release bandwidth be safely | +-------+ | |
processed? Probably.] The next step is up to the NAS: it sends a | | | |
bandwidth delegation Query Request message to the AN. The Result | Join game | |
field in the header is set to Ignore (0x0) as usual for multicast- |-----------+------------------------------>|
related messages. The Target TLV is a copy of the one received in | | | Multicast | NAS performs
the original Bandwidth Transfer message. The message is shown in the | | | Replication (*) admission
following figure: | | | Control (M1) | control
| Mcast Game Flow |<------------------|
|<=====================>+ |
| | | |
~ ~ ~ ~
| | | |
| Leave game | |
|-----------+------------------------------>|
| | | Multicast |
| | | Replication |
| | | Control (M2) |
| Mcast Game Flow |<------------------|
| discontinued | |
| | | |
0 1 2 3 (*) The NAS may optionally seek direction from an external
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 Authorization/Policy Server
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | MsgTyp = 96 |Rslt=0 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Example Delegated Bandwidth Query Request Message Figure 27: NAS-Initiated Flows For On-Line Gaming
The AN returns a Delegated Bandwidth Query Response message showing Multicast Replication Control message (M1) in Figure 28 looks like
that it believes that the amount of total multicast bandwidth is the message in Figure 21 with two exceptions. The first is that the
10000 kbits/s and it has committed 8000 kbits/s of it. The Result NAS has the option to set the Result field to AckAll (0x02) if it
field in the header shows Success (0x3) to distinguish the response. needs positive reassurance that the flow has been enabled. This was
[... in case we decide to make the query bidirectional ...] not done here to save having to depict a response differing only in
0 1 2 3 the Result field. The larger difference in this example is that the
flow description in the Multicast-Flow embedded TLV is that of an ASM
multicast group (Flow Type = 0x01) with IPv4 (0x01) group address
233.252.1.100.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | MsgTyp = 96 |Rslt=3 | Code = 0 | | Type (0x88-0C) | Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type=144 | 0x1 | Code = 0x000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length | | Type = 0x1000 (Target) | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Access Loop Circuit ID |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Request | TLV Length = 8 | | Command TLV Type = 0x11 | TLV Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount = 10000 | | Cmd Code=0x01 | Acctg = 0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed amount = 8000 | |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Type=0x01 |Addr Fam =0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.1.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
Figure 25: Example Delegated Bandwidth Query Response Message Figure 28: Enabling The Subscriber To Join An On-Line Game
The NAS decides to reset the total multicast bandwidth amount to 8000 Message M2 terminating the flow when the subscriber leaves the game
kbits/s. It issues a Port Management message looking exactly like looks the same as the message in Figure 28 with two exceptions: the
the one in Figure 20. Once it sends this message, it resumes Command Code becomes Delete (0x02), and Accounting is set to 0 to
processing service requests for the access line concerned. turn off flow accounting. Of course, the Transaction Identifier
Similarly, the AN resumes request processing after it receives the values will differ between the two messages.
Port Management message and resets its view of the current total
multicast bandwidth. In the short run, this means that it will have
to ask for more bandwidth if it receives another Join request. [It
seems reasonable that the AN would not do so for a period of time
after a reset or a response to a Bandwidth Reallocation Request that
grants less than the preferred amount. Should we establish a timer?]
A.3. Example Flows For Multicast Flow Reporting A.6. Example Flow For Multicast Flow Reporting
A.3.1. Per Port Multicast Flow Reporting The example in this section is independent of the example in the
preceding sections.
Figure 26 illustrate a message flow in the case where the NAS queries Figure 29 illustrates a message flow in a case where the NAS queries
the AN about which multicast flow is active on port 10, on port 20 the AN about which multicast flows are active on port 10, on port 20
and on port 11 of the AN. and on port 11 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 26: Per Port Multicast Flow Reporting Figure 29: 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 27. Figure 30. The Message Type is 149. The Result field is set to
AckAll (0x2). Three Target TLVs are present, identifying port 10,
port 20, and port 11 respectively.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type = 97 |Rslt=00| Code = 0 | | Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type = 149|Rslt=2 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length | | Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 88, line 39 skipping to change at page 86, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length | | Type = 0x1000 (Target) | 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 27: Multicast Flow Query Request message for per-port Mulicast Figure 30: Multicast Flow Query Request Message For Per-Port
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 28. It indicates that there is one active multicast flow Figure 31. It indicates that there is one active multicast flow
[(192.0.2.1, 233.252.2.4)] on port 10, no active multicast flow on [(192.0.2.1, 233.252.2.4)] on port 10, no active multicast flow on
port 20 and two active multicast flows [(192.0.2.1, 233.252.2.4) and port 20 and two active multicast flows [(192.0.2.1, 233.252.2.4) and
(192.0.2.2, 233.252.2.10)] on port 11. (192.0.2.2, 233.252.2.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type = 97 |Rslt=00| Code = 0 | | Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type = 149|Rslt=3 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length | | Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Access Loop Circuit ID (port10) ~ ~ Access Loop Circuit ID (port10) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length | |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | | Multicast Group Address = 233.252.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Type = 0x1000 (Target) | Target TLV Length | | Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Access Loop Circuit ID (port20) ~ ~ Access Loop Circuit ID (port20) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length | | Type = 0x1000 (Target) | 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) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length | |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | | Multicast Group Address = 233.252.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length | |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 | |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.10 | | Multicast Group Address: 233.252.2.10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
Figure 28: Multicast Flow Query Response message for per-port
Figure 31: Multicast Flow Query Response message for per-port
Mulicast Flow Reporting Mulicast Flow Reporting
Authors' Addresses Authors' Addresses
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
 End of changes. 424 change blocks. 
1547 lines changed or deleted 1639 lines changed or added

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