draft-ietf-ancp-mc-extensions-02.txt   draft-ietf-ancp-mc-extensions-03.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: September 9, 2010 Telecom Italia Expires: February 6, 2011 Telecom Italia
T. Taylor T. Taylor
Huawei Huawei
March 8, 2010 August 5, 2010
Multicast Control Extensions for ANCP Multicast Control Extensions for ANCP
draft-ietf-ancp-mc-extensions-02.txt draft-ietf-ancp-mc-extensions-03.txt
Abstract Abstract
This document specifies the extensions to the Access Node Control This document specifies the extensions to the Access Node Control
Protocol required for support of the multicast use cases defined in Protocol required for support of the multicast use cases defined in
the Access Node Control Protocol framework document. Those use cases the Access Node Control Protocol framework document and one
are organized into the following ANCP capabilities: additional use case described in this document. These use cases are
organized into the following ANCP capabilities:
o NAS-initiated multicast replication; o NAS-initiated multicast replication;
o conditional access with white and black lists; o conditional access with white and black lists;
o conditional access with grey lists; o conditional access with grey lists;
o bandwidth delegation. o bandwidth delegation;
o committed bandwidth reporting.
These capabilities may be combined according to the rules given in These capabilities may be combined according to the rules given in
this specification. this specification.
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 in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 6, 2011.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 8 3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 9
3.1. NAS Initiated Multicast Replication Control Use Case . . . 8 3.1. NAS Initiated Multicast Replication Control Use Case . . . 9
3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 10
3.2. Conditional Access and Admission Control Use Case . . . . 9 3.2. Conditional Access and Admission Control Use Case . . . . 10
3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11
3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 11 3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 12
3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11 3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 12
4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Committed Bandwidth Reporting Use Case . . . . . . . . . . 13
4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 13 3.4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 13 3.4.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 13
4.1.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 14 4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Port Management Message . . . . . . . . . . . . . . . . . 15 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 15
4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 15 4.1.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 15
4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 16 4.1.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 16
4.3. Multicast Replication Control Message . . . . . . . . . . 16 4.2. Port Management Message . . . . . . . . . . . . . . . . . 17
4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 21 4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 18
4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 21 4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 18
4.4. Multicast Admission Control Message . . . . . . . . . . . 23 4.3. Multicast Replication Control Message . . . . . . . . . . 19
4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 24 4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 23
4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 25 4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 23
4.5. Bandwidth Reallocation Request Message . . . . . . . . . . 26 4.4. Multicast Admission Control Message . . . . . . . . . . . 25
4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 27 4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 26
4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 27 4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 27
4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . . 29 4.5. Bandwidth Reallocation Request Message . . . . . . . . . . 28
4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 30 4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 29
4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 30 4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 29
4.7. Delegated Bandwidth Query Request Message . . . . . . . . 31 4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . . 31
4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 32 4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 32
4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 32 4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 32
4.8. Delegated Bandwidth Query Response Message . . . . . . . . 32 4.7. Delegated Bandwidth Query Request Message . . . . . . . . 33
4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 32 4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 34
4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 33 4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 34
4.9. Multicast Flow Query Request and Response Messages . . . . 33 4.8. Delegated Bandwidth Query Response Message . . . . . . . . 34
4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 34 4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 34
4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 35 4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 35
5. ANCP TLVs For Multicast . . . . . . . . . . . . . . . . . . . 37 4.9. Multicast Flow Query Request and Response Messages . . . . 35
5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 37 4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 36
5.2. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 38 4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 37
5.3. List-Action TLV . . . . . . . . . . . . . . . . . . . . . 38 4.10. Committed Bandwidth Report Message . . . . . . . . . . . . 38
5.4. Sequence-Number TLV . . . . . . . . . . . . . . . . . . . 41 4.10.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 38
5.5. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 42 4.10.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 38
5.6. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . . 42
5.7. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 43 5. ANCP TLVs For Multicast . . . . . . . . . . . . . . . . . . . 40
5.8. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 43 5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 40
5.9. Request-Source-IP TLV . . . . . . . . . . . . . . . . . . 44 5.2. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 41
5.10. Request-Source-MAC TLV . . . . . . . . . . . . . . . . . . 44 5.3. List-Action TLV . . . . . . . . . . . . . . . . . . . . . 41
5.11. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 45 5.4. Sequence-Number TLV . . . . . . . . . . . . . . . . . . . 44
6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . . 47 5.5. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 45
6.1. Required Protocol Support . . . . . . . . . . . . . . . . 47 5.6. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . . 45
6.1.1. Protocol Requirements For NAS-initiated Replication . 47 5.7. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 46
6.1.2. Protocol Requirements For Conditional Access With 5.8. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 46
White and Black Lists . . . . . . . . . . . . . . . . 48 5.9. Request-Source-IP TLV . . . . . . . . . . . . . . . . . . 47
5.10. Request-Source-MAC TLV . . . . . . . . . . . . . . . . . . 47
5.11. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 48
5.12. Report-Buffering-Time TLV . . . . . . . . . . . . . . . . 49
5.13. Committed-Bandwidth TLV . . . . . . . . . . . . . . . . . 50
6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . . 51
6.1. Required Protocol Support . . . . . . . . . . . . . . . . 51
6.1.1. Protocol Requirements For NAS-initiated Replication . 52
6.1.2. Protocol Requirements For Committed Multicast
Bandwidth Reporting . . . . . . . . . . . . . . . . . 52
6.1.3. Protocol Requirements For Conditional Access With 6.1.3. Protocol Requirements For Conditional Access With
Grey Lists . . . . . . . . . . . . . . . . . . . . . . 49 White and Black Lists . . . . . . . . . . . . . . . . 53
6.1.4. Protocol Requirements For Delegated Bandwidth . . . . 50 6.1.4. Protocol Requirements For Conditional Access With
Grey Lists . . . . . . . . . . . . . . . . . . . . . . 54
6.1.5. Protocol Requirements For Delegated Bandwidth . . . . 55
6.2. Capability-Specific Procedures for Providing Multicast 6.2. Capability-Specific Procedures for Providing Multicast
Service . . . . . . . . . . . . . . . . . . . . . . . . . 51 Service . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.1. Procedures For NAS-initiated Replication . . . . . . . 51 6.2.1. Procedures For NAS-Initiated Replication . . . . . . . 56
6.2.2. Procedures For Conditional Access With Black and 6.2.2. Procedures For Committed Bandwidth Reporting . . . . 57
White Lists . . . . . . . . . . . . . . . . . . . . . 52 6.2.3. Procedures For Conditional Access With Black and
6.2.3. Procedures For Conditional Access With Grey Lists . . 54 White Lists . . . . . . . . . . . . . . . . . . . . . 58
6.2.4. Procedures For Delegated Bandwidth . . . . . . . . . . 55 6.2.4. Procedures For Conditional Access With Grey Lists . . 60
6.3. Combinations of Multicast Capabilities . . . . . . . . . . 56 6.2.5. Procedures For Delegated Bandwidth . . . . . . . . . . 61
6.3. Combinations of Multicast Capabilities . . . . . . . . . . 62
6.3.1. Combination of Conditional Access With White and 6.3.1. Combination of Conditional Access With White and
Black Lists and Conditional Access With Grey Lists . . 56 Black Lists and Conditional Access With Grey Lists . . 62
6.3.2. Combination of Conditional Access With Delegated 6.3.2. Combination of Conditional Access With Delegated
Bandwidth . . . . . . . . . . . . . . . . . . . . . . 57 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 63
6.3.3. Combination of NAS-Initiated Replication with 6.3.3. Combination of NAS-Initiated Replication with
Other Capabilities . . . . . . . . . . . . . . . . . . 57 Other Capabilities . . . . . . . . . . . . . . . . . . 63
7. Security Considerations . . . . . . . . . . . . . . . . . . . 59 6.3.4. Combinations of Committed Bandwidth Reporting with
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 Other Multicast Capabilities . . . . . . . . . . . . . 64
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 65
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
10.1. Normative References . . . . . . . . . . . . . . . . . . . 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69
10.2. Informative References . . . . . . . . . . . . . . . . . . 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Appendix A. Example of Messages and Message Flows . . . . . . . . 66 10.1. Normative References . . . . . . . . . . . . . . . . . . . 70
A.1. Provisioning Phase . . . . . . . . . . . . . . . . . . . . 66 10.2. Informative References . . . . . . . . . . . . . . . . . . 70
A.2. Handling a Grey-Listed Flow . . . . . . . . . . . . . . . 72 Appendix A. Example of Messages and Message Flows . . . . . . . . 72
A.3. Handling White-Listed Flows . . . . . . . . . . . . . . . 77 A.1. Provisioning Phase . . . . . . . . . . . . . . . . . . . . 72
A.4. Handling Of Black-Listed Join Requests . . . . . . . . . . 82 A.2. Handling a Grey-Listed Flow . . . . . . . . . . . . . . . 78
A.5. Handling Of Requests To Join and Leave the On-Line Game . 82 A.3. Handling White-Listed Flows . . . . . . . . . . . . . . . 83
A.6. Example Flow For Multicast Flow Reporting . . . . . . . . 85 A.4. Handling Of Black-Listed Join Requests . . . . . . . . . . 88
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89 A.5. Handling Of Requests To Join and Leave the On-Line Game . 88
A.6. Example Flow For Multicast Flow Reporting . . . . . . . . 91
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 95
1. Introduction 1. Introduction
[I-D.ietf-ancp-framework] defines a framework and requirements for an [RFC5851] defines a framework and requirements for an Access Node
Access Node control mechanism between a Network Access Server (NAS) control mechanism between a Network Access Server (NAS) and an Access
and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a
(DSLAM)) in a multi-service reference architecture in order to multi-service reference architecture in order to perform QoS-related,
perform QoS-related, service-related and subscriber-related service-related and subscriber-related operations.
operations. [I-D.ietf-ancp-protocol] specifies a protocol for Access [I-D.ietf-ancp-protocol] specifies a protocol for Access Node Control
Node Control in broadband networks in line with this framework. in broadband networks in line with this framework.
The Access Node Control Protocol (ANCP) specified in [I-D.ietf-ancp-protocol] supports three use cases defined in
[I-D.ietf-ancp-protocol] supports a number of use cases defined in [RFC5851], specifically for DSL access: the DSL Topology Discovery
[I-D.ietf-ancp-framework] such as the Access Topology Discovery use use case, the DSL Line Configuration use case and the DSL Remote
case, the Access Loop Configuration use case and the Remote
Connectivity Test use case. However, it does not support the Connectivity Test use case. However, it does not support the
multicast use cases defined in [I-D.ietf-ancp-framework]. The multicast use cases defined in [RFC5851]. The present document
present document specifies the extensions to the Access Node Control specifies the extensions to the Access Node Control Protocol required
Protocol required for support of these multicast use cases. In terms for support of these multicast use cases. In addition, it supports
of the ANCP protocol, these use cases are organized into four the Committed Bandwidth Reporting use case, described below. In
terms of the ANCP protocol, these use cases are organized into five
capabilities: capabilities:
o NAS-initiated multicast replication; o NAS-initiated multicast replication;
o conditional access with white and black lists; o conditional access with white and black lists;
o conditional access with grey lists; o conditional access with grey lists;
o bandwidth delegation. o bandwidth delegation;
o committed bandwidth reporting.
NAS-initiated multicast replication assumes that multicast "join" and NAS-initiated multicast replication assumes that multicast "join" and
"leave" requests are terminated on the NAS, or that the NAS receives "leave" requests are terminated on the NAS, or that the NAS receives
requests to establish multicast sessions through other means (e.g., requests to establish multicast sessions through other means (e.g.,
application-level signalling). The NAS sends commands to the AN to application-level signalling). The NAS sends commands to the AN to
start or stop replication of specific multicast flows on specific start or stop replication of specific multicast flows on specific
subscriber ports. This use case is described briefly in the next-to- subscriber ports. This use case is described briefly in the next-to-
last paragraph of Section 3.4 of [I-D.ietf-ancp-framework]. last paragraph of Section 3.4 of [RFC5851].
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 [RFC5851], with the latter section particularly applicable to
applicable to operation with white and black lists only. In case of operation with white and black lists only. In case of "conditional
"conditional access with white and black lists", multicast join and access with white and black lists", multicast join and leave requests
leave requests are terminated at the AN and accepted or ignored in are terminated at the AN and accepted or ignored in accordance with
accordance with the direction provided by white and black lists the direction provided by white and black lists respectively. The
respectively. The white and black lists are provisioned per port at white and black lists are provisioned per port at startup time and
startup time and may be modified thereafter. The NAS may enable may be modified thereafter. The NAS may enable admission control of
admission control of white-listed flows by appropriate provisioning. white-listed flows by appropriate provisioning.
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. grey-listed flows at the AN.
Bandwidth delegation is described in Section 3.4.2.1 of Bandwidth delegation is described in Section 3.4.2.1 of [RFC5851].
[I-D.ietf-ancp-framework]. It allows flexible sharing of total video It allows flexible sharing of total video bandwidth on an access line
bandwidth on an access line between the AN and the NAS. One between the AN and the NAS. One application of such bandwidth
application of such bandwidth sharing is where the AN does multicast sharing is where the AN does multicast admission control, while the
admission control, while the NAS or Policy Server does unicast NAS or Policy Server does unicast admission control. In that case,
admission control. In that case, bandwidth delegation allows dynamic bandwidth delegation allows dynamic sharing of bandwidth between
sharing of bandwidth between unicast and multicast video traffic on unicast and multicast video traffic on each access line.
each access line.
Committed bandwidth reporting is described below, in Section 3.4.
The AN reports the amount of multicast bandwidth it has granted to a
given access line each time that value changes. These reports may be
buffered for a NAS-provisionable interval so that reports for
multiple access lines can be bundled into the same message.
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 [RFC5851]. Because of this common content and because of
and because of other protocol overlaps between the different other protocol overlaps between the different capabilities, the
capabilities, the protocol descriptions for the multicast extensions protocol descriptions for the multicast extensions specified in this
specified in this document are merged into a single non-redundant document are merged into a single non-redundant narrative. Tables in
narrative. Tables in Section 6 then indicate the specific sub- Section 6 then indicate the specific sub-sections of the protocol
sections of the protocol description that have to be implemented to description that have to be implemented to support each capability.
support each capability.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The expression "delegated bandwidth" is used as a shorter way of The expression "delegated bandwidth" is used as a shorter way of
saying: "the total amount of video bandwidth delegated to the AN for saying: "the total amount of video bandwidth delegated to the AN for
multicast admission control". multicast admission control".
3. Multicast Use Cases 3. Multicast Use Cases
Quoting from [I-D.ietf-ancp-framework]: Quoting from [RFC5851]:
"... the Access Node, aggregation node(s) and the NAS must all be "... the Access Node, aggregation node(s) and the NAS must all be
involved in the multicast replication process. This avoids that involved in the multicast replication process. This avoids that
several copies of the same stream are sent within the access/ several copies of the same stream are sent within the access/
aggregation network. In case of an Ethernet-based access/aggregation aggregation network. In case of an Ethernet-based access/aggregation
network, this may, for example, be achieved by means of IGMP snooping network, this may, for example, be achieved by means of IGMP snooping
or IGMP proxy in the Access Node and aggregation node(s). By or IGMP proxy in the Access Node and aggregation node(s). By
introducing IGMP processing in the access/aggregation nodes, the introducing IGMP processing in the access/aggregation nodes, the
multicast replication process is now divided between the NAS, the multicast replication process is now divided between the NAS, the
aggregation node(s) and Access Nodes. In order to ensure backward aggregation node(s) and Access Nodes. In order to ensure backward
compatibility with the ATM-based model, the NAS, aggregation node and compatibility with the ATM-based model, the NAS, aggregation node and
Access Node need to behave as a single logical device. This logical Access Node need to behave as a single logical device. This logical
device must have exactly the same functionality as the NAS in the ATM device must have exactly the same functionality as the NAS in the ATM
access/aggregation network. The Access Node Control Mechanism can be access/aggregation network. The Access Node Control Mechanism can be
used to make sure that this logical/functional equivalence is used to make sure that this logical/functional equivalence is
achieved by exchanging the necessary information between the Access achieved by exchanging the necessary information between the Access
Node and the NAS. " Node and the NAS. "
[I-D.ietf-ancp-framework] describes the use cases for ANCP associated [RFC5851] describes the use cases for ANCP associated with such
with such multicast operations, and identifies the associated ANCP multicast operations, and identifies the associated ANCP
requirements. The present section describes a subset of these use requirements. The present section describes a subset of these use
cases as background to facilitate reading of this document, but the cases as background to facilitate reading of this document, but the
reader is refered to [I-D.ietf-ancp-framework] for a more exhaustive reader is refered to [RFC5851] for a more exhaustive description of
description of the ANCP multicast use cases. Detailed example the ANCP multicast use cases. Detailed example message flows can
message flows can also be found in Appendix A. also be found in Appendix A.
3.1. NAS Initiated Multicast Replication Control Use Case 3.1. NAS Initiated Multicast Replication Control Use Case
3.1.1. Goals 3.1.1. Goals
One option for multicast handling is for the subscriber to One option for multicast handling is for the subscriber to
communicate the "join/leave" information to the NAS. This can be communicate the "join/leave" information to the NAS. This can be
done for instance by terminating all subscriber IGMP ([RFC3376]) or done for instance by terminating all subscriber IGMP ([RFC3376]) or
MLD ([RFC2710], [RFC3810]) signaling on the NAS. Another example MLD ([RFC2710], [RFC3810]) signaling on the NAS. Another example
could be a subscriber using some form of application level signaling, could be a subscriber using some form of application level signaling,
skipping to change at page 13, line 5 skipping to change at page 13, line 21
| | |<------------------| | | |<------------------|
| | | | | | | |
| | | Multicast Flow | | | | Multicast Flow |
| | | Query Response | | | | Query Response |
| | |------------------>| | | |------------------>|
| | | | | | | |
| | | | | | | |
Figure 3: Multicast Flow Reporting Figure 3: Multicast Flow Reporting
3.4. Committed Bandwidth Reporting Use Case
3.4.1. Goals
The committed bandwidth reporting use case allows the NAS to maintain
current awareness of how much multicast bandwidth the AN has
committed to a given access line, so that the NAS can adjust its
forwarding scheduler to ensure the associated QoS. Note that this
involves a finer level of detail than provided by bandwidth
delegation, since the amount of delegated bandwidth is an upper limit
on the amount of bandwidth committed rather than an actual value. To
reduce the volume of messaging, reports from the AN may be buffered
so that one message reports on changes for multiple access lines.
3.4.2. Message Flow
The message flow associated with this use case is shown in Figure 4.
The figure assumes that a non-zero buffering interval was previously
provisioned on the AN.
+-----+ +-------+ +-----+ ANCP +-----+
|Subs |+ | Home |+ | AN |<---------->| NAS |
|1,2 || |GW 1,2 || +-----+ +-----+
+-----+| +-------+| | |
+|----+ +|------+ | |
| | | | | |
| |Join(Subs1, Ch1) | |
|----------+--------------->| Start buffering |
| | | Multicast flow | timer. Create |
|<==========================| message with |
| | | | | initial contents |
| | | | | reporting new |
| | | | | Subs1 bandwidth. |
| | Join(Subs2, Ch2) | |
| |----------+------------->| Add report for |
| | | Multicast flow | new Subs2 b/w. |
| |<========================| |
| | | | | |
| |Leave(Subs1, Ch1) | |
|----------+--------------->| Replace report |
| | | | | for Subs1 with |
| | Stop replication X new value (which |
| | | | | happens to be |
| | | | | the same as the |
| | | | | starting value. |
| | | | | |
| | | | >|< TIMER expires |
| | | | | |
| | | | |Committed |
| | | | | Bandwidth Report |
| | | | |------------------>|
| | | | | (for latest |
| | | | | Subs1 and Subs2 |
| | | | | bandwidth) |
| | | | | |
Figure 4: Message Flow For Committed Bandwidth Reporting
4. ANCP Messages 4. ANCP Messages
This section defines new ANCP messages and new usage of existing ANCP This section defines new ANCP messages and new usage of existing ANCP
messages as well as procedures associated with the use of these messages as well as procedures associated with the use of these
messages. messages.
4.1. Provisioning Message 4.1. Provisioning Message
Section 5.4.3.1 of [I-D.ietf-ancp-protocol] defines the Provisioning Section 6.1.2 of [I-D.ietf-ancp-protocol] defines the Provisioning
message that is sent by the NAS to the AN to provision information in message that is sent by the NAS to the AN to provision information in
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 5.6. If present, this TLV indicates that the defined in Section 5.6. If present, this TLV indicates that the
AN is required to do admission control before replicating White- AN is required to do admission control before replicating White-
listed flows. listed flows.
o an instance of the MRepCtl-CAC TLV. The MRepCtl-CAC TLV is o an instance of the MRepCtl-CAC TLV. The MRepCtl-CAC TLV is
defined in Section 5.7. If present, this TLV indicates that the defined in Section 5.7. If present, this TLV indicates that the
AN is required to do admission control before replicating flows AN is required to do admission control before replicating flows
specified in Multicast Replication Control messages. specified in Multicast Replication Control messages.
o an instance of the Report-Buffering-Time TLV. The Report-
Buffering-Time TLV is defined in Section 5.12. If present, this
TLV indicates Committed Bandwidth Report messages should be
buffered for the amount of time given by the TLV before being
transmitted to the NAS.
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
perform admission control for specific classes of flows. perform admission control for specific classes of flows.
To provision or update a multicast service profile, the NAS MUST To provision or update a multicast service profile, the NAS MUST
include within the message one or more instances of the Multicast- include within the message one or more instances of the Multicast-
Service-Profile TLV specifying the content to be provisioned or Service- Profile TLV specifying the content to be provisioned or
updated. The NAS SHOULD NOT include any list type (White, Black, or updated. The NAS SHOULD NOT include any list type (White, Black, or
Grey) that is not supported by the set of multicast capabilities Grey) that is not supported by the set of multicast capabilities
negotiated between the NAS and the AN. The NAS MUST NOT use the negotiated between the NAS and the AN. The NAS MUST NOT use the
Provisioning message to send instances of the Multicast-Service- Provisioning message to send instances of the Multicast- Service-
Profile TLV to the AN unless the Multicast-Service-Profile TLV is Profile TLV to the AN unless the Multicast-Service-Profile TLV is
supported by the set of multicast capabilities negotiated between the supported by the set of multicast capabilities negotiated between the
NAS and the AN. NAS and the AN.
To require admission control to be performed at the AN on White- To require admission control to be performed at the AN on White-
listed flows, the NAS MUST include a copy of the White-List-CAC TLV listed flows, the NAS MUST include a copy of the White-List-CAC TLV
in the Provisioning message. The White-List-CAC TLV MUST NOT be in the Provisioning message. The White-List-CAC TLV MUST NOT be
provided unless the negotiated set of capabilities includes provided unless the negotiated set of capabilities includes
conditional access with White and Black lists. conditional access with White and Black lists.
To require admission control to be performed at the AN on Grey-listed To require admission control to be performed at the AN on Grey-listed
flows or on NAS-initiated flows, the NAS MUST include a copy of the flows or on NAS-initiated flows, the NAS MUST include a copy of the
MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV
MUST NOT be provided unless the negotiated set of capabilities MUST NOT be provided unless the negotiated set of capabilities
includes NAS-initiated replication control or conditional access with includes NAS-initiated replication control or conditional access with
Grey lists. Grey lists.
To require buffering of Committed Bandwidth Report messages so that
reports for multiple access lines can be included in the same
message, the NAS MUST include a copy of the Report-Buffering-Time TLV
containing a non-zero time value in a Provisioning message sent to
the AN. The Report-Buffering-Time TLV MUST NOT be provided unless
the negotiated set of capabilities includes committed bandwidth
reporting.
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
according to the contents of the associated List-Action TLVs. The AN according to the contents of the associated List-Action TLVs. The AN
MUST process List-Action TLVs in the order in which they appear MUST process List-Action TLVs in the order in which they appear
within the message. The AN MUST ignore instances of the List-Action 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 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
skipping to change at page 15, line 9 skipping to change at page 17, line 24
that profile has been assigned. For further details, see Section 6. that profile has been assigned. For further details, see Section 6.
If the White-List-CAC and/or MRepCtl-CAC TLV is present in the If the White-List-CAC and/or MRepCtl-CAC TLV is present in the
Provisioning message and the respective associated capabilities have Provisioning message and the respective associated capabilities have
been negotiated, the AN prepares (or continues) to do connection been negotiated, the AN prepares (or continues) to do connection
admission control on the indicated class(es) of flow. If one or both 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 of these TLVs was present in an earlier Provisioning message but is
absent in the latest message received, the AN ceases to do connection absent in the latest message received, the AN ceases to do connection
admission control on the indicated class(es) of flow. admission control on the indicated class(es) of flow.
The buffering time specified in an instance of the Report-Buffering-
Time TLV applies to only to Committed Bandwidth Report messages
initiated after the new buffering time is received at the AN, not to
any message already in the process of accumulation.
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 type in 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
list types there will be no debugging feedback. On the other
hand, this adds flexibility for handling pre-assembled sets of
list updates being sent out to multiple ANs. If there are no
comments on this feature/bug, this Editor's note will be removed
in the next version of the draft.
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 DSL line
configuration information to the AN ("ANCP based Line Configuration" configuration information to the AN ("ANCP based DSL Line
use case) using GSMP Port Management messages modified to contain an Configuration" use case) using GSMP Port Management messages modified
extension block. Section 5.4.3 of [I-D.ietf-ancp-protocol] defines a to contain additional information. See Section 5.3.3 of
number of TLVs that can be included in the Extension Value field [I-D.ietf-ancp-protocol] for details.
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 either or both of the following TLVs: include either or both of the following TLVs:
o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This
TLV associates a Multicast Service Profile with the Access Port TLV associates a Multicast Service Profile with the Access Port
specified by the extension block. specified by the extension block.
o Bandwidth-Allocation TLV (defined in Section 5.5). This TLV o Bandwidth-Allocation TLV (defined in Section 5.5). This TLV
specifies the total multicast bandwidth available to the AN for specifies the total multicast bandwidth available to the AN for
skipping to change at page 16, line 8 skipping to change at page 18, line 19
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. If the NAS Bandwidth-Allocation TLV, reset these parameters. If the NAS
includes a Multicast-Service-Profile-Name TLV in the Port Management includes a Multicast-Service-Profile-Name TLV in the Port Management
message, the name MUST match a profile name provided in a Multicast- message, the name MUST match a profile name provided in a Multicast-
Service-Profile TLV in a prior Provisioning message. The NAS MUST Service- Profile TLV in a prior Provisioning message. The NAS MUST
NOT include a TLV unless it is supported by the set of multicast NOT include a TLV unless it is supported by the set of multicast
capabilities negotiated between the NAS and the AN. See Section 6 capabilities negotiated between the NAS and the AN. See Section 6
for further information. for further information.
4.2.2. Receiver Behaviour 4.2.2. Receiver 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
skipping to change at page 17, line 14 skipping to change at page 19, line 24
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
144. 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] or extensions and identifies the AN port
request for admission or release. subject to the 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. multiple times.
As [I-D.ietf-ancp-protocol] indicates, the contents of the Command As [I-D.ietf-ancp-protocol] indicates, the contents of the Command
Info field within the Command TLV are specific to the message in Info field within the Command TLV are specific to the message in
which the TLV occurs. For the Multicast Replication Control Message, which the TLV occurs. For the Multicast Replication Control Message,
these contents consist of: these contents consist of:
o a Command Code field; o a Command Code field;
o an Accounting field; o an Accounting field;
o an instance of the Multicast-Flow TLV. o an instance of the Multicast-Flow TLV.
Figure 4 illustrates the complete Command TLV with the contents Figure 5 illustrates the complete Command TLV with the contents
specific to the Multicast Replication Control message. specific to the Multicast Replication Control message.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command | Command-TLV Length | | TLV Type = Command | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Command Code | Accounting | Reserved | |Command Code | Accounting | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Flow TLV | | Multicast-Flow TLV |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other embedded TLV Type | Other embedded TLV Length | | Other embedded TLV Type | Other embedded TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Other embedded TLV data ~ ~ Other embedded TLV data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Contents of the Command TLV in the Multicast Replication Figure 5: Contents of the Command TLV in the Multicast Replication
Control Message Control Message
Command Code: Command Code:
Command directive: Command directive:
0x01 - Add; 0x01 - Add;
0x02 - Delete; 0x02 - Delete;
0x03 - Delete All; 0x03 - Delete All;
skipping to change at page 21, line 12 skipping to change at page 23, line 12
| Source Address = 192.0.2.2 | | 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 [RFC5851] and
[I-D.ietf-ancp-framework] and summarized in Section 3.1. In that summarized in Section 3.1. In that case, the NAS MUST set the Result
case, the NAS MUST set the Result field to AckAll (0x2) or Nack (0x1) field to AckAll (0x2) or Nack (0x1) according to its requirements.
according to its requirements.
The NAS MAY also send this message in response to a Multicast The NAS MAY also send this message in response to a Multicast
Admission Control message (defined in Section 4.4) received from the Admission Control message (defined in Section 4.4) received from the
AN to support the conditional access and admission control use case AN to support the conditional access and admission control use case
presented in [I-D.ietf-ancp-framework] and summarized in Section 3.2. presented in [RFC5851] and summarized in Section 3.2. In that case,
In that case, the NAS MUST set the Result field to NAck (0x1). the NAS MUST set the Result field to NAck (0x1).
In either case, the sender MUST populate the 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 4.4.1 of [I-D.ietf-ancp-protocol].
Each Multicast Replication Control Message MUST contain one or more Each Multicast Replication Control Message MUST contain one or more
commands, each encapsulated in its own Command TLV. The sender MUST commands, each encapsulated in its own Command TLV. The sender MUST
use a separate Command TLV for each distinct multicast flow. use a separate Command TLV for each distinct multicast flow.
When the order of processing of two commands does not matter, the When the order of processing of two commands does not matter, the
commands MUST be transmitted in separate Multicast Replication commands MUST be transmitted in separate Multicast Replication
Control messages. Control messages.
4.3.2. Receiver Behaviour 4.3.2. Receiver Behaviour
skipping to change at page 23, line 39 skipping to change at page 25, line 39
notify of the removal of a multicast flow, for a given target. notify of the removal of a multicast flow, for a given target.
The Message Type for the Multicast Admission Control message is 145. The Message Type for the Multicast Admission Control message is 145.
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] or extensions and identifies the AN port
request for admission or release. subject to the 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. If it appears more [I-D.ietf-ancp-protocol]. It MUST be present. If it appears more
than once, only the first instance is considered meaningful in the than once, only the first instance is considered meaningful in the
present version of this specification and the other instances are present version of this specification and the other instances are
ignored. ignored.
Informative note: Informative note:
In the future, the specification of the Admission Control message In the future, the specification of the Admission Control message
skipping to change at page 24, line 31 skipping to change at page 26, line 31
Note that the Command TLV length includes the length of any embedded Note that the Command TLV length includes the length of any embedded
TLVs, including the embedded TLV headers. TLVs, including the embedded TLV headers.
4.4.1. Sender Behaviour 4.4.1. Sender 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 4.4.1 of
of[I-D.ietf-ancp-protocol] . [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 Accounting field MUST be set to 0; o the Accounting field MUST be set to 0;
o the Command Code field MUST be set to "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);
skipping to change at page 26, line 22 skipping to change at page 28, line 22
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 Section 6.1.3 of
appropriate content indicating the reason for the failure. [I-D.ietf-ancp-protocol]) with appropriate content indicating the
reason for the failure.
4.5. Bandwidth Reallocation Request Message 4.5. Bandwidth Reallocation Request Message
The Bandwidth Reallocation Request message is used when the bandwidth The Bandwidth Reallocation Request message is used when the bandwidth
delegation capability is included in the negotiated set. It MAY be delegation capability is included in the negotiated set. It MAY be
sent either by the NAS or by the AN to request an adjustment in the sent either by the NAS or by the AN to request an adjustment in the
amount of delegated bandwidth. It will be sent by the NAS typically amount of delegated bandwidth. It will be sent by the NAS typically
to reduce the multicast bandwidth allocated to the AN in order for to reduce the multicast bandwidth allocated to the AN in order for
the NAS to satisfy a request to add one or more flows. Conversely, the NAS to satisfy a request to add one or more flows. Conversely,
the AN will send a Bandwidth Reallocation Request to obtain the AN will send a Bandwidth Reallocation Request to obtain
additional bandwidth to satisfy a request to add a multicast channel. additional bandwidth to satisfy a request to add a multicast channel.
In each case, the requestor has a minimum requirement for additional In each case, the requestor has a minimum requirement for additional
bandwidth, and MAY ask for additional bandwidth beyond this amount bandwidth, and MAY ask for additional bandwidth beyond this amount
(e.g., to handle anticipated future requests). (e.g., to handle anticipated future requests).
The Bandwidth Reallocation Request message contains two TLVs: The Bandwidth Reallocation Request message contains two TLVs:
o the Target TLV (section 5.4.5.1.1 of [I-D.ietf-ancp-protocol]), o the Target TLV (Section 6.2.1 of [I-D.ietf-ancp-protocol] or an
specifying a single access line; extension), specifying a single access line;
o the Bandwidth-Request TLV (Section 5.8), specifying the required o the Bandwidth-Request TLV (Section 5.8), specifying the required
and preferred amounts of delegated bandwidth. and preferred amounts of delegated bandwidth.
The Message Type for the Bandwidth Reallocation Request message is The Message Type for the Bandwidth Reallocation Request message is
146. 146.
4.5.1. Sender Behaviour 4.5.1. Sender Behaviour
The Result field in the header of the Bandwidth Reallocation Request The Result field in the header of the Bandwidth Reallocation Request
skipping to change at page 32, line 10 skipping to change at page 34, line 10
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
The sender MUST set the Result field in the header of the Delegated The sender MUST set the Result field in the header of the Delegated
Bandwidth Query Request message to AckAll (0x2). The Code value MUST Bandwidth Query Request message to AckAll (0x2). The Code value MUST
be set to 0x000. The sender MUST populate the ANCP Transaction be set to 0x000. The sender MUST populate the ANCP Transaction
Identifier field with a unique value, as described in section 5.4.5 Identifier field with a unique value, as described in Section 4.4.1
of [I-D.ietf-ancp-protocol]. of [I-D.ietf-ancp-protocol].
4.7.2. Receiver Behaviour 4.7.2. Receiver Behaviour
If the AN or NAS receives a valid Delegated Bandwidth Query Request If the AN or NAS receives a valid Delegated Bandwidth Query Request
message, it MUST respond with a Delegated Bandwidth Query Response message, it MUST respond with a Delegated Bandwidth Query Response
message. The Result field in the header of the response MUST be set message. The Result field in the header of the response MUST be set
to Success (0x3). The Code field MUST be set to 0x000. The to Success (0x3). The Code field MUST be set to 0x000. The
Transaction-Id field MUST be copied from the request message. The Transaction-Id field MUST be copied from the request message. The
body of the response MUST contain the Target TLV, copied from the body of the response MUST contain the Target TLV, copied from the
skipping to change at page 34, line 17 skipping to change at page 36, line 17
Flow Query Response messages is 149. Flow Query Response messages is 149.
The contents of the Multicast Flow Query Request and Response depend The contents of the Multicast Flow Query Request and 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 4.4.1 of [I-D.ietf-ancp-
protocol]. protocol].
The Multicast Flow Query Request MAY be used by the NAS to retrieve: The Multicast Flow Query Request MAY be used by the NAS to retrieve:
o the AN's view of which multicast flows are currently active on a o the AN's view of which multicast flows are currently active on a
specified set of access ports; or specified set of access ports; or
o the AN's view of the access ports on which a specified set of o the AN's view of the access ports on which a specified set of
multicast flows are currently active; or multicast flows are currently active; or
skipping to change at page 35, line 31 skipping to change at page 37, 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 Multicast-Flow o Multicast-Flow TLV. This MUST be identical to the Multicast- Flow
TLV in the received Multicast Flow Query Request message. TLV in the received Multicast Flow Query Request message.
o Target TLV(s). The Target TLV MUST appear once per AN port on o Target TLV(s). The Target TLV MUST appear once per AN port on
which the multicast flow identified in the preceding Multicast which the multicast flow identified in the preceding Multicast
Flow TLV is active. Flow TLV is active.
The Multicast-Flow TLVs MUST appear in the response from the AN in The Multicast-Flow TLVs MUST appear in the response from the AN in
the same order as in the query from the NAS. the same order as in the query from the NAS.
If the Multicast Flow Query Request contained no Target TLV and no If the Multicast Flow Query Request contained no Target TLV and no
skipping to change at page 36, line 14 skipping to change at page 38, line 14
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.
The amount of information in the response to the Multicast Flow Query 4.10. Committed Bandwidth Report Message
Request may be very large. The AN MAY pass the information in a
series of Multicast Flow Query Response messages so that the control This section describes the Committed Bandwidth Report message, which
channel to the NAS is not blocked for too long by transmission of a is sent from the AN to the NAS to report the most recent amount of
single very large message. To support this, the receiver MUST set multicast bandwidth usage committed to one or more access lines.
the I flag and Submessage Number fields in the header of each
Multicast Flow Query Response message making up the complete response The Message Type for the Committed Bandwidth Report message is 150.
in accordance with the usage of these fields as described in Section
3.1.1 of [RFC3292]. That is, the initial Multicast Flow Query The Committed Bandwidth Report message contains one or more instances
Response message in the sequence MUST have the I flag set (0x1) and of the Committed-Bandwidth TLV, as described in Section 5.13.
the Submessage Number field value equal to the total number of
messages making up the complete response. The remaining messages in 4.10.1. Sender Behaviour
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 sender of a Committed Bandwidth Report message MUST set the
the complete sequence, counting from 2 for the second message in the Result field to Ignore (0x0). The Code field MUST be set to 0x000.
sequence. Moreover, every message in the sequence except the last The sender MUST populate the ANCP Transaction Identifier field with a
one MUST have the Result field value equal to "More" (0x5). The unique value, as described in section 4.4.1 of [I-D.ietf-ancp-
final message in the response MUST have the Result field set to protocol].
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 Each instance of the Committed-Bandwidth TLV included in the message
contents in the same order as if all of the information had been MUST identify an access line for which the amount of committed
presented in just one message, according to the rules described multicast bandwidth has changed since the previous Committed
above. Bandwidth Report message was sent and MUST report the latest amount
of multicast bandwidth committed to that line. There MUST be only
one instance of the Committed-Bandwidth TLV present in the message
for any given access line. The message MUST include an instance of
the Committed-Bandwidth TLV for every access line for which committed
multicast bandwidth has changed since the previous Committed
Bandwidth Report message was sent.
Further behaviour at the AN is specified in Section 6.2.2.
4.10.2. Receiver Behaviour
The usage of the contents of a Committed Bandwidth Report message
received by the NAS is implementation-dependent. One example is that
the NAS uses the reports of multicast bandwidth commitments to adjust
its forwarding scheduler operation to provide the intended level of
QoS.
The NAS MUST NOT reply to a valid Committed Bandwidth Report message.
The NAS MAY send a Generic Response message indicating the nature of
any errors detected in a Committed Bandwidth Report message that it
has received.
5. ANCP TLVs For Multicast 5. ANCP TLVs For Multicast
This section defines new ANCP TLVs for the control of multicast This section defines new ANCP TLVs for the control of multicast
flows. flows.
5.1. Multicast-Service-Profile TLV 5.1. Multicast-Service-Profile TLV
This document defines the new Multicast-Service-Profile TLV. This document defines the new Multicast-Service-Profile TLV.
The Multicast-Service-Profile TLV MAY be included in a Provisioning The Multicast-Service-Profile TLV MAY be included in a Provisioning
message as specified in Section 4.1. message as specified in Section 4.1.
The Multicast-Service-Profile TLV is illustrated in Figure 5. It The Multicast-Service-Profile TLV is illustrated in Figure 6. It
consists of a TLV header encapsulating a single instance of the consists of a TLV header encapsulating a single instance of the
Multicast-Service-Profile-Name TLV and one or more instances of the Multicast-Service- Profile-Name TLV and one or more instances of the
List-Action TLV. List-Action TLV.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Mcast Serv Profile | TLV Length | |TLV Type = Mcast Serv Profile | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Service-Profile-Name TLV | | Multicast-Service-Profile-Name TLV |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action TLV | | List-Action TLV |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action TLV | | List-Action TLV |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Multicast-Service-Profile TLV Figure 6: Multicast-Service-Profile TLV
The Multicast-Service-Profile TLV has the following fields: The Multicast-Service-Profile TLV has the following fields:
o The Multicast-Service-Profile TLV Type is 0x13. o The Multicast-Service-Profile TLV Type is 0x13.
o The TLV length is determined by the contents following the TLV o The TLV length is determined by the contents following the TLV
header. header.
o The Multicast-Service-Profile-Name TLV is described in o The Multicast-Service-Profile-Name TLV is described in
Section 5.2. The Multicast-Service-Profile-Name TLV MUST contain Section 5.2. The Multicast-Service-Profile-Name TLV MUST contain
an identifier which is unique over all profiles provisioned to the an identifier which is unique over all profiles provisioned to the
same AN partition. This identifier will be used to refer 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 profile when activating it for a given target within a Port
Management message (see Section 4.2). Management message (see Section 4.2).
o The List-Action TLV is described in Section 5.3. The List-Action 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 TLV(s) provide the content of a newly defined multicast service
profile or modify the existing content. If more than one List- profile or modify the existing content. If more than one List-
Action TLV is present, the order of the TLVs may be significant, Action TLV is present, the order of the TLVs may be significant,
since List-Action TLVs are processed in the order in whch they since List- Action TLVs are processed in the order in whch they
appear. appear.
5.2. Multicast-Service-Profile-Name TLV 5.2. Multicast-Service-Profile-Name TLV
The Multicast-Service-Profile-Name TLV carries the identifier of a The Multicast-Service-Profile-Name TLV carries the identifier of a
multicast service profile provisioned on the AN. It is illustrated multicast service profile provisioned on the AN. It is illustrated
in Figure 6. in Figure 7.
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 = MSP Name | TLV Length | |TLV Type = MSP Name | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile identifier | | Multicast service profile identifier |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Multicast-Service-Profile-Name TLV Figure 7: Multicast-Service-Profile-Name TLV
The Multicast-Service-Profile-Name TLV has the following fields: The Multicast-Service-Profile-Name TLV has the following fields:
o The Multicast-Service-Profile-Name TLV Type is 0x18. o The Multicast-Service-Profile-Name TLV Type is 0x18.
o TLV Length: up to 255 octets. o TLV Length: up to 255 octets.
o Multicast service profile identifier: an opaque sequence of bits o Multicast service profile identifier: an opaque sequence of bits
identifying a specific multicast service profile. identifying a specific multicast service profile.
skipping to change at page 38, line 51 skipping to change at page 41, line 51
arbitrary binary value, depending on the operator's practices. arbitrary binary value, depending on the operator's practices.
5.3. List-Action TLV 5.3. List-Action TLV
The List-Action TLV identifies multicast flows to be added to or The List-Action TLV identifies multicast flows to be added to or
removed from a list of White-, Black-, or Grey-listed flows. It is removed from a list of White-, Black-, or Grey-listed flows. It is
meaningful only in association with a Multicast-Service-Profile-Name meaningful only in association with a Multicast-Service-Profile-Name
TLV identifying the profile to which the List-Action TLV applies. TLV identifying the profile to which the List-Action TLV applies.
Such an association can be achieved by placing both TLVs in the same Such an association can be achieved by placing both TLVs in the same
base message payload or as embedded TLVs of another TLV such as the base message payload or as embedded TLVs of another TLV such as the
Multicast-Service-Profile. The List-Action TLV is shown in Figure 7. Multicast-Service-Profile. The List-Action TLV is shown in Figure 8.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action TLV | TLV Length | | TLV Type = List-Action TLV | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation | List Type | Reserved | | Operation | List Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields | | Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 39, line 25 skipping to change at page 42, line 25
...... ......
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields | | Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields | | Multicast flow fields |
...... ......
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: List-Action TLV Figure 8: List-Action TLV
The List-Action TLV contains the following fields: The List-Action TLV contains the following fields:
o The List-Action TLV Type is 0x21. o The List-Action TLV Type is 0x21.
o TLV Length: length of the subsequent contents. o TLV Length: length of the subsequent contents.
o Operation: operation to be performed upon the White, Black, or o Operation: operation to be performed upon the White, Black, or
Grey list identified by the List Type field within the profile Grey list identified by the List Type field within the profile
identified by the associated Multicast-Service-Profile-Name identified by the associated Multicast-Service-Profile-Name
skipping to change at page 40, line 22 skipping to change at page 43, line 22
that follow, encoded according to [PIMreg]. Possible values are that follow, encoded according to [PIMreg]. Possible values are
0x0001 (IPv4) or 0x0002 (IPv6). Either an IPv4 list or an IPv6 0x0001 (IPv4) or 0x0002 (IPv6). Either an IPv4 list or an IPv6
list or both MAY be present in the List-Action TLV. list or both MAY be present in the List-Action TLV.
o Number of flow fields: the number of multicast flow fields of the o Number of flow fields: the number of multicast flow fields of the
given address family which follow. given address family which follow.
o Multicast flow field: a field identifying one or more multicast o Multicast flow field: a field identifying one or more multicast
flows. It consists of an 8-bit group address prefix length, an flows. It consists of an 8-bit group address prefix length, an
8-bit source address prefix length, a 0-16 octet group prefix, and 8-bit source address prefix length, a 0-16 octet group prefix, and
a 0-16 octet source prefix, as shown in Figure 8. a 0-16 octet source prefix, as shown in Figure 9.
Each multicast flow field refers either to a Source-Specific Each multicast flow field refers either to a Source-Specific
Multicast (SSM) channel or to an Any Source Multicast (ASM) group. Multicast (SSM) channel or to an Any Source Multicast (ASM) group.
The scope of the designation may be broadened to multiple channels or The scope of the designation may be broadened to multiple channels or
groups through use of prefix length values smaller than the total groups through use of prefix length values smaller than the total
address length for the given address family. Multicast flow fields address length for the given address family. Multicast flow fields
MUST be placed consecutively within the embedded TLV without MUST be placed consecutively within the embedded TLV without
intervening padding except to round out individual addresses to the intervening padding except to round out individual addresses to the
nearest octet boundary. nearest octet boundary.
A multicast flow field consists of two single-octet prefix lengths A multicast flow field consists of two single-octet prefix lengths
followed by zero to two prefix values as shown in Figure 8: followed by zero to two prefix values as shown in Figure 9:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 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 8: Organization of a Single Multicast Flow Field Figure 9: 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
skipping to change at page 41, line 27 skipping to change at page 44, line 27
5.4. Sequence-Number TLV 5.4. Sequence-Number TLV
The Sequence-Number TLV conveys a sequence number of some sort. The The Sequence-Number TLV conveys a sequence number of some sort. The
specific meaning of the sequence number is message-specific. Within specific meaning of the sequence number is message-specific. Within
this specification, the Sequence-Number TLV is used as a embedded TLV this specification, the Sequence-Number TLV is used as a embedded TLV
within a Status-Info TLV, in a Generic Response reporting a failed 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. It identifies the sequence number within the Request message. It identifies the sequence number within the
message of the command that failed. message of the command that failed.
The Sequence-Number TLV has the format shown in Figure 9. The Sequence-Number TLV has the format shown in Figure 10.
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 = Sequence-Number | TLV Length = 4 | |TLV Type = Sequence-Number | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number | | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Sequence-Number TLV Figure 10: Sequence-Number TLV
The Sequence-Number TLV has the following fields: The Sequence-Number TLV has the following fields:
o The Sequence-Number TLV Type is 0x22. o The Sequence-Number TLV Type is 0x22.
o TLV length is 0x0004. o TLV length is 0x0004.
o Sequence number: the sequence number of a specific entity within a o Sequence number: the sequence number of a specific entity within a
series, where numbering starts from 1 for the first entity in the series, where numbering starts from 1 for the first entity in the
series. Represented as a 32-bit binary number, most significant series. Represented as a 32-bit binary number, most significant
bit first. bit first.
5.5. Bandwidth-Allocation TLV 5.5. Bandwidth-Allocation TLV
The Bandwidth-Allocation TLV is used to indicate the total amount of The Bandwidth-Allocation TLV is used to indicate the total amount of
video bandwidth delegated to the AN for multicast admission control video bandwidth delegated to the AN for multicast admission control
for a given access line, in kilobits per second. The TLV has the for a given access line, in kilobits per second. The TLV has the
format shown in Figure 10. format shown in Figure 11.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = BW-Allocation | TLV Length = 4 | |TLV Type = BW-Allocation | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount (kbits/s) | | Delegated amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: The Bandwidth-Allocation TLV Figure 11: The Bandwidth-Allocation TLV
The Bandwidth-Allocation TLV has the following fields: The Bandwidth-Allocation TLV has the following fields:
o The Bandwidth-Allocation TLV Type is 0x15. o The Bandwidth-Allocation TLV Type is 0x15.
o TLV length is 4. o TLV length is 4.
o Delegated amount: the bandwidth amount delegated to the AN for o Delegated amount: the bandwidth amount delegated to the AN for
admission of multicast video on a given port, kilobits per second. admission of multicast video on a given port, kilobits per second.
Presented as a 32-bit binary value, most significant bit first. Presented as a 32-bit binary value, most significant bit first.
5.6. White-List-CAC TLV 5.6. White-List-CAC TLV
The White-List-CAC TLV is used to indicate that the NAS wishes the AN The White-List-CAC TLV is used to indicate that the NAS wishes the AN
to do admission control for White-listed flows. Details on when the to do admission control for White-listed flows. Details on when the
White-List-CAC TLV may be provisioned are specified in Section 6. White-List-CAC TLV may be provisioned are specified in Section 6.
The White-List-CAC TLV is illustrated in Figure 11. The White- List-CAC TLV is illustrated in Figure 12.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = White-List-CAC | TLV Length = 0 | |TLV Type = White-List-CAC | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: White-List-CAC TLV Figure 12: White-List-CAC TLV
The White-List-CAC TLV contains the following fields: The White-List-CAC TLV contains the following fields:
o The White-List-CAC TLV Type is 0x24. o The White-List-CAC TLV Type is 0x24.
o TLV length is 0, since the TLV contains no data other than the TLV o TLV length is 0, since the TLV contains no data other than the TLV
header. header.
5.7. MRepCtl-CAC TLV 5.7. MRepCtl-CAC TLV
The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to
do admission control for flows added by the Multicast Replication do admission control for flows added by the Multicast Replication
Control message. Details on when the MRepCtl-CAC TLV may be Control message. Details on when the MRepCtl-CAC TLV may be
provisioned are specified in Section 6. The MRepCtl-CAC TLV is provisioned are specified in Section 6. The MRepCtl-CAC TLV is
illustrated in Figure 12. illustrated in Figure 13.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = MRepCtl-CAC | TLV Length = 0 | |TLV Type = MRepCtl-CAC | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: MRepCtl-CAC TLV Figure 13: MRepCtl-CAC TLV
The MRepCtl-CAC TLV contains the following fields: The MRepCtl-CAC TLV contains the following fields:
o The MRepCtl-CAC TLV Type is 0x25. o The MRepCtl-CAC TLV Type is 0x25.
o TLV length is 0, since the TLV contains no data other than the TLV o TLV length is 0, since the TLV contains no data other than the TLV
header. header.
5.8. Bandwidth-Request TLV 5.8. Bandwidth-Request TLV
The Bandwidth-Request TLV is used to request an adjustment of the The Bandwidth-Request TLV is used to request an adjustment of the
total amount of video bandwidth allocated to the AN for multicast total amount of video bandwidth allocated to the AN for multicast
admission control for a given line. The "Required amount" field admission control for a given line. The "Required amount" field
indicates the minimum adjustment required to meet the request. The indicates the minimum adjustment required to meet the request. The
"Preferred amount" field indicates the adjustment the requestor would "Preferred amount" field indicates the adjustment the requestor would
prefer to have, if possible. Section 4.5 discusses the required prefer to have, if possible. Section 4.5 discusses the required
relationships between the "Required amount", "Preferred amount", and relationships between the "Required amount", "Preferred amount", and
current values of total bandwidth allocated to the AN. current values of total bandwidth allocated to the AN.
The Bandwidth-Request TLV has the format shown in Figure 13. The Bandwidth-Request TLV has the format shown in Figure 14.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Request | TLV Length = 8 | |TLV Type = Bandwidth-Request | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required amount (kbits/s) | | Required amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred amount (kbits/s) | | Preferred amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: The Bandwidth-Request TLV Figure 14: The Bandwidth-Request TLV
The Bandwidth-Request TLV has the following fields: The Bandwidth-Request TLV has the following fields:
o The Bandwidth-Request TLV Type is 0x16. o The Bandwidth-Request TLV Type is 0x16.
o The TLV length is 8 octets. o The TLV length is 8 octets.
o Required amount: the minimum or maximum amount, depending on o Required amount: the minimum or maximum amount, depending on
whether the sender is the AN or the NAS respectively, of delegated whether the sender is the AN or the NAS respectively, of delegated
video bandwidth that is being requested, in kilobits per second. video bandwidth that is being requested, in kilobits per second.
Presented as a 32-bit binary value, most significant bit first. Presented as a 32-bit binary value, most significant bit first.
o Preferred amount: the preferred amount of delegated video o Preferred amount: the preferred amount of delegated video
bandwidth that is being requested, in kilobits per second. bandwidth that is being requested, in kilobits per second.
Presented as a 32-bit binary value, most significant bit first. Presented as a 32-bit binary value, most significant bit first.
5.9. Request-Source-IP TLV 5.9. Request-Source-IP TLV
The Request-Source-IP TLV provides the IP address of the entity that The Request-Source-IP TLV provides the IP address of the entity that
originated a specific request to join or leave a multicast channel. originated a specific request to join or leave a multicast channel.
The TLV is illustrated in Figure 14. The TLV is illustrated in Figure 15.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Request-Source-IP | TLV length = 4 or 16 | | TLV Type = Request-Source-IP | TLV length = 4 or 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Address | | Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Request-Source-IP TLV Figure 15: Request-Source-IP TLV
The Request-Source-IP TLV contains the following fields: The Request-Source-IP TLV contains the following fields:
o The Request-Source-IP TLV Type is 0x92. o The Request-Source-IP TLV Type is 0x92.
o TLV length is 4 for an IPv4 address or 16 for an IPv6 address. o TLV length is 4 for an IPv4 address or 16 for an IPv6 address.
o Unicast address: IP address of the source of a multicast flow join o Unicast address: IP address of the source of a multicast flow join
request, in network byte order. request, in network byte order.
5.10. Request-Source-MAC TLV 5.10. Request-Source-MAC TLV
The Request-Source-MAC TLV provides the MAC address of the entity The Request-Source-MAC TLV provides the MAC address of the entity
that originated a specific request to join or leave a multicast that originated a specific request to join or leave a multicast
channel. The TLV is illustrated in Figure 15. channel. The TLV is illustrated in Figure 16.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type=Request-Source-MAC | TLV Length = 6 or 8 | |TLV Type=Request-Source-MAC | TLV Length = 6 or 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IEEE MAC Address | | |
+-+-+- IEEE MAC Address +-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Request-Source-MAC TLV Figure 16: Request-Source-MAC TLV
The Request-Source-MAC TLV contains the following fields: The Request-Source-MAC TLV contains the following fields:
o The Request-Source-MAC TLV Type is 0x93. o The Request-Source-MAC TLV Type is 0x93.
o TLV length is either 6 octets (MAC-48 or EUI-48) or 8 octets o TLV length is either 6 octets (MAC-48 or EUI-48) or 8 octets
(EUI-64). (EUI-64).
o IEEE MAC Address: MAC address of the device originating the o IEEE MAC Address: MAC address of the device originating the
request to join a multicast flow. Within the address, bytes and request to join a multicast flow. Within the address, bytes and
bits respectively shall be ordered from most to least significant, bits respectively shall be ordered from most to least significant,
consistently with [IEEE48] for MAC-48 and EUI-48, and with consistently with [IEEE48] for MAC-48 and EUI-48, and with
[IEEE64] for EUI-64. [IEEE64] for EUI-64.
EUI-48 and EUI-64 are registered trademarks of the IEEE. EUI-48 and EUI-64 are registered trademarks of the IEEE.
5.11. Multicast-Flow TLV 5.11. Multicast-Flow TLV
The Multicast-Flow TLV specifies a multicast flow in terms of its The Multicast-Flow TLV specifies a multicast flow in terms of its
multicast group address and, if applicable, its unicast source multicast group address and, if applicable, its unicast source
address. It is illustrated in Figure 16. address. It is illustrated in Figure 17.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Multicast-Flow | TLV Length | |TLV Type = Multicast-Flow | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Addr Family | Reserved | | Flow Type | Addr Family | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address | | Multicast Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Unicast Source Address (for SSM flows only) | | Unicast Source Address (for SSM flows only) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Multicast-Flow TLV Figure 17: Multicast-Flow TLV
The Multicast-Flow TLV has the following fields: The Multicast-Flow TLV has the following fields:
o The Multicast-Flow TLV Type is 0x19. o The Multicast-Flow TLV Type is 0x19.
o TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow) to o TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow) to
36 (for an IPv6 SSM flow. 36 (for an IPv6 SSM flow.
o Flow Type: 0x01 for Any Source Multicast (ASM), 0x02 for Specific- o Flow Type: 0x01 for Any Source Multicast (ASM), 0x02 for Specific-
Source Multicast (SSM). Source Multicast (SSM).
skipping to change at page 47, line 5 skipping to change at page 49, line 33
in the context of ANCP is for further study. in the context of ANCP is for further study.
o Multicast Group Address: a multicast group address within the o Multicast Group Address: a multicast group address within the
given address family. The group address MUST always be present. given address family. The group address MUST always be present.
o Unicast Source Address: unicast address within the given address o Unicast Source Address: unicast address within the given address
family. If the Flow Type is 0x01 (ASM), a source address MUST NOT family. If the Flow Type is 0x01 (ASM), a source address MUST NOT
be present. If the Flow Type is 0x02 (SSM), a source address MUST be present. If the Flow Type is 0x02 (SSM), a source address MUST
be present. be present.
5.12. Report-Buffering-Time TLV
The Report-Buffering-Time TLV provides the time for which a Committed
Bandwidth Report message must be held with the intention of
accumulating multiple reports of changed committed multicast
bandwidth in one report, to reduce the volume of messages sent to the
NAS. For further information see Section 6.2.2. The TLV is
illustrated in Figure 18.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type=Report-Buffering-Time | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffering Time (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Report-Buffering-Time TLV
The Report-Buffering-Time TLV contains the following fields:
o The Report-Buffering-Time TLV Type is 0x94.
o TLV length is 4 octets.
o Buffering Time is a 32-bit unsigned integer containing a time
value in ms.
5.13. Committed-Bandwidth TLV
The Committed-Bandwidth TLV identifies an access line and provides
the current amount of multicast bandwidth that the AN has committed
to it. The TLV is illustrated in Figure 19.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type=Committed-Bandwidth | TLV Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Multicast Bandwidth (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+- Target TLV +-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Committed-Bandwidth TLV
The Committed-Bandwidth TLV contains the following fields:
o The Committed-Bandwidth TLV Type is 0x95.
o TLV length is 4 octets plus the length of the Target TLV including
its header and any padding.
o Committed Multicast Bandwidth is a 32-bit unsigned integer
providing a bandwidth amount in kbits/s.
o The Target TLV identifies the access line to which this amount of
multicast bandwidth is currently committed.
6. Multicast Capabilities 6. Multicast Capabilities
Section 5.3 of [I-D.ietf-ancp-protocol] defines a capability Section 4.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 five 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 0x03);
o committed multicast bandwidth reporting (capability type 0x05);
o conditional access with white and black lists (capability type o conditional access with white and black lists (capability type
0x06); 0x06);
o conditional access with grey lists (capability type 0x07); o conditional access with grey lists (capability type 0x07);
o bandwidth delegation (capability type 0x08). o bandwidth delegation (capability type 0x08).
The "Capability Data" field within the Capability TLV for all of The "Capability Data" field within the Capability TLV for all of
these capabilities is empty. these capabilities is empty. All of these capabilities are
independent of the access technology.
The remainder of this section consists of three sub-sections. The remainder of this section consists of three sub-sections.
Section 6.1 specifies the protocol elements that must be implemented Section 6.1 specifies the protocol elements that must be implemented
in order to support each capability. Section 6.2 specifies the in order to support each capability. Section 6.2 specifies the
procedures that apply to each capability on its own. Section 6.3 procedures that apply to each capability on its own. Section 6.3
specifies how the capabilities interact if more than one multicast specifies how the capabilities interact if more than one multicast
capability is included in the set of capabilities negotiated between capability is included in the set of capabilities negotiated between
the AN and the NAS. the AN and the NAS.
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., 84 "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 6.1.3 and 6.2.3 in [I-D.ietf-ancp-protocol] for
for more details. 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
skipping to change at page 48, line 27 skipping to change at page 52, line 32
| | | | | |
| Section 5.4 | Command Number TLV | | Section 5.4 | Command Number TLV |
| | | | | |
| Section 5.7 | MRepCtl-CAC TLV | | Section 5.7 | MRepCtl-CAC TLV |
| | | | | |
| Section 5.11 | Multicast-Flow TLV | | Section 5.11 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 1: Protocol Requirements For NAS-initiated Replication Table 1: Protocol Requirements For NAS-initiated Replication
6.1.2. Protocol Requirements For Conditional Access With White and 6.1.2. Protocol Requirements For Committed Multicast Bandwidth
Black Lists Reporting
Table 2 specifies the protocol elements within Section 4 and Table 2 specifies the protocol elements within Section 4 and
Section 5 that MUST be implemented to support the NAS-initiated
replication multicast capability.
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Report-Buffering-Time |
| | TLV |
| | |
| Section 4.10 | Committed Bandwidth Report message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.12 | Report-Buffering-Timer TLV |
| | |
| Section 5.13 | Committed-Bandwidth TLV |
| | |
| Section 5.11 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 2: Protocol Requirements For Committed Multicast Bandwidth
Reporting
6.1.3. Protocol Requirements For Conditional Access With White and
Black Lists
Table 3 specifies the protocol elements within Section 4 and
Section 5 that MUST be implemented to support the conditional access Section 5 that MUST be implemented to support the conditional access
with white and black lists multicast capability. 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 |
| | | | | |
skipping to change at page 49, line 31 skipping to change at page 54, line 31
| | | | | |
| Section 5.3 | List-Action TLV, White and Black lists only | | Section 5.3 | List-Action TLV, White and Black lists only |
| | | | | |
| Section 5.5 | Bandwidth-Allocation TLV | | Section 5.5 | Bandwidth-Allocation TLV |
| | | | | |
| Section 5.6 | White-List-CAC TLV | | Section 5.6 | White-List-CAC TLV |
| | | | | |
| Section 5.11 | Multicast-Flow TLV | | Section 5.11 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 2: Protocol Requirements For Conditional Access with White and Table 3: Protocol Requirements For Conditional Access with White and
Black Lists Black Lists
6.1.3. Protocol Requirements For Conditional Access With Grey Lists 6.1.4. Protocol Requirements For Conditional Access With Grey Lists
Table 3 specifies the protocol elements within Section 4 and Table 4 specifies the protocol elements within Section 4 and
Section 5 that MUST be implemented to support the conditional access Section 5 that MUST be implemented to support the conditional access
with grey lists multicast capability. 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 |
| | | | | |
skipping to change at page 50, line 41 skipping to change at page 55, line 41
| | | | | |
| Section 5.7 | MRepCtl-CAC TLV | | Section 5.7 | MRepCtl-CAC TLV |
| | | | | |
| Section 5.9 | Request-Source-IP TLV | | Section 5.9 | Request-Source-IP TLV |
| | | | | |
| Section 5.10 | Request-Source-MAC TLV | | Section 5.10 | Request-Source-MAC TLV |
| | | | | |
| Section 5.11 | Multicast-Flow TLV | | Section 5.11 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 3: Protocol Requirements For Conditional Access with Grey Lists Table 4: Protocol Requirements For Conditional Access with Grey Lists
6.1.4. Protocol Requirements For Delegated Bandwidth 6.1.5. Protocol Requirements For Delegated Bandwidth
Table 4 specifies the protocol elements within Section 4 and Table 5 specifies the protocol elements within Section 4 and
Section 5 that MUST be implemented to support the delegated bandwidth Section 5 that MUST be implemented to support the delegated bandwidth
multicast capability. multicast capability.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Reference | Protocol Element | | Reference | Protocol Element |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Section 4.2 | Port Management message with Bandwidth-Allocation | | Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV. | | | TLV. |
| | | | | |
| Section 4.5 | Bandwidth Reallocation Request Message | | Section 4.5 | Bandwidth Reallocation Request Message |
skipping to change at page 51, line 28 skipping to change at page 56, line 28
| | | | | |
| Section 4.9 | Multicast Flow Query Request and Response messages | | Section 4.9 | Multicast Flow Query Request and Response messages |
| | | | | |
| Section 5.5 | Bandwidth-Allocation TLV | | Section 5.5 | Bandwidth-Allocation TLV |
| | | | | |
| Section 5.8 | Bandwidth-Request TLV | | Section 5.8 | Bandwidth-Request TLV |
| | | | | |
| Section 5.11 | Multicast-Flow TLV | | Section 5.11 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 4: Protocol Requirements For Delegated Bandwidth Table 5: Protocol Requirements For Delegated Bandwidth
6.2. Capability-Specific Procedures for Providing Multicast Service 6.2. Capability-Specific Procedures for Providing Multicast Service
This section describes multicast service procedures for each This section describes multicast service procedures for each
capability as if it were the only multicast capability within the capability as if it were the only multicast capability within the
negotiated set. Procedures involving combinations of multicast negotiated set. Procedures involving combinations of multicast
capabilities are described in Section 6.3. capabilities are described in Section 6.3.
The use of the Multicast Flow Query Request and Response messages to The use of the Multicast Flow Query Request and Response messages to
determine the association between multicast flows and ports is common determine the association between multicast flows and ports is common
to all multicast capabilities. No additional text is required here, to all multicast capabilities. No additional text is required here,
beyond that already given in Section 4.9 to describe the use of those beyond that already given in Section 4.9 to describe the use of those
messages. messages.
6.2.1. Procedures For NAS-initiated Replication 6.2.1. Procedures For NAS-Initiated 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.
6.2.1.1. Provisioning 6.2.1.1. Provisioning
skipping to change at page 52, line 26 skipping to change at page 57, line 26
The procedures associated with NAS-initiated replication are The procedures associated with NAS-initiated replication are
straightforward. To initiate replication, the NAS MUST send a straightforward. To initiate replication, the NAS MUST send a
Multicast Replication Control message to the AN, containing one or Multicast Replication Control message to the AN, containing one or
more commands adding flows, as described in Section 4.3.1. To more commands adding flows, as described in Section 4.3.1. To
terminate replication the NAS MUST send a Multicast Replication terminate replication the NAS MUST send a Multicast Replication
Control message where the commands delete instead of adding the Control message where the commands delete instead of adding the
flows. The AN acts upon these messages as specified in flows. The AN acts upon these messages as specified in
Section 4.3.2. Section 4.3.2.
6.2.2. Procedures For Conditional Access With Black and White Lists 6.2.2. Procedures For Committed Bandwidth Reporting
Committed bandwidth reporting MAY be negotiated if the NAS requires
current knowledge of the amount of multicast bandwidth committed to
each access line and cannot obtain this information by other means.
6.2.2.1. Provisioning 6.2.2.1. Provisioning
The default buffering time when committed bandwidth reporting is
enabled is zero (immediate reporting). To change this, the NAS MAY
send an instance of the Report-Buffering-Time TLV containing a non-
zero time value to the AN in a Provisioning message. If the NAS
subsequently wishes to change the buffering time again, it MAY do so
in another Provisioning message.
6.2.2.2. Multicast Service Procedures
If the buffering time for committed bandwidth reporting is zero, the
AN MUST send a Committed Bandwidth Report message to the NAS each
time the amount of multicast bandwidth committed to any access line
under its control changes.
If a non-zero value is provided in the Report-Buffering-Time TLV, the
AN at any given moment is in one of two states: not-buffering, or
buffering. The AN enters buffering state if it is in not-buffering
state and the multicast bandwidth amount committed to some access
line changes. It leaves buffering state when the AN sends a
Committed Bandwidth Report.
Upon entry to the buffering state, the AN MUST start a buffering
timer and create a Committed Bandwidth Report message containing a
Committed-Bandwidth TLV for the triggering access line, but MUST NOT
send it. If a multicast bandwidth change occurs for another access
line, the AN MUST add a new Committed-Bandwidth TLV to the message
for that additional line. If a multicast bandwidth change occurs for
a line for which a Committed-Bandwidth TLV is already present in the
buffered report, the AN MUST update the Committed-Bandwidth TLV to
contain the new bandwidth value, rather than adding another
Committed-Bandwidth TLV for the same access line.
The buffering timer expires after the period provided by the Report-
Buffering-Time TLV. When it expires, the AN MUST send the Committed
Bandwidth Report message that it has been accumulating to the NAS.
Exceptionally, the AN MAY choose to send the message before the timer
expires, in which case it MUST clear the buffering timer when the
message is sent. In either case, the AN enters the not-buffering
state as a result.
Report buffering implies that NAS reaction to changes in multicast
bandwidth usage is delayed by the amount of the buffering period.
The choice of buffering period must take this into consideration.
6.2.3. Procedures For Conditional Access With Black and White Lists
6.2.3.1. Provisioning
The NAS provisions named multicast service profiles containing White The NAS provisions named multicast service profiles containing White
and Black lists on the AN using the Provisioning message containing and Black lists on the AN using the Provisioning message containing
one or more Multicast-Service-Profile TLVs. The NAS MAY update the one or more Multicast-Service-Profile TLVs. The NAS MAY update the
contents of these profiles from time to time as required, by sending contents of these profiles from time to time as required, by sending
additional Provisioning messages with Multicast-Service-Profile TLVs additional Provisioning messages with Multicast-Service-Profile TLVs
containing incremental modifications to the existing White and Black containing incremental modifications to the existing White and Black
lists or replacements for them. lists or replacements for them.
The NAS assigns a specific multicast service profile to an individual The NAS assigns a specific multicast service profile to an individual
access line using the Port Management message containing a Multicast- access line using the Port Management message containing a Multicast-
Service-Profile-Name TLV. The NAS MAY change the multicast service Service-Profile-Name TLV. The NAS MAY change the multicast service
profile for a given access line at any time by sending a Port profile for a given access line at any time by sending a Port
Management message identifying a new multicast service profile. Management message identifying a new multicast service profile.
The NAS MAY choose to enable admission control at the AN for White- The NAS MAY choose to enable admission control at the AN for White-
listed flows. To do this, it MUST send a Provisioning message as listed flows. To do this, it MUST send a Provisioning message as
described in Section 4.1, which includes the White-List-CAC TLV and described in Section 4.1, which includes the White-List-CAC TLV and
it MUST provide a multicast bandwidth allocation for each access line it MUST provide a multicast bandwidth allocation for each access line
by including a Bandwidth-Allocation TLV in a Port Management message. by including a Bandwidth-Allocation TLV in a Port Management message.
6.2.2.2. Multicast Service Procedures 6.2.3.2. Multicast Service Procedures
The conditional access with White and Black lists capability assumes The conditional access with White and Black lists capability assumes
that IGMP/MLD requests are terminated on the AN. When the AN that IGMP/MLD requests are terminated on the AN. When the AN
receives a "join" request, it MUST check to see whether the requested receives a "join" request, it MUST check to see whether the requested
flow is White-listed or Black-listed as described below. Requests flow is White-listed or Black-listed as described below. Requests
for Black-listed flows MUST be discarded. If the NAS has enabled for Black-listed flows MUST be discarded. If the NAS has enabled
admission control on the AN as described in the previous section, but admission control on the AN as described in the previous section, but
a White-listed flow would cause the amount of committed multicast a White-listed flow would cause the amount of committed multicast
bandwidth to exceed the provisioned limit, the request MUST be bandwidth to exceed the provisioned limit, the request MUST be
discarded. The AN replicates flows passing these checks to the discarded. The AN replicates flows passing these checks to the
skipping to change at page 54, line 7 skipping to change at page 60, line 7
multicast service profile, the AN MUST review the status of active multicast service profile, the AN MUST review the status of active
flows on all ports to which the updated profile is currently flows on all ports to which the updated profile is currently
assigned. Similarly, if a Port Management message assigns a new assigned. Similarly, if a Port Management message assigns a new
multicast service profile to a given port, the AN MUST review all multicast service profile to a given port, the AN MUST review all
active flows on that port. If the most specific match for any flow active flows on that port. If the most specific match for any flow
is a Black list entry, the flow MUST be terminated immediately. If is a Black list entry, the flow MUST be terminated immediately. If
any of the remaining flows do not match an entry in the White list, any of the remaining flows do not match an entry in the White list,
they also MUST be terminated immediately. White listed flows MUST be they also MUST be terminated immediately. White listed flows MUST be
allowed to continue. allowed to continue.
6.2.3. Procedures For Conditional Access With Grey Lists 6.2.4. Procedures For Conditional Access With Grey Lists
6.2.3.1. Provisioning 6.2.4.1. Provisioning
The NAS provisions named multicast service profiles containing Grey The NAS provisions named multicast service profiles containing Grey
lists on the AN using the Provisioning message containing one or more lists on the AN using the Provisioning message containing one or more
Multicast-Service-Profile TLVs. The NAS MAY update the contents of Multicast-Service-Profile TLVs. The NAS MAY update the contents of
these profiles from time to time as required, by sending additional these profiles from time to time as required, by sending additional
Provisioning messages with Multicast-Service-Profile TLVs containing Provisioning messages with Multicast-Service-Profile TLVs containing
incremental modifications to the existing Grey lists or replacements incremental modifications to the existing Grey lists or replacements
for them. for them.
The NAS assigns a specific multicast service profile to an individual The NAS assigns a specific multicast service profile to an individual
access line using the Port Management message containing a Multicast- access line using the Port Management message containing a Multicast-
Service-Profile-Name TLV. The NAS MAY change profiles on the line by Service-Profile-Name TLV. The NAS MAY change profiles on the line by
sending a subsequent Port Management message identifying a new sending a subsequent Port Management message identifying a new
profile. profile.
The NAS MAY perform admission control for grey-listed flows. In that The NAS MAY perform admission control for grey-listed flows. In that
case, the NAS MUST NOT include the MRepCtl-CAC TLV in a Provisioning case, the NAS MUST NOT include the MRepCtl-CAC TLV in a Provisioning
message sent to the AN. Alternatively, the NAS MAY enable admission message sent to the AN. Alternatively, the NAS MAY enable admission
control at the AN for Grey-listed flows. To do this, it MUST include control at the AN for Grey-listed flows. To do this, it MUST include
the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST the MRepCtl-CAC TLV in a Provisioning message sent to the AN and MUST
also provide a Bandwidth-Allocation TLV in a Port Management message also provide a Bandwidth- Allocation TLV in a Port Management message
for each access line. for each access line.
6.2.3.2. Multicast Service Procedures 6.2.4.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
skipping to change at page 55, line 29 skipping to change at page 61, line 29
NAS updates its internal records but MUST NOT respond to the message. NAS updates its internal records but MUST NOT respond to the message.
If the AN receives a Provisioning message which updates an existing If the AN receives a Provisioning message which updates an existing
multicast service profile, the AN MUST review the status of active multicast service profile, the AN MUST review the status of active
flows on all ports to which the updated profile has been assigned. flows on all ports to which the updated profile has been assigned.
Similarly, if a Port Management message that assigns a new profile to Similarly, if a Port Management message that assigns a new profile to
a given port, the AN MUST review all active flows on that port. In 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 either case, if any flow does not match an entry in the Grey list, it
MUST be terminated immediately. MUST be terminated immediately.
6.2.4. Procedures For Delegated Bandwidth 6.2.5. Procedures For Delegated Bandwidth
6.2.4.1. Provisioning 6.2.5.1. Provisioning
The NAS SHOULD provision an initial amount of delegated multicast The NAS SHOULD provision an initial amount of delegated multicast
bandwidth for each access line using the Port Management message bandwidth for each access line using the Port Management message
containing the Bandwidth-Allocation TLV. containing the Bandwidth-Allocation TLV.
If it fails to do so and a value has not been provisioned on the If it fails to do so and a value has not been provisioned on the
AN by other means, the AN will be forced to request a bandwidth AN by other means, the AN will be forced to request a bandwidth
allocation as soon as it receives a "join" request. allocation as soon as it receives a "join" request.
The NAS MAY at any time force an update of the amount of delegated The NAS MAY at any time force an update of the amount of delegated
bandwidth by the same means. bandwidth by the same means.
6.2.4.2. Multicast Service Procedures 6.2.5.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
whether it has granted the request, and if so, what is the new amount whether it has granted the request, and if so, what is the new amount
of delegated bandwidth. of delegated bandwidth.
skipping to change at page 56, line 34 skipping to change at page 62, line 34
autonomous Bandwidth Transfer message. The contents of this message autonomous Bandwidth Transfer message. The contents of this message
are described in Section 4.6. are described in Section 4.6.
6.3. Combinations of Multicast Capabilities 6.3. Combinations of Multicast Capabilities
6.3.1. Combination of Conditional Access With White and Black Lists and 6.3.1. Combination of Conditional Access With White and Black Lists and
Conditional Access With Grey Lists Conditional Access With Grey Lists
If conditional access with White and Black lists is combined with If conditional access with White and Black lists is combined with
conditional access with Grey lists, provisioning of the multicast conditional access with Grey lists, provisioning of the multicast
service profiles is as described in Section 6.2.2.1 except that service profiles is as described in Section 6.2.3.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 on the AN for White lists by control is enabled independently on the AN for White lists by
including the White-list-CAC TLV in the Provisioning message and for including the White-list-CAC TLV in the Provisioning message and for
Grey lists by including the MRepCtl-CAC TLV in the Provisioning Grey lists by including the MRepCtl-CAC TLV in the Provisioning
message. The Bandwidth-Allocation TLV provisions an amount that message. The Bandwidth-Allocation TLV provisions an amount that
applies to both White- and Grey- listed flows if admission control is applies to both White- and Grey- listed flows if admission control is
enabled for both. enabled for both.
With regard to multicast service procedures, one point of difference With regard to multicast service procedures, one point of difference
from the individual capabilities must be noted. This is an from the individual capabilities must be noted. This is an
interaction during the profile matching procedure. The AN MUST seek interaction during the profile matching procedure. The AN MUST seek
the best match amongst multiple lists as described in the best match amongst multiple lists as described in
Section 6.2.2.2. However, if there are multiple matches of equal Section 6.2.3.2. However, if there are multiple matches of equal
precision, the order of priority is Black list first, Grey list precision, the order of priority is Black list first, Grey list
second, and White list last. second, and White list last.
Once profile matching has been completed, processing of a "join" Once profile matching has been completed, processing of a "join"
request is as described in Section 6.2.2.2 for White or Black listed request is as described in Section 6.2.3.2 for White or Black listed
flows or Section 6.2.3.2 for Grey listed flows. Requests that do not flows or Section 6.2.4.2 for Grey listed flows. Requests that do not
match any list SHOULD be discarded. match any list SHOULD be discarded.
When the AN receives a "leave" request, it MUST terminate replication When the AN receives a "leave" request, it MUST terminate replication
of the flow to the access line. If the flow was Grey-listed, the AN of the flow to the access line. If the flow was Grey-listed, the AN
MUST then send a Multicast Admission Control message to the NAS MUST then send a Multicast Admission Control message to the NAS
indicating the deletion. 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.
If the AN receives a Provisioning message which updates an existing If the AN receives a Provisioning message which updates an existing
multicast service profile, the AN MUST review the status of active multicast service profile, the AN MUST review the status of active
flows on all ports to which the updated profile is currently flows on all ports to which the updated profile is currently
assigned. Similarly, if a Port Management message assigns a new assigned. Similarly, if a Port Management message assigns a new
multicast service profile to a given port, the AN MUST review all multicast service profile to a given port, the AN MUST review all
active flows on that port. If any flow has its most specific match active flows on that port. If any flow has its most specific match
in a Black list entry, it MUST be terminated immediately. If any of in a Black list entry, it MUST be terminated immediately. If any of
the remaining flows do not match an entry in the White or Grey list, the remaining flows do not match an entry in the White or Grey list,
they MUST also be terminated immediately. Finally, if any remaining they MUST also be terminated immediately. Finally, if any remaining
flows were originally admitted because they were White-listed, but flows were originally admitted because they were White-listed, but
after the change they are Grey-listed, the AN MUST generate a after the change they are Grey- listed, the AN MUST generate a
Multicast Flow Query response message autonomously as if it were Multicast Flow Query response message autonomously as if it were
responding to a Multicast Flow Query request, listing all such flows. responding to a Multicast Flow Query request, listing all such flows.
These flows MUST be allowed to continue until the NAS or the These flows MUST be allowed to continue until the NAS or the
subscriber terminates them. Flows with their most specific match in subscriber terminates them. Flows with their most specific match in
the White list MUST be allowed to continue. the White list MUST be allowed to continue.
The autonomously-generated Multicast Flow Query response message MUST The autonomously-generated Multicast Flow Query response message MUST
be formatted as if it were a successful response to a request be formatted as if it were a successful response to a request
containing no Target and no Multicast-Flow TLV, as described in containing no Target and no Multicast-Flow TLV, as described in
Section 4.9.2, with the exception that the Transaction-Id MUST be set Section 4.9.2, with the exception that the Transaction-Id MUST be set
to all zeroes. to all zeroes.
6.3.2. Combination of Conditional Access With Delegated Bandwidth 6.3.2. Combination of Conditional Access With Delegated Bandwidth
The provisioning and bandwidth management procedures of Section 6.2.4 The provisioning and bandwidth management procedures of Section 6.2.5
apply in addition to the procedures in Section 6.2.2, Section 6.2.3, apply in addition to the procedures in Section 6.2.3, Section 6.2.4,
or Section 6.3.1 as applicable. Admission control follows the rules or Section 6.3.1 as applicable. Admission control follows the rules
for conditional access in terms of matching flows against White and for conditional access in terms of matching flows against White and
Black and/or Grey lists and performing or not performing bandwidth 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 checks at the AN, but the amount of bandwidth used by the AN to
perform admission control is negotiable as described in perform admission control is negotiable as described in
Section 6.2.4.2. Section 6.2.5.2.
6.3.3. Combination of NAS-Initiated Replication with Other Capabilities 6.3.3. Combination of NAS-Initiated Replication with Other Capabilities
NAS-initiated replication can coexist with the other capabilities, NAS-initiated replication can coexist with the other capabilities,
but some means must exist to prevent double replication of flows. but some means must exist to prevent double replication of flows.
The simplest way to do this is to terminate all IGMP/MLD requests on The simplest way to do this is to terminate all IGMP/MLD requests on
the AN, so that NAS-initiated replication is stimulated only by the AN, so that NAS-initiated replication is stimulated only by
signalling through other channels. Other arrangements are possible, signalling through other channels. Other arrangements are possible,
but need not be discussed here. but need not be discussed here.
skipping to change at page 59, line 5 skipping to change at page 64, line 26
Replication Control messages, regardless of whether they are part of Replication Control messages, regardless of whether they are part of
NAS-initiated replication or Grey list multicast service processing. NAS-initiated replication or Grey list multicast service processing.
Conversely, non inclusion of the MRepCtl-CAC TLV in Provisioning Conversely, non inclusion of the MRepCtl-CAC TLV in Provisioning
messages to the AN enables admission control by the NAS for flows messages to the AN enables admission control by the NAS for flows
added by Multicast Replication Control messages, regardless of added by Multicast Replication Control messages, regardless of
whether they are part of NAS- initiated replication or Grey list whether they are part of NAS- initiated replication or Grey list
multicast service processing. Admission Control for white flows can multicast service processing. Admission Control for white flows can
also be enabled independently on the AN by inclusion by the NAS of also be enabled independently on the AN by inclusion by the NAS of
the White-List-CAC TLV in the Provisioning message. the White-List-CAC TLV in the Provisioning message.
6.3.4. Combinations of Committed Bandwidth Reporting with Other
Multicast Capabilities
Committed bandwidth reporting can take independently of which other
multicast capabilities have been negotiated. However, some
combinations do not make sense because of redundancy. In particular,
the NAS obtains the same information that committed bandwidth
reporting gives if the only other capabilities operating are NAS-
initiated replication and/or conditional access with Grey lists.
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.] [Probably need to say more, but will do so later.]
8. IANA Considerations 8. IANA Considerations
RFC EDITOR'S NOTE: Please replace XXXX with the RFC number of this
document.
This document defines the following additional values within the This document defines the following additional values within the
GSMPv3 Message Type Name Space registry, under the new heading GSMPv3 Message Type Name Space registry, under the new heading
"Multicast Extensions To ANCP/GSMPv3": "Multicast Extensions To ANCP/GSMPv3":
+---------------------------+---------------+--------+--------------+ +-----------------------------+----------------+--------+-----------+
| Message Name | Message | Status | Reference | | Message Name | Message Number | Status | Reference |
| | Number | | | +-----------------------------+----------------+--------+-----------+
+---------------------------+---------------+--------+--------------+ | Multicast Replication | 144 | | RFC XXXX |
| Multicast Replication | 144 | | This | | Control | | | |
| Control | | | document | | | | | |
| | | | | | Multicast Admission Control | 145 | | RFC XXXX |
| Multicast Admission | 145 | | This | | | | | |
| Control | | | document | | Bandwidth Reallocation | 146 | | RFC XXXX |
| | | | | | Request | | | |
| Bandwidth Reallocation | 146 | | This | | | | | |
| Request | | | document | | Bandwidth Transfer | 147 | | RFC XXXX |
| | | | | | | | | |
| Bandwidth Transfer | 147 | | This | | Delegated Bandwidth Query | 148 | | RFC XXXX |
| | | | document | | | | | |
| | | | | | Multicast Flow Query | 149 | | RFC XXXX |
| Delegated Bandwidth Query | 148 | | This | | | | | |
| | | | document | | Committed Bandwidth Report | 150 | | RFC XXXX |
| | | | | +-----------------------------+----------------+--------+-----------+
| Multicast Flow Query | 149 | | This |
| | | | document |
+---------------------------+---------------+--------+--------------+
This document defines the following additional values for the GSMPv3 This document defines the following additional values for the GSMPv3
Failure Response Message Name Space registry: Failure Response Message Name Space registry:
+-------+--------------------------------------------+--------------+ +-------+-----------------------------------------------+-----------+
| Value | Failure Response Message Name | Reference | | Value | Failure Response Message Name | Reference |
+-------+--------------------------------------------+--------------+ +-------+-----------------------------------------------+-----------+
| 100 | Command error. | This | | 100 | Command error. | RFC XXXX |
| | | document | | | | |
| | | | | 101 | Bad flow address. | RFC XXXX |
| 101 | Bad flow address. | This | | | | |
| | | document | | 102 | Multicast flow does not exist. | RFC XXXX |
| | | | | | | |
| 102 | Multicast flow does not exist. | This | | 103 | Invalid preferred bandwidth amount. | RFC XXXX |
| | | document | | | | |
| | | | | 104 | Inconsistent views of delegated bandwidth | RFC XXXX |
| 103 | Invalid preferred bandwidth amount. | This | | | amount. | |
| | | document | | | | |
| | | | | 105 | Bandwidth request conflict. | RFC XXXX |
| 104 | Inconsistent views of delegated bandwidth | This | +-------+-----------------------------------------------+-----------+
| | amount. | document |
| | | |
| 105 | Bandwidth request conflict. | 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 | RFC XXXX |
| | | | | | | |
| Bandwidth-Allocation | 0x15 | This document | | Bandwidth-Allocation | 0x15 | RFC XXXX |
| | | | | | | |
| Bandwidth-Request | 0x16 | This document | | Bandwidth-Request | 0x16 | RFC XXXX |
| | | | | | | |
| Multicast-Service-Profile-Name | 0x18 | This document | | Multicast-Service-Profile-Name | 0x18 | RFC XXXX |
| | | | | | | |
| Multicast-Flow | 0x19 | This document | | Multicast-Flow | 0x19 | RFC XXXX |
| | | | | | | |
| List-Action | 0x21 | This document | | List-Action | 0x21 | RFC XXXX |
| | | | | | | |
| Sequence-Number | 0x22 | This document | | Sequence-Number | 0x22 | RFC XXXX |
| | | | | | | |
| White-List-CAC | 0x24 | This document | | White-List-CAC | 0x24 | RFC XXXX |
| | | | | | | |
| MRepCtl-CAC | 0x25 | This document | | MRepCtl-CAC | 0x25 | RFC XXXX |
| | | | | | | |
| Request-Source-IP | 0x92 | This document | | Request-Source-IP | 0x92 | RFC XXXX |
| | | | | | | |
| Request-Source-MAC | 0x93 | This document | | Request-Source-MAC | 0x93 | RFC XXXX |
+--------------------------------+-----------+---------------+ | | | |
| Report-Buffering-Time | 0x94 | RFC XXXX |
| | | |
| Committed-Bandwidth | 0x95 | RFC XXXX |
+--------------------------------+-----------+-----------+
This document defines the following additional values for the ANCP This document defines the following additional values for the ANCP
Command Code 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 | RFC XXXX |
| | | document | | | | |
| | | | | Delete | 0x02 | RFC XXXX |
| Delete | 0x02 | This | | | | |
| | | document | | Delete All | 0x03 | RFC XXXX |
| | | | | | | |
| Delete All | 0x03 | This | | Admission Control Reject | 0x04 | RFC XXXX |
| | | document | | | | |
| | | | | Conditional Access Reject | 0x05 | RFC XXXX |
| Admission Control Reject | 0x04 | This | | | | |
| | | document | | Admission Control and Conditional | 0x06 | RFC XXXX |
| | | | | Access Reject | | |
| Conditional Access Reject | 0x05 | This | +--------------------------------------+----------------+-----------+
| | | document |
| | | |
| Admission Control and Conditional | 0x06 | This |
| Access Reject | | document |
+-------------------------------------+----------------+------------+
This document defines the following additional values for the ANCP This document defines the following additional values for the ANCP
Capability registry: Capability registry:
+-----------------------------------+------------------+------------+ +------------------------------------+------------------+-----------+
| Capability Type Name | Capability Type | Reference | | Capability Type Name | Capability Type | Reference |
| | Code | | | | Code | |
+-----------------------------------+------------------+------------+ +------------------------------------+------------------+-----------+
| NAS-initiated replication | 0x5 | This | | NAS-initiated replication | 0x3 | RFC XXXX |
| | | document | | | | |
| | | | | Committed bandwidth reporting | 0x5 | RFC XXXX |
| Conditional access with white and | 0x6 | This | | | | |
| black lists | | document | | Conditional access with white and | 0x6 | RFC XXXX |
| | | | | black lists | | |
| Conditional access with grey | 0x7 | This | | | | |
| lists | | document | | Conditional access with grey lists | 0x7 | RFC XXXX |
| | | | | | | |
| Bandwidth delegation | 0x8 | This | | Bandwidth delegation | 0x8 | RFC XXXX |
| | | 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. Kristian Poscic provided the committed
bandwidth reporting use case.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ancp-framework]
Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks",
draft-ietf-ancp-framework-13 (work in progress),
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., Haag, T., Voigt, N., and T.
N., and R. Maglione, "Protocol for Access Node Control Taylor, "Protocol for Access Node Control Mechanism in
Mechanism in Broadband Networks", Broadband Networks", draft-ietf-ancp-protocol-10 (work in
draft-ietf-ancp-protocol-09 (work in progress), progress), July 2010.
February 2010.
[IEEE48] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ [IEEE48] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/
EUI48.html", 2010. EUI48.html", 2010.
[IEEE64] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/ [IEEE64] IEEE, "http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html", 2010. EUI64.html", 2010.
[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.
skipping to change at page 65, line 12 skipping to change at page 71, line 5
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.
[PIMreg] IANA, "http://www.iana.org/assignments/pim-parameters/ [PIMreg] IANA, "http://www.iana.org/assignments/pim-parameters/pim-
pim-parameters.xhtml", 2005. 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.
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format", Independent Multicast (PIM) Join Attribute Format",
RFC 5384, November 2008. RFC 5384, November 2008.
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks",
RFC 5851, May 2010.
Appendix A. Example of Messages and Message Flows Appendix A. Example of Messages and Message Flows
This appendix provides an example in which most of the possible This appendix provides an example in which most of the possible
message flows for multicast control are illustrated. This appendix message flows for multicast control are illustrated. This appendix
is for informational purposes only. In case of discrepancy with text is for informational purposes only. In case of discrepancy with text
of the body of this document, the text in the body of the document is of the body of this document, the text in the body of the document is
to be considered as the normative text. to be considered as the normative text.
Assume the following, for a given access port: Assume the following, for a given access port:
skipping to change at page 66, line 28 skipping to change at page 72, line 28
o Some premium services are available, but requests for these o Some premium services are available, but requests for these
services must be referred to the policy server for proper credit services must be referred to the policy server for proper credit
processing. For this reason they are grey-listed. The NAS will processing. For this reason they are grey-listed. The NAS will
be responsible for admission control for these services. be responsible for admission control for these services.
o The subscriber has asked that certain services be blocked so that o The subscriber has asked that certain services be blocked so that
his children cannot view them. These services are black-listed. his children cannot view them. These services are black-listed.
o All of the above services are Source-Specific Multicast (SSM). In o All of the above services are Source-Specific Multicast (SSM). In
addition, by means which bypass the AN, the subscriber can signal addition, by means which bypass the AN, the subscriber can signal
intent to join an on-line game service which is Any-Source intent to join an on- line game service which is Any-Source
Multicast (ASM). The NAS is responsible for admission control for Multicast (ASM). The NAS is responsible for admission control for
this service. this service.
o Bandwidth delegation is in effect to share video bandwidth between o Bandwidth delegation is in effect to share video bandwidth between
the AN and the NAS. the AN and the NAS.
The stated conditions require the use of all four of the capabilities The stated conditions require the use of four of the five
specified in this memo. capabilities specified in this memo.
A.1. Provisioning Phase A.1. Provisioning Phase
Assume that capability negotiation has been completed between the AN Assume that capability negotiation has been completed between the AN
and NAS and that the set of negotiated capabilities includes the and NAS and that the set of negotiated capabilities includes the
following four multicast capabilities: NAS-initiated replication, following four multicast capabilities: NAS-initiated replication,
conditional access with white and black list, conditional access with conditional access with white and black list, conditional access with
grey list, and bandwidth delegation. At this point, the NAS can grey list, and bandwidth delegation. At this point, the NAS can
provision the service profiles on the AN and enable admission control provision the service profiles on the AN and enable admission control
at the AN for white-listed flows. To do this, the NAS sends the AN a at the AN for white-listed flows. To do this, the NAS sends the AN a
Provisioning message containing this information. An example message Provisioning message containing this information. An example message
providing the profile for our assumed subscriber is shown in providing the profile for our assumed subscriber is shown in
Figure 17. The message has the following contents: Figure 20. The message has the following contents:
o Message type is 93. o Message type is 93.
o The Result and Code fields in the header are set to zeroes, as o The Result and Code fields in the header are set to zeroes, as
specified in the ANCP base protocol document. specified in the ANCP base protocol document.
o A Transaction identifier is assigned by the NAS. o A Transaction identifier is assigned by the NAS.
o The Multicast-Service-Profile TLV (of which typically there would o The Multicast-Service-Profile TLV (of which typically there would
be multiple instances) contains a Multicast-Service-Profile-Name be multiple instances) contains a Multicast-Service-Profile-Name
skipping to change at page 69, line 6 skipping to change at page 75, line 6
TLV lengths are given in decimal for easier understanding. Note that TLV lengths are given in decimal for easier understanding. Note that
the padding after the middle List-Action TLV is counted as part of 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 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 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 in the message header, unlike those in the TLVs, includes the message
header itself, as required by [RFC3292]. Finally, note that the header itself, as required by [RFC3292]. Finally, note that the
Provisioning message does not include a MRepCtl-CAC TLV since in our Provisioning message does not include a MRepCtl-CAC TLV since in our
example admission control for Grey listed flows and for NAS-initiated example admission control for Grey listed flows and for NAS-initiated
replication is performed by the NAS. replication is performed by the NAS.
Figure 17: Example Provisioning Message Figure 20: 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 Management message that, together with the other with an ANCP Port Management message that, together with the other
parameters, includes the multicast service profile name to be parameters, includes the multicast service profile name to be
associated to that port along with the initial amount of delegated associated to that port along with the initial amount of delegated
bandwidth. The corresponding message flow is illustrated in bandwidth. The corresponding message flow is illustrated in
Figure 18. Figure 21.
+----------+ +---------+ +-----+ +-----+ +----------+ +---------+ +---
--+ +-----+
|Subscriber| | Home | | AN | | NAS | |Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+ +----------+ | Gateway | +-----+ +-----+
| +---------+ | | | +---------+ | |
| | | | | | | |
| | | | | | | |
| | DSL Synch. | | | | DSL Synch. | |
| |--------------------->| | | |--------------------->| |
| | |(M1)PORT_UP(Port ID) | | | |(M1)PORT_UP(Port ID) |
| | |-------------------->| | | |-------------------->|
| | | (*) | | | (*)
| | |(M2) PORT_MNGT | | | |(M2) PORT_MNGT |
| | | (Port ID, | | | | (Port ID, |
| | |Mcast S Profile Name,| | | |Mcast S Profile Name,|
| | |Bandwidth Allocation)| | | |Bandwidth Allocation)|
| | |<--------------------| | | |<--------------------|
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Autorization/Policy Server Autorization/Policy Server
Figure 18: Configuring an AN Port With Multicast Service Profile ID Figure 21: Configuring an AN Port With Multicast Service Profile ID
and Delegated Bandwidth amount and Delegated Bandwidth amount
The Port Management message will typically contain other TLVs but our The Port Management message will typically contain other TLVs but our
example (Figure 19) just shows the Target, Multicast-Service-Profile- example (Figure 22) just shows the Target, Multicast- Service-
Name, and Bandwidth-Allocation TLVs. The Target TLV identifies the Profile-Name, and Bandwidth-Allocation TLVs. The Target TLV
subscriber line, the Multicast-Service-Profile-Name TLV is identical identifies the subscriber line, the Multicast-Service-Profile-Name
to the one contained in the Provisioning message, and the Bandwidth- TLV is identical to the one contained in the Provisioning message,
Allocation TLV provides just enough bandwidth (2000 kbits/s) for one and the Bandwidth-Allocation TLV provides just enough bandwidth (2000
channel to start with. kbits/s) for one channel to start with.
The following fields in the Port Management message header are shown The following fields in the Port Management message header are shown
with specific values either as directed by the base protocol document with specific values either as directed by the base protocol document
or for the sake of our example: or for the sake of our example:
o Message Type is 32. o Message Type is 32.
o Result is set to Nack (0x01) for this example. o Result is set to Nack (0x01) for this example.
o Code is 0x000. o Code is 0x000.
skipping to change at page 71, line 47 skipping to change at page 77, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile name | | Multicast service profile name |
~ = "Cust 0127-53681-0003" ~ ~ = "Cust 0127-53681-0003" ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BW Alloc TLV Type = 0x15 | TLV Length = 4 | | BW Alloc TLV Type = 0x15 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth value = 0x000007D0 (2000 kbits/s) | | Bandwidth value = 0x000007D0 (2000 kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Example Port Management Message Figure 22: Example Port Management Message
A.2. Handling a Grey-Listed Flow A.2. Handling a Grey-Listed Flow
Suppose now that the subscriber chooses to watch the premium channel Suppose now that the subscriber chooses to watch the premium channel
characterized by source 192.0.2.21, group 233.252.0.67. Upon characterized by source 192.0.2.21, group 233.252.0.67. Upon
receiving the Join request, the AN matches it against the multicast receiving the Join request, the AN matches it against the multicast
service profile for the port and determines that it is a Grey-listed service profile for the port and determines that it is a Grey-listed
flow. Figure 20 illustrates the resulting ANCP message flow for the flow. Figure 23 illustrates the resulting ANCP message flow for the
case of a simple join and leave, when admission control for Grey- case of a simple join and leave, when admission control for Grey-
listed flows is not activated on the AN. To start the flow, the AN 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 sends a Multicast Admission Control request (M1) to the NAS. The NAS
decides whether flow can be admitted, applying both policy and decides whether flow can be admitted, applying both policy and
bandwidth criteria. It returns its decision (positive in this bandwidth criteria. It returns its decision (positive in this
example) in a Multicast Replication Control message (M2). Later, example) in a Multicast Replication Control message (M2). Later,
when the subscriber leaves the flow, the AN informs the NAS by when the subscriber leaves the flow, the AN informs the NAS by
sending another Multicast Admission Control message. sending another Multicast Admission Control message.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
skipping to change at page 72, line 48 skipping to change at page 78, line 48
| Leave(Grey-Fl) | Admission | | Leave(Grey-Fl) | Admission |
|-----------+---------->| Control (M3) | |-----------+---------->| Control (M3) |
| | |------------------>| | | |------------------>|
| | | | | | | |
Grey-Fl : Multicast Flow matching an entry in Grey List Grey-Fl : Multicast Flow matching an entry in Grey List
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Authorization/Policy Server Authorization/Policy Server
Figure 20: Successful Join/Leave Operations, Grey-Listed Flow Figure 23: 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 = 145 - Multicast Admission Control; * Message-Type = 145 - Multicast Admission Control;
* Result= 0x0 (Ignore); * Result= 0x0 (Ignore);
* Transaction-ID = Transaction-ID maintained by AN; * Transaction-ID = Transaction-ID maintained by AN;
skipping to change at page 75, line 51 skipping to change at page 81, line 51
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 | | Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 | | Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Multicast Replication Control Message Admitting A Flow Figure 24: Multicast Replication Control Message Admitting A Flow
The Multicast Admission Control message M3 advising the NAS that the The Multicast Admission Control message M3 advising the NAS that the
flow has been terminated contains: flow has been terminated contains:
o an ANCP Header with: o an ANCP Header with:
* Message-Type = 145 - Multicast Admission Control * Message-Type = 145 - Multicast Admission Control
* Result= 0x0 (Ignore) * Result= 0x0 (Ignore)
skipping to change at page 78, line 25 skipping to change at page 84, line 25
Bandwidth Transfer message back to the NAS bringing the delegated Bandwidth Transfer message back to the NAS bringing the delegated
bandwidth amount back down to 2000 kbits/s when one of the flows is bandwidth amount back down to 2000 kbits/s when one of the flows is
terminated, but this shows nothing new and is omitted. terminated, but this shows nothing new and is omitted.
As one more point of illustration, suppose that the NAS chooses to As one more point of illustration, suppose that the NAS chooses to
audit the current amount of delegated bandwidth to ensure it is audit the current amount of delegated bandwidth to ensure it is
synchronized with the AN. It sends a Delegated Bandwidth Query synchronized with the AN. It sends a Delegated Bandwidth Query
request message to the AN, and receives a Delegated Bandwidth Query request message to the AN, and receives a Delegated Bandwidth Query
response message with the current allocation as the AN sees it. response message with the current allocation as the AN sees it.
The complete message flow is shown in Figure 22. The complete message flow is shown in Figure 25.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS | |Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | | | | | |
| Join(White-F1) | | | Join(White-F1) | |
|-----------+---------->| | |-----------+---------->| |
| | |AN performs | | | |AN performs |
| Mcast White Flow 1 | admission control | | Mcast White Flow 1 | admission control |
skipping to change at page 79, line 43 skipping to change at page 85, line 43
| | |<------------------|(M3) | | |<------------------|(M3)
| | | | | | | |
| | |Delegated Bandwidth| | | |Delegated Bandwidth|
| | | Query response | | | | Query response |
| | |------------------>|(M4) | | |------------------>|(M4)
| | | | | | | |
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Authorization/Policy Server Authorization/Policy Server
Figure 22: Successful Join/Leave Operations, Grey-Listed Flow Figure 25: Successful Join/Leave Operations, Grey-Listed Flow
The Bandwidth Reallocation Request message (M1) is shown in The Bandwidth Reallocation Request message (M1) is shown in
Figure 23. The contents require little explanation. The Message Figure 26. The contents require little explanation. The Message
Type for the Bandwidth Reallocation Request is 146. The Result field Type for the Bandwidth Reallocation Request is 146. The Result field
is set to 0x0 (Ignore). Besides the Target, the message has one is set to 0x0 (Ignore). Besides the Target, the message has one
other TLV, the Bandwidth-Request, with a TLV Type of 0x16. The TLV other TLV, the Bandwidth- Request, with a TLV Type of 0x16. The TLV
contains Required Amount and Preferred Amount fields, set to 4000 and contains Required Amount and Preferred Amount fields, set to 4000 and
6000 kbits/s respectively. 6000 kbits/s respectively.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length = 36 | | Type (0x88-0C) | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type=146 | 0x0 | Code = 0x000 | | Vers | Sub | Msg Type=146 | 0x0 | Code = 0x000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 80, line 29 skipping to change at page 86, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID | | Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Bandwidth-Req TLV Type = 0x16 | TLV Length = 8 | |Bandwidth-Req TLV Type = 0x16 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Amount = 0x00000FA0 (4000 kbits/s) | | Required Amount = 0x00000FA0 (4000 kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Amount = 0x00001770 (6000 kbits/s) | | Preferred Amount = 0x00001770 (6000 kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Bandwidth Reallocation Request Message Figure 26: Bandwidth Reallocation Request Message
The Bandwidth Transfer message (M2) is shown in Figure 24. Again, The Bandwidth Transfer message (M2) is shown in Figure 27. Again,
the contents are easily understood. The Message Type for the the contents are easily understood. The Message Type for the
Bandwidth Transfer message is 147. The Result field is set to Bandwidth Transfer message is 147. The Result field is set to
Success (0x3). The message contains the Target TLV and the Success (0x3). The message contains the Target TLV and the
Bandwidth-Allocation TLV. The latter has a TLV Type of 0x15 and Bandwidth- Allocation TLV. The latter has a TLV Type of 0x15 and
contains a Delegated Amount field, set to 4000 kbits/s. contains a Delegated Amount field, set to 4000 kbits/s.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length = 32 | | Type (0x88-0C) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type=147 | 0x3 | Code = 0x000 | | Vers | Sub | Msg Type=147 | 0x3 | Code = 0x000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
skipping to change at page 81, line 27 skipping to change at page 87, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID | | Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|BW-Allocation TLV Type = 0x15 | TLV Length = 4 | |BW-Allocation TLV Type = 0x15 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Amount = 0x00000FA0 (4000 kbits/s) | | Delegated Amount = 0x00000FA0 (4000 kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: NAS Response, Bandwidth Transfer Message Figure 27: NAS Response, Bandwidth Transfer Message
The Delegated Bandwidth Query request message (M3) is shown in The Delegated Bandwidth Query request message (M3) is shown in
Figure 25. The Message Type for the Delegated Bandwidth Query Figure 28. The Message Type for the Delegated Bandwidth Query
request message is 148. The Result field is set to AckAll (0x2). request message is 148. The Result field is set to AckAll (0x2).
The message contains the Target TLV only. The message contains the Target TLV only.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length = 24 | | Type (0x88-0C) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type=148 | 0x2 | Code = 0x000 | | Vers | Sub | Msg Type=148 | 0x2 | Code = 0x000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 81, line 52 skipping to change at page 87, line 52
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 24 | |I| SubMessage Number | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length = 8 | | Type = 0x1000 (Target) | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID | | Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Delegated Bandwidth Query Request Message Figure 28: Delegated Bandwidth Query Request Message
Finally, the Delegated Bandwidth Query response message (M4) is shown Finally, the Delegated Bandwidth Query response message (M4) is shown
in Figure 26. The Message Type for the Delegated Bandwidth Query in Figure 29. The Message Type for the Delegated Bandwidth Query
response message is 148. The Result field is set to Success (0x3). response message is 148. The Result field is set to Success (0x3).
The message contains the Target TLV and the Bandwidth-Allocation TLV The message contains the Target TLV and the Bandwidth-Allocation TLV
with the Delegated Amount field set to 4000 kbits/s. with the Delegated Amount field set to 4000 kbits/s.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length = 32 | | Type (0x88-0C) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type=148 | 0x3 | Code = 0x000 | | Vers | Sub | Msg Type=148 | 0x3 | Code = 0x000 |
skipping to change at page 82, line 33 skipping to change at page 88, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 | | Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID | | Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|BW-Allocation TLV Type = 0x15 | TLV Length = 4 | |BW-Allocation TLV Type = 0x15 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Amount = 0x00000FA0 (4000 kbits/s) | | Delegated Amount = 0x00000FA0 (4000 kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Delegated Bandwidth Query Response Message Figure 29: Delegated Bandwidth Query Response Message
A.4. Handling Of Black-Listed Join Requests A.4. Handling Of Black-Listed Join Requests
This section introduces no new messages, since requests for flows in This section introduces no new messages, since requests for flows in
the Black list are simply ignored. The one thing to point out is the the Black list are simply ignored. The one thing to point out is the
overlap in our example between the set of flows in the Grey list and overlap in our example between the set of flows in the Grey list and
the flows in the Black list. This does not create any ambiguity, the flows in the Black list. This does not create any ambiguity,
since not only does the Black list have priority for equally good since not only does the Black list have priority for equally good
matches, but also the Black list entries are more specific (group matches, but also the Black list entries are more specific (group
prefix lengths of 32 versus 29 in the Grey list) than the Grey list prefix lengths of 32 versus 29 in the Grey list) than the Grey list
skipping to change at page 83, line 12 skipping to change at page 89, line 12
(ASM). Subscriber signalling bypasses the AN, going directly to the (ASM). Subscriber signalling bypasses the AN, going directly to the
NAS (e.g., through a web interface). NAS (e.g., through a web interface).
When the subscriber requests to join the game, the NAS (after When the subscriber requests to join the game, the NAS (after
applying policy and bandwidth checks) sends a Multicast Replication applying policy and bandwidth checks) sends a Multicast Replication
Control message to the AN to enable the flow on the port concerned. Control message to the AN to enable the flow on the port concerned.
The AN knows not to apply admission control, since it has not The AN knows not to apply admission control, since it has not
received an MRepCtl-CAC TLV in the Provisioning message. When the received an MRepCtl-CAC TLV in the Provisioning message. When the
subscriber leaves, the NAS sends another Multicast Replication subscriber leaves, the NAS sends another Multicast Replication
Control message to delete the flow. This message sequence is shown Control message to delete the flow. This message sequence is shown
in Figure 27. in Figure 30.
It is possible that the NAS finds that there is not enough bandwidth It is possible that the NAS finds that there is not enough bandwidth
available to accommodate the subscriber's request. In this case, the available to accommodate the subscriber's request. In this case, the
NAS could send a Bandwidth Reallocation Request message to the AN, NAS could send a Bandwidth Reallocation Request message to the AN,
asking it to release some of the bandwidth delegated to it. This is asking it to release some of the bandwidth delegated to it. This is
not shown in the present example, since the messages are the same as not shown in the present example, since the messages are the same as
those already presented with the exception that the Preferred Amount those already presented with the exception that the Preferred Amount
in the request will be *less than* or equal to the Required amount, in the request will be *less than* or equal to the Required amount,
rather than *greater than* or equal to it. rather than *greater than* or equal to it.
skipping to change at page 83, line 50 skipping to change at page 89, line 50
| | | Multicast | | | | Multicast |
| | | Replication | | | | Replication |
| | | Control (M2) | | | | Control (M2) |
| Mcast Game Flow |<------------------| | Mcast Game Flow |<------------------|
| discontinued | | | discontinued | |
| | | | | | | |
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Authorization/Policy Server Authorization/Policy Server
Figure 27: NAS-Initiated Flows For On-Line Gaming Figure 30: NAS-Initiated Flows For On-Line Gaming
Multicast Replication Control message (M1) in Figure 28 looks like Multicast Replication Control message (M1) in Figure 31 looks like
the message in Figure 21 with two exceptions. The first is that the the message in Figure 24 with two exceptions. The first is that the
NAS has the option to set the Result field to AckAll (0x02) if it NAS has the option to set the Result field to AckAll (0x02) if it
needs positive reassurance that the flow has been enabled. This was needs positive reassurance that the flow has been enabled. This was
not done here to save having to depict a response differing only in not done here to save having to depict a response differing only in
the Result field. The larger difference in this example is that the the Result field. The larger difference in this example is that the
flow description in the Multicast-Flow embedded TLV is that of an ASM flow description in the Multicast-Flow embedded TLV is that of an ASM
multicast group (Flow Type = 0x01) with IPv4 (0x01) group address multicast group (Flow Type = 0x01) with IPv4 (0x01) group address
233.252.1.100. 233.252.1.100.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 84, line 41 skipping to change at page 90, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 | Acctg = 0x01 | Reserved = 0x0000 | | Cmd Code=0x01 | Acctg = 0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 8 | |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Type=0x01 |Addr Fam =0x01 | Reserved = 0x0000 | |Flow Type=0x01 |Addr Fam =0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.1.100 | | Multicast Group Address = 233.252.1.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
Figure 28: Enabling The Subscriber To Join An On-Line Game Figure 31: Enabling The Subscriber To Join An On- Line Game
Message M2 terminating the flow when the subscriber leaves the game Message M2 terminating the flow when the subscriber leaves the game
looks the same as the message in Figure 28 with two exceptions: the looks the same as the message in Figure 31 with two exceptions: the
Command Code becomes Delete (0x02), and Accounting is set to 0 to Command Code becomes Delete (0x02), and Accounting is set to 0 to
turn off flow accounting. Of course, the Transaction Identifier turn off flow accounting. Of course, the Transaction Identifier
values will differ between the two messages. values will differ between the two messages.
A.6. Example Flow For Multicast Flow Reporting A.6. Example Flow For Multicast Flow Reporting
The example in this section is independent of the example in the The example in this section is independent of the example in the
preceding sections. preceding sections.
Figure 29 illustrates a message flow in a case where the NAS queries Figure 32 illustrates a message flow in a case where the NAS queries
the AN about which multicast flows are 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 29: Per Port Multicast Flow Reporting Figure 32: 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 30. The Message Type is 149. The Result field is set to Figure 33. The Message Type is 149. The Result field is set to
AckAll (0x2). Three Target TLVs are present, identifying port 10, AckAll (0x2). Three Target TLVs are present, identifying port 10,
port 20, and port 11 respectively. port 20, and port 11 respectively.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length | | Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type = 149|Rslt=2 | Code = 0 | | Vers | Sub | Msg Type = 149|Rslt=2 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 86, line 41 skipping to change at page 92, 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 30: Multicast Flow Query Request Message For Per-Port Figure 33: Multicast Flow Query Request Message For Per-Port
Multicast Flow Reporting Multicast Flow Reporting
The Multicast Flow Query Response message (M2) is illustrated in The Multicast Flow Query Response message (M2) is illustrated in
Figure 31. It indicates that there is one active multicast flow Figure 34. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length | | Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 88, line 14 skipping to change at page 94, line 14
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 | |Multicast-Flow TLV Type = 0x19 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 | |Flow Type=0x02 |Addr Fam =0x01 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address: 233.252.2.10 | | Multicast Group Address: 233.252.2.10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.2 | | Unicast Source Address = 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
Figure 31: Multicast Flow Query Response message for per-port Figure 34: 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
skipping to change at page 89, line 27 skipping to change at page 95, line 27
Telecom Italia Telecom Italia
Via Reiss Romoli 274 Via Reiss Romoli 274
Torino 10148 Torino 10148
Italy Italy
Phone: Phone:
Email: roberta.maglione@telecomitalia.it Email: roberta.maglione@telecomitalia.it
Tom Taylor Tom Taylor
Huawei Technologies Huawei Technologies
1852 Lorraine Ave Ottawa
Ottawa, Ontario K1H 6Z8
Canada Canada
Phone: +1 613 680 2675
Email: tom111.taylor@bell.net Email: tom111.taylor@bell.net
 End of changes. 162 change blocks. 
441 lines changed or deleted 692 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/