draft-ietf-ancp-mc-extensions-00.txt   draft-ietf-ancp-mc-extensions-01.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: January 4, 2010 Telecom Italia Expires: April 29, 2010 Telecom Italia
T. Taylor T. Taylor
Huawei Huawei
July 3, 2009 October 26, 2009
Additional Multicast Control Extensions for ANCP Additional Multicast Control Extensions for ANCP
draft-ietf-ancp-mc-extensions-00.txt draft-ietf-ancp-mc-extensions-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 45 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 4, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
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. the Access Node Control Protocol framework document. Those use cases
are organized into the following ANCP capabilities:
o NAS-initiated multicast replication;
o conditional access with white and black lists;
o conditional access with grey lists;
o bandwidth delegation.
These capabilities may be combined according to the rules given in
this specification.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 7 3. Multicast Use Cases . . . . . . . . . . . . . . . . . . . . . 10
3.1. NAS Initiated Multicast Replication Control Use Case . . . 7 3.1. NAS Initiated Multicast Replication Control Use Case . . . 10
3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11
3.2. Conditional Access and Admission Control Use Case . . . . 8 3.2. Conditional Access and Admission Control Use Case . . . . 11
3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 12
3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 9 3.3. Multicast Flow Reporting Use Case . . . . . . . . . . . . 13
3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 10 3.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 13
4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 11 4. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 11 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 14
4.2. Port Management Message . . . . . . . . . . . . . . . . . 11 4.1.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 14
4.3. Multicast Replication Control Message . . . . . . . . . . 12 4.1.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 15
4.4. Multicast Status Message . . . . . . . . . . . . . . . . . 17 4.2. Port Management Message . . . . . . . . . . . . . . . . . 16
4.5. Multicast Admission Control Message . . . . . . . . . . . 20 4.2.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 16
4.6. Bandwidth Reallocation Request Message . . . . . . . . . . 23 4.2.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 17
4.7. Bandwidth Transfer Message . . . . . . . . . . . . . . . . 25 4.3. Multicast Replication Control Message . . . . . . . . . . 17
4.8. Delegated Bandwidth Query Request and Response Messages . 26 4.3.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 21
4.9. Multicast Flow Query Request and Response Messages . . . . 28 4.3.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 22
4.10. Delegated Bandwidth Reset Procedure . . . . . . . . . . . 30 4.4. Multicast Admission Control Message . . . . . . . . . . . 24
5. ANCP TLVs and Sub-TLVs . . . . . . . . . . . . . . . . . . . . 32 4.4.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 25
5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 32 4.4.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 26
5.1.1. Profile Processing At the Access Node . . . . . . . . 34 4.5. Bandwidth Reallocation Request Message . . . . . . . . . . 27
5.2. Bandwidth-Delegation-Control TLV . . . . . . . . . . . . . 36 4.5.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 28
5.3. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 37 4.5.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 28
5.4. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 38 4.6. Bandwidth Transfer Message . . . . . . . . . . . . . . . . 30
5.5. Bandwidth-Status TLV . . . . . . . . . . . . . . . . . . . 38 4.6.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 31
5.6. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 39 4.6.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 31
5.7. Request-Source-IP sub-TLV . . . . . . . . . . . . . . . . 39 4.7. Delegated Bandwidth Query Request Message . . . . . . . . 32
5.8. Request-Source-MAC sub-TLV . . . . . . . . . . . . . . . . 40 4.7.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 33
5.9. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 41 4.7.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 33
6. New Capabilities . . . . . . . . . . . . . . . . . . . . . . . 43 4.8. Delegated Bandwidth Query Response Message . . . . . . . . 33
7. Example of Messages and Message Flows . . . . . . . . . . . . 45 4.8.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 34
7.1. Multicast Conditional Access and CAC without AN 4.8.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 34
Bandwidth Delegation . . . . . . . . . . . . . . . . . . . 45 4.9. Multicast Flow Query Request and Response Messages . . . . 35
7.1.1. List/Profile Provisioning . . . . . . . . . . . . . . 45 4.9.1. Sender Behaviour . . . . . . . . . . . . . . . . . . . 35
7.1.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 47 4.9.2. Receiver Behaviour . . . . . . . . . . . . . . . . . . 36
7.1.3. Successful Join/Leave Operations . . . . . . . . . . . 47 5. ANCP TLVs and Sub-TLVs . . . . . . . . . . . . . . . . . . . . 38
7.1.4. Admission Control Reject without NAS Response . . . . 53 5.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 38
7.1.5. Admission Control Reject with NAS Response . . . . . . 55 5.2. Command Number TLV . . . . . . . . . . . . . . . . . . . . 41
7.2. Example Flows For Bandwidth Delegation . . . . . . . . . . 59 5.3. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 41
7.2.1. Activation and Provisioning of Delegated Bandwidth . . 60 5.4. White-List-CAC TLV . . . . . . . . . . . . . . . . . . . . 42
7.2.2. Successful Request For More Delegated Bandwidth . . . 61 5.5. MRepCtl-CAC TLV . . . . . . . . . . . . . . . . . . . . . 42
7.2.3. Failed Autonomous Transfer With Reset . . . . . . . . 63 5.6. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 42
7.3. Example Flows For Multicast Flow Reporting . . . . . . . . 66 5.7. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 43
7.3.1. Per Port Multicast Flow Reporting . . . . . . . . . . 66 5.8. Request-Source-IP sub-TLV . . . . . . . . . . . . . . . . 43
8. Security Considerations . . . . . . . . . . . . . . . . . . . 71 5.9. Request-Source-MAC sub-TLV . . . . . . . . . . . . . . . . 44
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 5.10. Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 45
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76 6. Multicast Capabilities . . . . . . . . . . . . . . . . . . . . 46
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6.1. Required Protocol Support . . . . . . . . . . . . . . . . 46
11.1. Normative References . . . . . . . . . . . . . . . . . . . 77 6.1.1. Protocol Requirements For NAS-initiated Replication . 46
11.2. Informative References . . . . . . . . . . . . . . . . . . 77 6.1.2. Protocol requirements For Conditional Access With
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 79 White and Black Lists . . . . . . . . . . . . . . . . 47
6.1.3. Protocol requirements For Conditional Access With
Grey Lists . . . . . . . . . . . . . . . . . . . . . . 48
6.1.4. Protocol requirements For Delegated Bandwidth . . . . 49
6.2. Capability-Specific Procedures for Providing Multicast
Service . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.1. Procedures For NAS-initiated Replication . . . . . . . 50
6.2.2. Procedures For Conditional Access With Black and
White Lists . . . . . . . . . . . . . . . . . . . . . 51
6.2.3. Procedures For Conditional Access With Grey Lists . . 52
6.2.4. Procedures For Delegated Bandwidth . . . . . . . . . . 53
6.3. Combinations of Multicast Capabilities . . . . . . . . . . 54
6.3.1. Combination of NAS-Initiated Replication with
Other Capabilities . . . . . . . . . . . . . . . . . . 54
6.3.2. Conditional Access With White, Black, and Grey
Lists . . . . . . . . . . . . . . . . . . . . . . . . 55
6.3.3. Conditional Access Combined With Delegated
Bandwidth . . . . . . . . . . . . . . . . . . . . . . 56
7. Security Considerations . . . . . . . . . . . . . . . . . . . 57
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
10.1. Normative References . . . . . . . . . . . . . . . . . . . 63
10.2. Informative References . . . . . . . . . . . . . . . . . . 63
Appendix A. Example of Messages and Message Flows . . . . . . . . 65
A.1. Multicast Conditional Access and CAC without AN
bandwidth delegation . . . . . . . . . . . . . . . . . . . 65
A.1.1. List/Profile Provisioning . . . . . . . . . . . . . . 65
A.1.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 67
A.1.3. Successful Join/Leave Operations . . . . . . . . . . . 67
A.1.4. Admission Control Reject without NAS Response . . . . 73
A.1.5. Admission Control Reject with NAS Response . . . . . . 75
A.2. Example Flows For bandwidth delegation . . . . . . . . . . 79
A.2.1. Activation and Provisioning of total multicast
Bandwidth . . . . . . . . . . . . . . . . . . . . . . 80
A.2.2. Successful Request For More Multicast Bandwidth . . . 81
A.2.3. Failed Autonomous Transfer With Reset . . . . . . . . 83
A.3. Example Flows For Multicast Flow Reporting . . . . . . . . 86
A.3.1. Per Port Multicast Flow Reporting . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91
1. Introduction 1. Introduction
[I-D.ietf-ancp-framework] defines a framework and requirements for an [I-D.ietf-ancp-framework] defines a framework and requirements for an
Access Node control mechanism between a Network Access Server (NAS) Access Node control mechanism between a Network Access Server (NAS)
and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer
(DSLAM)) in a multi-service reference architecture in order to (DSLAM)) in a multi-service reference architecture in order to
perform QoS-related, service-related and subscriber-related perform QoS-related, service-related and subscriber-related
operations. [I-D.ietf-ancp-protocol] specifies a protocol for Access operations. [I-D.ietf-ancp-protocol] specifies a protocol for Access
Node Control in broadband networks in line with this framework. Node Control in broadband networks in line with this framework.
The Access Node Control Protocol (ANCP) specified in The Access Node Control Protocol (ANCP) specified in
[I-D.ietf-ancp-protocol] supports a number of use cases defined in [I-D.ietf-ancp-protocol] supports a number of use cases defined in
[I-D.ietf-ancp-framework] such as the Access Topology Discovery use [I-D.ietf-ancp-framework] such as the Access Topology Discovery use
case, the Access Loop Configuration use case and the 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 [I-D.ietf-ancp-framework]. The
present document specifies the extensions to the Access Node Control present document specifies the extensions to the Access Node Control
Protocol required for support of these multicast use cases. Protocol required for support of these multicast use cases. In terms
of the ANCP protocol, these use cases are organized into four
capabilities:
o NAS-initiated multicast replication;
o conditional access with white and black lists;
o conditional access with grey lists;
o bandwidth delegation.
NAS-initiated multicast replication assumes that multicast "join" and
"leave" requests are terminated on the NAS, or that the NAS receives
requests to establish multicast sessions through other means (e.g.,
application-level signalling). The NAS sends commands to the AN to
start or stop replication of specific multicast flows on specific
subscriber ports. This use case is described briefly in the next-to-
last paragraph of section 3.4 of [I-D.ietf-ancp-framework].
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
applicable to operation with white and black lists only. In case of
"conditional access with white and black lists", multicast join and
leave requests are terminated at the AN and accepted or ignored in
accordance with the direction provided by white and black lists
respectively. The white and black lists are provisioned per port at
startup time and may be modified thereafter. The NAS may enable
admission control of White-listed flows by appropriate provisioning.
If the bandwidth delegation capability has also been negotiated, that
capability provides a means to adjust the multicast bandwidth limits
at the AN.
Conditional access with grey lists is similar to conditional access
with white lists, except that before accepting any request matching a
grey list entry, the AN sends a request to the NAS for permission to
replicate the flow. Again, the NAS can enable admission control of
Grey-listed flows at the AN. It can control the application of
admission control on a per-flow basis.
Bandwidth delegation is described in section 3.4.2.1 of
[I-D.ietf-ancp-framework]. It allows flexible sharing of total video
bandwidth on an access line between the AN and the NAS. One
application of such bandwidth sharing is where the AN does multicast
admission control, while the NAS or Policy Server does unicast
admission control. In that case, bandwidth delegation allows dynamic
sharing of bandwidth between unicast and multicast video traffic on
each access line.
The formal specification of the behaviours associated with each of
these capabilities, singly and in combination, is given in Section 6.
In addition to the multicast service processing behaviour just
sketched, the definition of each capability includes support for the
multicast accounting and reporting services described in section
3.4.3 of [I-D.ietf-ancp-framework]. Because of this common content
and because of other protocol overlaps between the different
capabilities, the protocol descriptions for the multicast extensions
specified in this document are merged into a single non-redundant
narrative. Tables in Section 6 then indicate the specific sub-
sections of the protocol description that have to be implemented to
support each capability.
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".
skipping to change at page 7, line 32 skipping to change at page 10, line 32
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 [I-D.ietf-ancp-framework] describes the use cases for ANCP associated
with such multicast operations, and identifies the associated ANCP with such 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 [I-D.ietf-ancp-framework] for a more exhaustive
description of the ANCP multicast use cases. Detailed example description of the ANCP multicast use cases. Detailed example
message flows can also be found in Section 7. message flows can 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 8, line 9 skipping to change at page 11, line 9
single copy of the multicast stream towards the AN, which in turn single copy of the multicast stream towards the AN, which in turn
performs replication to multiple subscribers as instructed by the NAS performs replication to multiple subscribers as instructed by the NAS
via ANCP. The NAS first performs conditional access and multicast via ANCP. The NAS first performs conditional access and multicast
admission control when processing multicast join requests, and only admission control when processing multicast join requests, and only
creates replication state in the AN if admission succeeds. creates replication state in the AN if admission succeeds.
3.1.2. Message Flow 3.1.2. Message Flow
With the NAS-initiated use case, a Multicast Replication Control With the NAS-initiated use case, a Multicast Replication Control
Message is sent by the NAS to the AN with a directive to either join Message is sent by the NAS to the AN with a directive to either join
or leave one (or more) multicast flow(s). The AN uses a Multicast or leave one (or more) multicast flow(s). The AN uses a Generic
Status Message to convey the outcome of the directive. Figure 1 Response message to convey the outcome of the directive. Figure 1
illustrates such an ANCP message exchange as well as the associated illustrates such an ANCP message exchange as well as the associated
AN behavior. AN behavior.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<-------------------->| NAS | |Subscriber| | Home | | AN |<-------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | Multicast-Replication-Crl | | | | Multicast-Replication-Crl |
| | | (Target,add, Flow 1) | | | | (Target,add, Flow 1) |
| | |<--------------------------| | | |<--------------------------|
| Mcast Flow 1 | | | Mcast Flow 1 | |
|<==========================+ | |<==========================+ |
| | | Multicast-Status | | | | Generic Response |
| | |-------------------------->| | | |-------------------------->|
| | | | | | | |
| | | | | | | |
~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | |
| | | Multicast-Replication-Crl | | | | Multicast-Replication-Crl |
| | | (Target,delete, Flow 1) | | | | (Target,delete, Flow 1) |
| | |<--------------------------| | | |<--------------------------|
| | | | | | | |
| <Stop Replication of X | | <Stop Replication of X |
| Mcast Flow 1> | Multicast-Status | | Mcast Flow 1> | Generic Response |
| | |-------------------------->| | | |-------------------------->|
Figure 1: NAS Initiated Multicast Replication Control Figure 1: NAS Initiated Multicast Replication Control
3.2. Conditional Access and Admission Control Use Case 3.2. Conditional Access and Admission Control Use Case
3.2.1. Goals 3.2.1. Goals
One option for multicast handling is for the access/aggregation nodes One option for multicast handling is for the access/aggregation nodes
to participate in IGMP/MLD processing (e.g. via IGMP/MLD snooping). to participate in IGMP/MLD processing (e.g. via IGMP/MLD snooping).
In this scenario, on detecting a join/leave request from an enduser In this scenario, on detecting a join/leave request from an enduser
for a multicast flow, the AN uses ANCP to request conditional access for a multicast flow (in the grey list), the AN uses ANCP to request
and admission control decision from the NAS. In turn, after conditional access and admission control decision from the NAS. In
conditional access and admission control checks, the NAS uses ANCP to turn, after conditional access and admission control checks, the NAS
instruct the AN to change the replication states accordingly. uses ANCP to instruct the AN to change the replication states
accordingly.
3.2.2. Message Flow 3.2.2. Message Flow
For support of the conditional access and admission control use case, For support of the conditional access and admission control use case,
on detection of an IGMP/MLD Join, the AN sends an Admission Control on detection of an IGMP/MLD Join, the AN sends an Admission Control
message to the NAS to request conditional access and admission message to the NAS to request conditional access and admission
control check. In case of positive outcome, the NAS sends a control check. In case of positive outcome, the NAS sends a
Multicast Replication Control Message to the AN with a directive to Multicast Replication Control Message to the AN with a directive to
replicate the multicast flow to the corresponding user. Similarly on replicate the multicast flow to the corresponding user. Similarly on
detection of an IGMP/MLD leave, an Admission Control message is sent detection of an IGMP/MLD leave, an Admission Control message is sent
by the AN to the NAS to keep the NAS aware of user departure for the by the AN to the NAS to keep the NAS aware of user departure for the
flow. This message flow is illustrated in Figure 2. flow. This message flow is illustrated in Figure 2.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<------------------->| NAS | |Subscriber| | Home | | AN |<------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | | | | | |
| Join(Flow 1) | Admission-Control | | Join(Gr-Flow1) | Admission-Control |
|------------+---------->| (Target,add, Flow 1) | |------------+---------->| (Target,add,Gr-Flow1) |
| | |-------------------------->| | | |-------------------------->|
| | | (*) | | | (*)
| | | Multicast-Replication-Crl | | | | Multicast-Replication-Crl |
| | | (Target,add, Flow 1) | | | | (Target,add,Gr-Flow 1) |
| | |<--------------------------| | | |<--------------------------|
| Mcast Flow 1 | | | Mcast Gr-Flow1 | |
|<=======================+ | |<=======================+ |
| | | | | | | |
~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | |
| Leave(Flow 1) | Admission-Control | | Leave(Gr-Flow1) | Admission-Control |
|------------+---------->| (Target,delete, Flow 1) | |------------+---------->| (Target,delete,Gr-Flow1) |
| | |-------------------------->| | | |-------------------------->|
| <Stop Replication of X | | <Stop Replication of X |
| Mcast Flow 1> | | | Mcast Gr-Flow1> | |
| | | | | | | |
Gr-Flow1: a multicast flow matching the grey list for that port
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Authorization/Policy Server Authorization/Policy Server
Figure 2: Multicast Conditional Access and Admission Control Figure 2: Multicast Conditional Access and Admission Control
3.3. Multicast Flow Reporting Use Case 3.3. Multicast Flow Reporting Use Case
3.3.1. Goals 3.3.1. Goals
The Multicast flow reporting use case allows the NAS to The Multicast flow reporting use case allows the NAS to
skipping to change at page 11, line 13 skipping to change at page 14, line 13
Figure 3: Multicast Flow Reporting Figure 3: Multicast Flow 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
[I-D.ietf-ancp-protocol] defines the Provisioning message that is Section 5.4.3.1 of [I-D.ietf-ancp-protocol] defines the Provisioning
sent by the NAS to the AN to provision information in the AN. message that is sent by the NAS to the AN to provision information in
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, Bandwidth Delegation activation/ multicast service profiles). The ANCP Provisioning message payload
deactivation). MAY contain:
The ANCP Provisioning message payload MAY contain the following TLVs: o one or more instances of the Multicast-Service-Profile TLV. The
Multicast-Service-Profile TLV is defined in the present document
in Section 5.1. Each instance of the Multicast-Service-Profile
TLV contains a Multicast Service Profile name and one or more list
actions. A list action consists of an action (add, delete,
replace), a list type (White, Black, or Grey), and list content
(multicast source and group addresses).
o Multicast-Service-Profile TLV: the Multicast-Service-Profile TLV o an instance of the White-List-CAC TLV. The White-List-CAC TLV is
is defined in the present document in Section 5.1. It MAY appear defined in section TLV_White_AC. If present, this TLV indicates
zero, one or multiple times. Each instance of the Multicast- that the AN is required to do admission control before replicating
Service-Profile TLV contains a (possibly empty) White List, a White-listed flows.
(possibly empty) Grey List, a (possibly empty) Black List and the
Multicast Service Profile name associated with this set of three
lists.
o Bandwidth-Delegation-Control TLV: The Bandwidth-Delegation-Control o an instance of the MRepCtl_CAC TLV. The MRepCtl-CAC TLV is
TLV is defined in the present document in Section 5.2. It MAY defined in section TLV_MRepCtl_AC. If present, this TLV indicates
appear zero times or once. When present it instructs the AN on that the AN may be required to do admission control before
whether Bandwidth Delegation is to be activated or deactivated. replicating flows specified in Multicast Replication Control
messages.
[Editor's Note: A generic mechanism should be defined in ancp-proto See Section 6 for information on which multicast capabilities require
to deal with incorrect/invalid Provisioning message. This should support of these TLVs in the Provisioning message.
include an error code for the AN to indicate that it does not know a
given TLV and does not support the corresponding capability, and an 4.1.1. Sender Behaviour
error code for the AN to indicate that a given TLV and its
corresponding capabilities have been "negotiated out" during the When directed by the Policy Server or by management action, the NAS
Capability negotiation phase. The present document can indicate that sends the Provisioning message to initially provision or to update
(i) the 1st error code can be used when Provisioning message contain the White, Black, and/or Grey multicast channel lists associated with
a multicast related TLV but the AN does not support it and (ii) the a set of named multicast service profiles, or to enable the AN to
2nd error code can be used when Bandwidth-delegation-Control TLV perform admission control for specific classes of flows.
indicates "active" but Bandwidth Delegation is not part of the
negotiated multicast capabilities]. To provision or update a multicast service profile, the NAS MUST
include within the message one or more instances of the Multicast-
Service-Profile TLV specifying the content to be provisioned or
updated. The NAS SHOULD NOT include any list type (White, Black, or
Grey) that is not supported by the set of multicast capabilities
negotiated between the NAS and the AN. The NAS MUST NOT use the
Provisioning message to send instances of the Multicast-Service-
Profile TLV to the AN unless the Multicast-Service-Profile TLV is
supported by the set of multicast capabilities negotiated between the
NAS and the AN.
To require admission control to be performed at the AN on White-
listed flows, the NAS MUST include a copy of the White-List-CAC TLV
in the Provisioning message. The White-List-CAC TLV MUST NOT be
provided unless the negotiated set of capabilities includes
conditional access with White and Black lists.
To require admission control to be performed at the AN on Grey-listed
flows or on NAS-initiated flows, the NAS MUST include a copy of the
MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV
MUST NOT be provided unless the negotiated set of capabilities
includes NAS-initiated replication control or conditional access with
Grey lists.
4.1.2. Receiver Behaviour
The receiving AN provisions/updates the White, Black, and/or Grey
lists associated with the Multicast Service Profile names contained
in the Multicast-Service-Profile TLV instances within the message.
The AN MUST ignore instances of the Multicast-Service-Profile TLV
referring to any list type (White, Black, or Grey) that is not
supported by the set of multicast capabilities negotiated between the
NAS and the AN.
When a new Multicast Service Profile is identified by a Multicast-
Service-Profile TLV, the initial state of all lists associated with
that profile according to the negotiated set of multicast
capabilities is empty until changed by the contents of Multicast-
Service-Profile TLVs.
If the White-List-CAC and/or MRepCtl-CAC TLV is present in the
Provisioning message and the respective associated capabilities have
been negotiated, the AN prepares to do connection admission control
on the indicated class(es) of flow.
As indicated in [I-D.ietf-ancp-protocol], the AN MUST NOT reply to
the Provisioning message if it processed it successfully. If an
error prevents successful processing of the message content, the AN
MUST return a Generic Response message as defined in
[I-D.ietf-ancp-protocol], containing a Status-Info TLV with the
appropriate content describing the error. For this purpose, the
presence of a list typein a Multicast-Service-Profile TLV which was
ignored because it was not supported by the negotiated set of
capabilities is not considered to be an error.
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.
When a new Multicast Service Profile is identified by a Multicast-
Service-Profile TLV, the initial state of all lists associated with
that profile according to the negotiated set of multicast
capabilities is empty until changed by the contents of Multicast-
Service-Profile TLVs.
4.2. Port Management Message 4.2. Port Management Message
As defined in [I-D.ietf-ancp-protocol], the NAS may send line As specified in [I-D.ietf-ancp-protocol], the NAS may send line
configuration information to the AN ("ANCP based Line Configuration" configuration information to the AN ("ANCP based Line Configuration"
use case) using GSMP Port Management messages modified to contain an use case) using GSMP Port Management messages modified to contain an
extension block. [I-D.ietf-ancp-protocol] defines a number of TLVs extension block. Section 5.4.3 of [I-D.ietf-ancp-protocol] defines a
that can be included in the Extension Value field inside a Port number of TLVs that can be included in the Extension Value field
Management message (e.g. "Access-Loop-Circuit-ID", "Service- inside a Port Management message to support line configuration.
Profile-Name").
This document specifies that the Port Management message MAY also be This document specifies that the Port Management message MAY also
used by the NAS to associate a "Multicast-Service-Profile" (aka. a include the following TLVs:
triple of White, Grey and Black lists) to a AN port. To do so, the
NAS includes a "Multicast-Service-Profile-Name" TLV (specified in
Section 5.6) in the Port Management message.
In addition, when bandwidth delegation is activated for this AN, the o "Multicast-Service-Profile-Name" TLV (defined in Section 5.7).
Port Management message MAY be used to provision the initial amount This TLV associates a Multicast Service Profile with the Access
of bandwidth delegated to the AN for multicast admission control Port specified by the extension block.
(hereafter referred to as the "delegated bandwidth"). To do so, the
NAS MAY include in the Port Management message a "Bandwidth-
Allocation" TLV (defined in Section 5.3) .
[Editor's Note: the Port Management message requires the o "Bandwidth-Allocation" TLV (defined in Section 5.3). This TLV
specification of an Access-Loop-Circuit-Id TLV indicating the target specifies the total multicast bandwidth available to the AN for
of the assignment. Thinking about the possibility of PON, will we be admission control at the Access Port.
updating the definition of Access-Loop-Circuit-Id TLV to include
default naming formats for PON? Of the authors, TT prefers this 4.2.1. Sender Behaviour
route, leaving Target to designate multiple targets for the same
command.] The NAS sends the Port Management message at startup time to
initialize parameters associated with the Access Port specified in
the message and with the multicast capabilities negotiated between
the NAS and the AN. The NAS MAY send additional Port Management
messages subsequent to startup, to update or, in the case of the
Bandwidth-Allocation TLV, reset these parameters. The NAS MUST NOT
include a TLV unless it is supported by the set of multicast
capabilities negotiated between the NAS and the AN. See Section 6
for further information.
4.2.2. Receiver Behaviour
If the Port Management message contains a Multicast-Service-Profile-
Name TLV, the AN associates the named profile with the specified
Access Port. This association replaces any previous association.
That is, a given Access Port is associated with at most one Multicast
Service Profile.
As specified in [I-D.ietf-ancp-framework], if a join request is later
received by the AN for a multicast flow that is part of multiple
lists in the Multicast Service Profile associated with the Access
Port, then the most specific match MUST be used by the AN. If the
most specific match occurs in multiple lists, the Black list entry
MUST take precedence over the Grey list, which MUST take precedence
over the White list. If the requested multicast flow is not part of
any list, the AN SHOULD ignore the join request.
If the Port Management message contains a Bandwidth-Allocation TLV,
the AN adopts this as the current value of its total multicast
bandwidth limit for the Access Port. If the AN has already committed
multicast bandwidth exceeding the amount given in the Bandwidth-
Allocation TLV, the AN SHOULD NOT discontinue any multicast streams
in order to bring bandwidth down to within the new limit. However,
the AN MUST NOT admit new multicast streams that are subject to
admission control until it can do so within the limit specified by
the Bandwidth-Allocation TLV.
If the Port Management request cannot be processed due to error and
the Result field of the request is Nack (0x1) or AckAll (0x2), the AN
SHOULD add a Status-Info TLV to the Extension Value field in its
reply if this will provide useful information beyond what is provided
by the Code value returned in the response header.
4.3. Multicast Replication Control Message 4.3. Multicast Replication Control Message
This section defines a new message called the Multicast Replication This section defines a new message called the Multicast Replication
Control message. The Multicast Replication Control message is sent Control message. The Multicast Replication Control message is sent
by the NAS to the AN with one or more directives to add (join) or by the NAS to the AN with one or more directives to add (join) or
delete (leave) a multicast flow on a target object identified in the delete (leave) a multicast flow on a target object identified in the
content of the message. When a response is needed an AN MUST use the content of the message.
Multicast Status message (defined in Section 4.4) to convey the
outcome of the directive.
The Message Type for the Multicast Replication Control message is The Message Type for the Multicast Replication Control message is
0x90. The sender of a Multicast Replication Control message MUST set 0x90.
the Result field to "0x00" meaning "Ignore". 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-protocol].
The NAS MAY issue a Multicast Replication Control message to the AN
to convey one or more directives to add (join) or delete (leave) a
multicast flow. The NAS sends this message on its own initiative to
support the NAS initiated Multicast Control use case presented in
[I-D.ietf-ancp-framework] and summarized in Section 3.1. The NAS
sends this message in response to a Multicast Admission Control
message (defined in Section 4.5) received from the AN to support the
conditional access and admission control use case presented in
[I-D.ietf-ancp-framework] and summarized in Section 3.2.
The ANCP Multicast Replication Control message payload contains the The ANCP Multicast Replication Control message payload contains the
following TLVs: following TLVs:
o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol]. o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol].
It MUST appear once and only once. It is encoded as specified in It MUST appear once and only once. It is encoded as specified in
[I-D.ietf-ancp-protocol] and identifies the AN port subject to the [I-D.ietf-ancp-protocol] and identifies the AN port subject to the
request for admission or release. request for admission or release.
o Command TLV: The Command TLV is defined in o Command TLV: The Command TLV is defined in
skipping to change at page 13, line 30 skipping to change at page 18, line 24
directive for the target. directive for the target.
The contents of the Command TLV for the Multicast Replication Control The contents of the Command TLV for the Multicast Replication Control
Message are defined in Figure 4 and subsequent text. Message are defined in Figure 4 and subsequent text.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |R O M Flags | Command Length | | Command Code |R O M Flags | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Multicast Flow Source Address | | Multicast Flow Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-\ /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Flow Source Address (Cont'd) ... | | (Cont'd) ... / \ | Multicast Flow Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-\ /-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Multicast Flow Group Address | | (Cont'd) ... / \ | Sub-TLVs ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+\ /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Flow Group Address (Cont'd) ... | | (Cont'd) ... / \ | Padding to 32-bit boundary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+\ /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding to 32-bit boundary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Command TLV in Multicast Replication Control Message Figure 4: Contents of the Command TLV in the Multicast Replication
Control Message
Command Code: Command Code:
Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete
All. All.
Command Length: Command Length:
Length in bytes of the Command including multicast flow Length in bytes of the Command including multicast flow
address, but excluding the Command Code header and flags. address, but excluding the Command Code header and flags.
Flags: Flags:
8 bit General purpose Flag field. Currently the following 8 bit General purpose Flag field. Currently the following
flags are defined: flags are defined:
R - Resource Admitted Flag. Set to 1 in an add R - Resource Admitted Flag. Set to 1 in an add
command to indicate that the flow resources have command to indicate that the flow resources have
been reserved by admission control, 0 otherwise. been reserved by admission control. Cleared to 0
Not used in delete command. otherwise.
O - Flow Accounting. When set in add command O - Flow Accounting. When set in add command
indicates that byte accounting for the flow is to indicates that byte accounting for the flow is to
commence. commence.
M - When set, indicates that the multicast flow is M - When set, indicates that the multicast flow is
SSM; the Command MUST then specify both the SSM; the Command MUST then specify both the
source and the group address. When not set, source and the group address. When not set,
indicates that the multicast flow is ASM; the indicates that the multicast flow is ASM; the
Command MUST then specify the group address only, Command MUST then specify the group address only,
omitting the Source Address field. omitting the Source Address field.
Address Family: Multicast Flow Source Address:
The address family of the address with values as defined in a field containing three sub-fields as illustrated in
[IANAAEA]. Figure 5, giving the source address for an SSM flow. This
field MUST be present if the M flag is set, and MUST NOT be
Encoding Type: present if the M flag is cleared.
The type of encoding used within a specific Address Family.
The value `0' is reserved for this field, and represents
the native encoding of the Address Family. This is
consistent with the address encoding specified in
[RFC4601].
Address: Multicast Flow Group Address:
The address as represented by the given Address Family and a field containing three sub-fields as illustrated in
Encoding Type. This is consistent with the address Figure 5, giving the group address for the multicast flow.
encoding specified in [RFC4601]. This field MUST be present.
If needed, padding is done after both addresses so that the TLV is The address family of the group address MAY differ from the address
32-bit aligned. family of the source address, if present.
If the AN receives a Multicast Replication Control Message containing For future extensibility, each Command TLV MAY also have additional
an unrecognized Target TLV, the AN MUST return a Multicast Status sub-TLVs appended following the command and multicast flow
Message (Section 4.4) indicating the "Unrecognised port Type - 0x04" information (shown as "Sub-TLVs" in Figure 4). Unrecognized sub-TLVs
error. SHOULD be silently discarded.
Each Multicast Replication Control Message MAY contain one or more If needed, padding is done at the end of the command data so that the
commands, each encapsulated in its own Command TLV. The sender MUST TLV is 32-bit aligned.
use a separate Command TLV for each distinct multicast flow.
When successive commands (in the same or different messages) relate As shown in Figure 5, each address entry in the Command TLV consists
to the same Target and multicats flow, the state of each feature of the following three sub-fields with no intervening padding:
controlled or affected by flags or by optional attributes received in
the Multicast Replication Control message, SHALL be as set by the
last command or message referring to that target and flow and
containing the controlling flag or optional attribute. As an
example, successive Multicast Replication Control messages containing
add commands for a given port and flow, but differing only in the
accounting flag setting SHALL be interpreted to mean that the state
of the accounting feature is as set in the final command received,
but all other feastures are as set in the initial message.
If more than one Command TLV is present in a Multicast Replication Address Family:
Control message, the AN MUST act on the commands in the order in The address family of the address with values as defined in
which they are presented in the message. The AN SHALL assign a [IANAAEA].
sequence number to each command in a given Multicast Replication
Control message, starting from 0x01 for the first command. The AN
MUST use the assigned sequence number in any response message when
necessary to distinguish the Command TLV instance to which a given
status code applies.
The processing/execution of multiple commands contained in a single Encoding Type:
Multicast Control message MUST be interrupted at the first error The type of encoding used within a specific Address Family. The
encountered, and the remaining commands in the Multicast Replication value `0' is reserved for this field, and represents the native
Control message discarded. In such a case a Multicast Status message encoding of the Address Family. This is consistent with the
MUST be sent indicating the command number that resulted in the error address encoding specified in [RFC4601].
along with the error code.
When the order of processing of two commands does not matter, the Address:
commands MUST be transmitted in separate Multicast Replication The address as represented by the given Address Family and
Control messages. Encoding Type. This is consistent with the address encoding
specified in [RFC4601].
Each command directive is equipped with an 8-bit Flags field that 0 1 2 3
allows specification of Multicast ASM or SSM modes of operation, and 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
an indication of other features or conditions attached to this +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
command (e.g. To enable accounting for the flow, etc). Unassigned | Addr Family | Encoding Type | IP Address |
flags are reserved for future use, and could in the future be subject +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/-+-+-+-+-+-+-+-+
of the capability negotiation. When receiving a Multicast | IP Address (Cont'd) ... \
Replication Control Message containing an unrecognized Flag set (to +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/-+-+-+-+-+-+-+-+
1), a recipient MUST interpret it as an error, and generate an
Multicast Status message indicating the error.
The multicast flow subject to the command is specified by means of Figure 5: Structure of the Address Fields in the Command TLV
one or two well known Address Family designators ([IANAAEA]), the
IPv4-Address-Family (0x01) and the IPv6-Address-Family (0x02). When
the M flag is set the two Address-Family tuples MUST be present in
the strict order specifying the multicast flow source and group
respectively. When the M flag is cleared only one Address-Family is
allowed, specifying the multicast flow.
For future extensibility, each Command TLV MAY also have additional The figure below is an example of a Multicast Replication Control
[sub- or same level ????] TLVs appended following the command and message that would result in a swap from multicast SSM flows
multicast flow information (referred to as "TLVs" in the message 192.0.2.1, 233.252.0.2, to 192.0.2.2, 233.252.0.3 on the Target
format above). Unrecognized TLVs SHOULD be silently discarded. The identified by the "Access Loop Circuit ID":
figure below is an example of a Multicast Replication Control message
that would result in a swap from multicast SSM flows 192.0.2.1,
233.252.0.2, to 192.0.2.2, 233.252.0.3 on the Target identified by
the "Access Loop Circuit ID":
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length | | Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=90 | 0x02 | Code | | Vers | Sub |MessageType=90 | 0x02 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0001 | | Partition ID | Transaction Identifier = 0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
skipping to change at page 17, line 44 skipping to change at page 21, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 |0 0 1 | Command Length | | Cmd Code=0x01 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 | | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Mcast Source (Ctnd) 192.0.2.2 | AddrFamily 01 | EncType 0x0 | |Mcast Source (Ctnd) 192.0.2.2 | AddrFamily 01 | EncType 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast Flow: 233.252.0.3 | | Mcast Flow: 233.252.0.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4. Multicast Status Message 4.3.1. Sender Behaviour
This section defines a new message called the Multicast Status The NAS MAY issue a Multicast Replication Control message to the AN
message. The general purpose of the Multicast Status message is to to convey one or more directives to add (join) or delete (leave) one
provide information on the success or failure to process a message or more multicast flows.
previously received from the sender's peer. Depending on the
particular use case, the Multicast Status message MAY be sent by
either the NAS or the AN. In some cases the Multicast Status message
is REQUIRED, even when processing of the original message is
successful. In other cases the Multicast Status message is used only
to report failures. For further details see the descriptions of
other multicast-related messages presented in this section.
The Message Type for the Multicast Status message is 0x91. The NAS MAY send this message on its own initiative to support the
NAS initiated Multicast Control use case presented in
[I-D.ietf-ancp-framework] and summarized in Section 3.1. In that
case, the NAS MUST set the Result field to AckAll (0x2) or Nack (0x1)
according to its requirements.
A Multicast Status message MUST use the same ANCP Transaction ID as The NAS MAY also send this message in response to a Multicast
that in the message that it is responding to. The Success or Failure Admission Control message (defined in Section 4.4) received from the
status is reported in the Result field of the ANCP header as AN to support the conditional access and admission control use case
described in section 5 of [I-D.ietf-ancp-protocol]. presented in [I-D.ietf-ancp-framework] and summarized in Section 3.2.
In that case, the NAS MUST set the Result field to NAck (0x1).
A Multicast Status Message indicating Success SHOULD simply consist In either case, the sender MUST populate the Code field with the
only of the base ANCP header with no body, however the message MAY value 0x000 and the ANCP Transaction Identifier field with a unique
contain one or more TLVs that are meant to communicate any relevant value, as described in section 5.4.5 of [I-D.ietf-ancp-protocol].
information to an application. The payload of a Multicast Status
Message indicating Failure MUST contain a Status-Info TLV (0x12) (as
defined in [I-D.ietf-ancp-protocol]) as its first TLV. This SHOULD
be followed by the Target TLV (as defined in
[I-D.ietf-ancp-protocol]) and Port-info [???]. Other TLVs MAY be
present. A Multicast Status message indicating Failure MUST be sent
whenever a multicast control message cannot be fulfilled or results
in an execution error. The Cmnd Nmbr parameter in the Status-Info
TLV contained by the Multicast Status Message is used to indicate the
sequence number of the command in the Multicast Replication Control
Message that resulted in an error. In the case where the problem is
with the Multicast Replication Control Message as a whole, or in the
case where the problem is with a message that is not a Multicast
Replication Control message, the Cmnd Nmbr parameter SHOULD be set to
0x00.
The following values are defined for the Result Code field in the Each Multicast Replication Control Message MAY contain one or more
Status-Info TLV contained in a Multicast Status Message: commands, each encapsulated in its own Command TLV. The sender MUST
use a separate Command TLV for each distinct multicast flow.
0x00 - Success When the order of processing of two commands does not matter, the
commands MUST be transmitted in separate Multicast Replication
Control messages.
0x01 - Malformed message The NAS MAY choose to perform admission control before adding a
particular flow even if admission control has been enabled on the AN.
If it does so, it MUST set the R flag in the Command TLV concerned.
Conversely, if admission control has been enabled on the AN, the NAS
MAY choose to have the AN do admission control by clearing the R
flag.
0x02 - Command not supported Note that clearing the R flag causes the AN to allocate resources
for the flow out of its bandwidth budget as opposed to any
bandwidth budget managed for the same access line at the NAS.
0x03 - Flag set but not supported 4.3.2. Receiver Behaviour
0x04 - Unrecognized Target When successive commands (in the same or different messages) relate
0x05 - Unsupported Address Family to the same Target and multicast flow, the state of each feature
controlled or affected by flags or by optional attributes received in
the Multicast Replication Control message, SHALL be as set by the
last command or message referring to that target and flow and
containing the controlling flag or optional attribute. As an
example, successive Multicast Replication Control messages containing
add commands for a given port and flow, but differing only in the
accounting flag setting SHALL be interpreted to mean that the state
of the accounting feature is as set in the final command received,
but all other features are as set in the initial message.
0x06 - Malformed flow address If more than one Command TLV is present in a Multicast Replication
Control message, the AN MUST act on the commands in the order in
which they are presented in the message. The AN SHALL assign a
sequence number to each command in a given Multicast Replication
Control message, starting from 0x01 for the first command.
0x07 - No resources If admission control for Multicast Replication Control messages has
not been enabled (through provisioning of the MRepCtl_CAC TLV, the AN
MUST ignore the R flag in Command TLVs. Otherwise, if a Command TLV
adds a flow, the R flag within the TLV is not set, and the AN is
performing admission control for Multicast Replication Control
messages, then the AN MUST perform admission control before
replicating the flow. If the admission control check fails, the AN
MUST treat the failure as an error as described below. The
appropriate Code value for the response is 18 (0x012) "Insufficient
resources".
0x08 - Unknown Target If the AN processes the complete Multicast Replication Control
message successfully and the Result field of the Multicast
Replication Control message was set to AckAll (0x2), the AN MUST
respond with a Generic Response message where the Result field is set
to Success (0x3), the Code field is set to 0x000, and the Transaction
Identifier field is copied from the Multicast Replication Control
message. The body of the response MAY be empty or MAY be copied from
the Multicast Replication Control message.
0x09 - Target down The processing/execution of multiple commands contained in a single
Multicast Control message MUST be interrupted at the first error
encountered, and the remaining commands in the Multicast Replication
Control message discarded.
0x0a - Configuration error (such as Port not enabled for If the AN detects an error in a received Multicast Replication
multicast) Control message and the Result field in that message was set to Nack
(0x1) or AckAll (0x2), the AN MUST generate a Generic Response
message providing error information to the NAS. This specification
identifies the following new Code values beyond those specified in
[I-D.ietf-ancp-protocol], which MAY be used in a Generic Response
sent in reply to a Multicast Replication Control message:
0x0b - Multicast flow does not exist 0x100 Command error. This SHOULD be reported for the following
cases:
0x0c - Unsupported address encoding * invalid command code;
0x0d - Additional info needed to execute command (payload MAY * undefined flag set.
contain an indication of the expected info)
0x0e - Multicast flow count exceeded 0x101 Bad flow address. This SHOULD be reported for the following
cases:
0x0f - M Flag set, but no IP Source address provided * unsupported address family;
0x10 - Transaction-id out of sequence * unsupported address encoding;
0x11 - Invalid preferred bandwidth amount * source address present when M flag cleared, or absent when M
flag set.
0x12 - Bandwidth delegation not activated 0x102 Multicast flow does not exist. This SHOULD be reported if the
NAS attempts to delete a flow that is not enabled.
0x13 - Delegated bandwidth reset required A Generic Response message responding to the Multicast Replication
Control message and containing one of the above Code values MUST
include a Status-Info TLV which includes one or two sub-TLVs as
follows:
An example of a failure message for an invalid address, including the o a Command Number TLV as described in Section 5.2, giving the
Target TLV for a 4 byte "Access Loop Circuit ID", followed by TLV sequence number of the failed command, MUST be included;
padding, is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 o the failed Command TLV itself SHOULD be included.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=91 | 0x4 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-info-TLV=0x12 | Status-TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Cmd Number | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4) if Length > 0 |
+---------------------------------------------------------------+
| Target TLV=0x10 | Target-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop ID type | Access-Loop ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.5. Multicast Admission Control Message Note that the Error Message field of the Status-Info TLV MAY be
used to report more details than implied by the Code value in the
message header. For example, the Code value could be 0x101 and
the Error Message field could contain the text: "Source address
present when M flag cleared".
4.4. Multicast Admission Control Message
This section defines a new message called the Multicast Admission This section defines a new message called the Multicast Admission
Control message. The Multicast Admission Control message is sent by Control message. The Multicast Admission Control message is sent by
the AN to the NAS to request admission of a multicast flow, or to the AN to the NAS to request admission of a multicast flow, or to
notify of the removal of a multicast flow, over a given target. The notify of the removal of a multicast flow, for a given target.
NAS will use a Multicast Replication Control message (as discussed in
Section 4.3) in order to convey back to the AN the outcome of the
admission request.
The Message Type for the Multicast Admission Control message is 0x92. The Message Type for the Multicast Admission Control message is 0x92.
The AN sending the Multicast Admission Control message MUST set the
Result field to "0x00" meaning "Ignore".
The AN MUST populate the ANCP Transaction Identifier field with a
unique value, as described in section 5.4.5
of[I-D.ietf-ancp-protocol] .
The ANCP Multicast Admission Control message payload contains two The ANCP Multicast Admission Control message payload contains two
TLVs: TLVs:
o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol]. o Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol].
It MUST appear once and only once in the Multicast Admission It MUST appear once and only once in the Multicast Admission
Control message. It is encoded as specified in Control message. It is encoded as specified in
[I-D.ietf-ancp-protocol] and identifies the AN port subject to the [I-D.ietf-ancp-protocol] and identifies the AN port subject to the
request for admission or release. request for admission or release.
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 the document and the other instances are present version of this specification and the other instances are
ignored . The Command TLV is encoded as specified in Section 4.3 ignored.
with the following additional rules:
* the R flag is set to 0 Informative note:
* the O flag is set to 0 In the future, the specification of the Admission Control message
may be extended to allow transport of more than a single directive
(e.g. to carry both a leave from one group and a join to another
group for the same Target). It is expected that this would
support a similar notion of strict sequenced processing as
currently defined for handling multiple directives in the
Multicast Replication Control message whereby all directives
following the first directive that can not be executed are not
executed either. When the strict sequenced processing of the
directives is not required the directives are distributed across
separate messages.
* the Command field is set to "0x01 - Add" when the message 4.4.1. Sender Behaviour
conveys a Join , to "0x02 - Delete" when the message conveys a
Leave and to "0x03 - Delete All" when the message conveys a
Leave of all channels (on the target).
* The M Flag, Multicast Source Address and Multicast Flow Address The AN sending the Multicast Admission Control message MUST set the
of the Command TLV identify the multicast flow subject to the Result field to Ignore (0x0).
request for admission or release.
* a Request-Source-IP sub-TLV (as defined in Section 5.7) MAY be The AN MUST populate the ANCP Transaction Identifier field with a
included by the AN to convey the IP address of the sender of unique value, as described in section 5.4.5
the join/leave message (e.g. IGMP/MLD Join/Leave) that of[I-D.ietf-ancp-protocol] .
triggered the AN to include the corresponding Command TLV in
the Admission Control message. If it appears more than once,
only the first instance is considered meaningful and the other
instances are ignored.
* a Request-Source-MAC sub-TLV (as defined in Section 5.8) MAY be The AN MUST encode the Command TLV as specified in Section 4.3 with
included by the AN to convey the MAC address of the sender of the following additional rules:
the join/leave message (e.g. IGMP/MLD Join/Leave) that
triggered the AN to include the corresponding Command TLV in
the Admission Control message. If it appears more than once,
only the first instance is considered meaningful and the other
instances are ignored.
In the future, the specification of the Admission Control message may o the R flag MUST be set to 0;
be extended to allow transport of more than a single directive (e.g.
to carry both a leave from one group and a join to another group for o the O flag MUST be set to 0;
the same Target). It is expected that this would support a similar
notion of strict sequenced processing as currently defined for o the Command Code field MUST be set to "0x01 - Add" when the
handling multiple directives in the Multicast Replication Control message conveys a Join , to "0x02 - Delete" when the message
message whereby all directives following the first directive that can conveys a Leave and to "0x03 - Delete All" when the message
not be executed are not executed either. When the strict sequenced conveys a Leave of all channels (on the target);
processing of the directives is not required the directives are
distributed across separate messages. o The M Flag, Multicast Source Address and Multicast Flow Address of
the Command TLV identify the multicast flow subject to the request
for admission or release. When the Command Code is 0x03, the M
Flag, Multicast Source address, and Multicast Flow Address are
meaningless and MUST be set to all zeroes.
o a Request-Source-IP sub-TLV (as defined in Section 5.8) MAY be
included by the AN to convey the IP address of the sender of the
join/leave message (e.g. IGMP/MLD Join/Leave) that triggered the
AN to include the corresponding Command TLV in the Admission
Control message. If it appears more than once, only the first
instance is considered meaningful and the other instances are
ignored.
o a Request-Source-MAC sub-TLV (as defined in Section 5.9) MAY be
included by the AN to convey the MAC address of the sender of the
join/leave message (e.g. IGMP/MLD Join/Leave) that triggered the
AN to include the corresponding Command TLV in the Admission
Control message. If it appears more than once, only the first
instance is considered meaningful and the other instances are
ignored.
4.4.2. Receiver Behaviour
On receipt of an Multicast Admission Control message, the NAS: On receipt of an Multicast Admission Control message, the NAS:
o MUST ignore the Result field o MUST ignore the Result field;
o if the directive in the Multicast Admission Control message is o if the directive in the Multicast Admission Control message is
"0x02 - Delete" or "0x03 - Delete All" and is processed correctly "0x02 - Delete" or "0x03 - Delete All" and is processed correctly
by the NAS, the NAS MUST NOT generate any ANCP message in response by the NAS, the NAS MUST NOT generate any ANCP message in response
to the Multicast Admission Control message to the Multicast Admission Control message;
o if the directive in the Multicast Admission Control message is o if the directive in the Multicast Admission Control message is
"0x01 - Add" and is accepted by the NAS, the NAS MUST generate a "0x01 - Add" and is accepted by the NAS, the NAS MUST generate a
Multicast Replication Control in response to the Multicast Multicast Replication Control in response to the Multicast
Admission Control message. The Multicast Replication Control Admission Control message. The Multicast Replication Control
message: message:
* MUST contain a Result set to 0x00 * MUST contain a Result set to Nack (0x1);
* MUST contain a Transaction ID generated by the NAS (distinct * MUST contain a Transaction ID generated by the NAS (distinct
non-zero, and linearly incremented by NAS for each request per non-zero, and linearly incremented by NAS for each request per
adjacency). adjacency);
* MUST contain the directive as accepted by the NAS * MUST contain the directive as accepted by the NAS. The R flag
in the returned Command TLV MUST have value 0 if the NAS
intends the AN to perform admission control before installing
the flow, 1 otherwise. Note that the AN will ignore the R flag
unless the MRepCtl_CAC TLV has been provisioned on the AN.
o if the directive in the Multicast Admission Control message is o if the directive in the Multicast Admission Control message is
"0x01 - Add", is processed correctly but not accepted by the NAS "0x01 - Add", is processed correctly but not accepted by the NAS
(i.e. it does not pass the admission control or conditional access (i.e. it does not pass the admission control or conditional access
check), the NAS MAY generate a Multicast Replication Control check), the NAS MAY generate a Multicast Replication Control
message in response to the Multicast Admission Control message. message in response to the Multicast Admission Control message.
This optional message can be used by the AN to maintain statistics This optional message can be used by the AN to maintain statistics
about admission control reject and, in the future, when the about admission control reject and, in the future, when the
protocol between the subscriber and the AN allows explicit protocol between the subscriber and the AN allows explicit
notification of join reject (e.g. notification of join reject (e.g.
[I-D.morin-mboned-igmpmld-error-feedback]). When used in this [I-D.morin-mboned-igmpmld-error-feedback]). When used in this
situation, the Multicast Replication Control message: situation, the Multicast Replication Control message:
* MUST contain a Result set to 0x00 * MUST contain a Result set to 0x00;
* MUST contain a Transaction ID generated by the NAS (distinct * MUST contain a Transaction ID generated by the NAS (distinct
non-zero, and linearly incremented by NAS for each request per non-zero, and linearly incremented by NAS for each request per
adjacency). adjacency);
* MUST contain the directive rejected by the NAS (i.e. Target * MUST contain the directive rejected by the NAS (i.e. Target
TLV and Command TLV) but with a Command Code set to "0x04 - TLV and Command TLV) but with a Command Code set to "0x04 -
Admission Control Reject", "0x05 - Conditional Access Reject" Admission Control Reject", "0x05 - Conditional Access Reject"
or "0x06 - Admission Control and Conditional Access Reject". or "0x06 - Admission Control and Conditional Access Reject".
o if the Multicast Admission Control message cannot be processed o if the Multicast Admission Control message cannot be processed
correctly by the NAS (e.g. the message is malformed, the multicast correctly by the NAS (e.g. the message is malformed, the multicast
flow does not exist etc.), the NAS MUST generate a Multicast flow does not exist etc.), the NAS MUST generate a Generic
Status message (defined in Section 4.4) in response to the Response message (defined in [I-D.ietf-ancp-protocol]) with
Multicast Admission Control message. The Multicast Status appropriate content indicating the reason for the failure.
message:
* MUST contain a Result set to "Failure" in the ANCP header 4.5. Bandwidth Reallocation Request Message
* MUST contain a Transaction ID that echoes the value of the The Bandwidth Reallocation Request message is used when the bandwidth
Transaction ID received in the Multicast Admission Control delegation capability is included in the negotiated set. It MAY be
message. sent either by the NAS or by the AN to request an adjustment in the
amount of delegated bandwidth. It will be sent by the NAS typically
to reduce the multicast bandwidth allocated to the AN in order for
the NAS to satisfy a request to add one or more flows. Conversely,
the AN will send a Bandwidth Reallocation Request to obtain
additional bandwidth to satisfy a request to add a multicast channel.
In each case, the requestor has a minimum requirement for additional
bandwidth, and MAY ask for additional bandwidth beyond this amount
(e.g., to handle anticipated future requests).
* MUST contain a Status TLV including a Result Code indicating The Bandwidth Reallocation Request message contains two TLVs:
the reason why the Admission Control message could not be
processed and encoded as specified in Section 4.4.
4.6. Bandwidth Reallocation Request Message o the Target TLV (section 5.4.5.1.1 of [I-D.ietf-ancp-protocol]),
specifying a single access line;
The Bandwidth Reallocation Request message is used when the Bandwidth o the Bandwidth-Request TLV (Section 5.6), specifying the required
Delegation capability has been activated. It MAY be sent either by and preferred amounts of delegated bandwidth.
the NAS or by the AN to request an adjustment in the amount of
delegated bandwidth. It will be sent by the NAS typically to reduce
the multicast bandwidth allocated to the AN in order for the NAS to
satisfy a request to add a unicast video channel. Conversely, the AN
will send a Bandwidth Reallocation Request to obtain additional
bandwidth to satisfy a request to add a multicast channel. In each
case, the requestor has a minimum requirement for additional
bandwidth, and MAY ask for additional bandwidth beyond this amount
(say to handle anticipated future requests).
The Message Type for the Bandwidth Reallocation Request message is The Message Type for the Bandwidth Reallocation Request message is
0x94. The Result field in the header of the Bandwidth Reallocation 0x94.
Request message is not used and MUST be set to Ignore (0x00). The
Bandwidth Reallocation Request message MUST contain two TLVs:
o the Target TLV (section 5.4.5.1.1 of [I-D.ietf-ancp-protocol]), 4.5.1. Sender Behaviour
specifying a single access line; [TT - I would prefer the Access-
Loop-Circuit-Id TLV, believing it should evolve to include non-DSL
identifiers, but the majority overruled me];
o the Bandwidth-Request TLV (Section 5.4), specifying the required The Result field in the header of the Bandwidth Reallocation Request
and preferred amounts of delegated bandwidth. message is not used and the sender MUST set it to Ignore (0x0).
The bandwidth values in the Bandwidth-Request TLV are expressed in The bandwidth values in the Bandwidth-Request TLV are expressed in
terms of total bandwidth delegated to the AN. terms of total multicast bandwidth allocated to the AN.
The choice of "total bandwidth" rather than "incremental The choice of "total bandwidth" rather than "incremental
bandwidth" was made so that it would be easier for the AN and NAS bandwidth" was made so that it would be easier for the AN and NAS
to keep their respective views of the current amount of delegated to keep their respective views of the current amount of delegated
bandwidth synchronized. bandwidth synchronized.
Because the values are totals rather than desired increments/ Because the values are totals rather than desired increments/
decrements, the relationship between the required amount and the decrements, the relationship between the required amount and the
preferred amount will differ depending on whether the Bandwidth preferred amount will differ depending on whether the Bandwidth
Reallocation Request message is issued by the NAS or the AN. Reallocation Request message is issued by the NAS or the AN.
o If the NAS is making the request, the preferred amount MUST be o If the NAS is making the request, the preferred amount MUST be
less than or equal to the required amount. The required amount less than or equal to the required amount. The required amount
MUST be less than the current delegated bandwidth value. MUST be less than the currently amount of delegated bandwidth.
o If the AN is making the request, the preferred amount MUST be o If the AN is making the request, the preferred amount MUST be
greater than or equal to the required amount. The required amount greater than or equal to the required amount. The required amount
MUST be greater than the current delegated bandwidth value. MUST be greater than the currently amount of delegated bandwidth.
If these conditions are violated and the problem is the relationship 4.5.2. Receiver Behaviour
between the required amount and the receiver's view of the current
delegated bandwidth, the delegated bandwidth reset procedure
described in Section 4.10 MUST be performed. If the problem is the
relationship between the preferred and required amounts, the peer
receiving the Bandwidth Reallocation Request message MUST return a
Multicast Status message where the Result field in the header
indicates Failure (0x4) and the Status-Info TLV contains the
following values:
Result Code = invalid preferred bandwidth amount (0x11); When the peer receives a valid Bandwidth Reallocation Request
message, it SHOULD determine whether it can satisfy the request from
its existing allocation of unused video bandwidth. If it decides
that it can reallocate bandwidth to the peer, it MAY choose to return
any amount between the required and the preferred amounts indicated
in the Bandwidth Reallocation Request message.
Command Number = 0x1; The peer MUST return a Bandwidth Transfer message Section 4.6
indicating its decision. If the request is met, the Result field of
the Bandwidth Transfer message MUST be set to Success (0x3), the Code
field MUST be set to 0x000, and the Bandwidth-Allocation TLV
(Section 5.3) MUST contain the new value of total multicast
bandwidth. This new value MUST lie between the required and
preferred values, inclusive, from the request message. If the
request is not met, the Result field of the Bandwidth Transfer
message MUST be set to Failure (0x4), the Code field MUST be set to
0x000, and the Bandwidth Allocation TLV MUST contain the value of the
currently allocated amount of delegated bandwidth as the responder
views it.
Error Message Length = 0x0 (or optionally the length of an error The following cases indicate that the sender holds a different view
message, padded to a four-octet boundary); of the amount of bandwidth from the receiver:
Error Message (optional text); o the NAS receives a request where the required amount is less than
its view of the current amount of delegated bandwidth;
the Target TLV, copied from the Bandwidth Reallocation Request o the AN receives a request where the required amount is greater
message; than its view of the current amount of delegated bandwidth.
the Bandwidth-Request TLV, also copied from the request message. If one of these cases occurs, the receiver with one exception MUST
send a Bandwidth Transfer message indicating Success.
When the peer receives a valid Bandwidth Reallocation Request o If the NAS received the request, the allocated amount in the NAS's
message, it SHOULD determine whether it can satisfy the request from response MUST be at least equal to NAS's view of the current
its existing allocation of unused video bandwidth. If it decides amount of delegated bandwidth.
that it can reallocate bandwidth to the peer, it MAY choose to return
any amount between the required and the preferred amounts indicated o If the AN received the request, the allocated amount in the AN's
in the Bandwidth Reallocation Request message. The peer MUST return response MUST be no greater than the AN's view of the current
a Bandwidth Transfer message Section 4.7 indicating its decision. If amount of delegated bandwidth.
the request is met, the Result field of the Bandwidth Transfer
message MUST be set to Success (0x3), and the Bandwidth-Allocation The exception is when the NAS receives a request while it has a
TLV (Section 5.3) MUST contain the new value of delegated bandwidth. request of its own outstanding. Handling of that case is described
This new value MUST lie between the required and preferred values, below.
inclusive, from the request message. If the request is not met, the
Result field of the Bandwidth Transfer message MUST be set to Failure While the cases just described are an error condition, the success
(0x4) and the Bandwidth Allocation TLV MUST contain the value of the response achieves a graceful recovery.
current amount of delegated bandwidth as the responder views it.
To avoid deadlock due to race conditions, the following rules MUST be To avoid deadlock due to race conditions, the following rules MUST be
applied: applied:
a. If the NAS receives a Bandwidth Reallocation Request message a. If the NAS receives a Bandwidth Reallocation Request message
while it has a Bandwidth Reallocation Request message of its own while it has a Bandwidth Reallocation Request message of its own
outstanding for the same access line, the NAS MUST provide an outstanding for the same access line, the NAS MUST provide an
immediate failure response to the request from the AN. immediate failure response to the request from the AN, with a
Code value set to 0x105 "Bandwidth request conflict".
b. If the AN receives a Bandwidth Reallocation Request message while b. If the AN receives a Bandwidth Reallocation Request message while
it has a Bandwidth Reallocation Request message of its own it has a Bandwidth Reallocation Request message of its own
outstanding for the same access line, the AN MUST release any outstanding for the same access line, the AN MUST release any
bandwidth it has already committed to an outstanding Join request bandwidth it has already committed to an outstanding Join request
while it is awaiting a response from the NAS. It MUST decide while it is awaiting a response from the NAS. It MUST decide
upon and send its response to the NAS taking the released upon and send its response to the NAS taking the released
bandwidth into account. bandwidth into account.
[Editor's Note: This is an arbitrary rule which gives priority to If the receiver is unable to process the Bandwidth Reallocation
unicast over multicast. Is that the right direction?] Request message due to an error, then the receiver MUST return a
Bandwidth Transfer message where:
4.7. Bandwidth Transfer Message o the Result field is set to Failure (0x4),
o the Code field is set appropriately to indicate the type of error
that was detected,
o the Bandwidth Allocation TLV contains the value of the current
amount of delegated bandwidth as the responder views it, and
o a Status-Info TLV MAY follow the Bandwidth Allocation TLV giving
further information about the error.
This specification provides three new Code values applicable
specifically to the contents of the Bandwidth-Request TLV. These
Code values by their nature MUST only be used when the error is being
reported in a Bandwidth Transfer message rather than a Generic
Response message.
0x103 invalid preferred bandwidth amount. This indicates that the
preferred and required amounts of bandwidth in the TLV do not have
the numerical relationship described in the previous section.
0x104 inconsistent views of delegated bandwidth amount. This will
appear only in a Bandwidth Transfer message from the NAS to the AN
in the case where the NAS has an outstanding Bandwidth
Reallocation Request. The recommended procedure for recovery is
described in Section 4.6.2.
0x105 bandwidth request conflict. The NAS has rejected the AN's
request for more bandwidth because the NAS has an outstanding
bandwidth request.
4.6. Bandwidth Transfer Message
The Bandwidth Transfer message is used to transfer video bandwidth The Bandwidth Transfer message is used to transfer video bandwidth
from the sender to the peer for a specific access line. This message from the sender to the peer for a specific access line. This message
MAY be sent either from the AN or from the NAS. As described in the MAY be sent either from the AN or from the NAS. As described in the
previous section, it is the required response to a valid Bandwidth previous section, it is the required response to a valid Bandwidth
Reallocation Request message. Reallocation Request message.
The Bandwidth Transfer message MAY also be used to transfer bandwidth The Bandwidth Transfer message MAY also be used to transfer bandwidth
autonomously from one peer to another. One example of this usage is autonomously from one peer to another. One example of this usage is
to release bandwidth borrowed earlier by means of the Bandwidth to release bandwidth borrowed earlier by means of the Bandwidth
Reallocation Request message. When the message is used in this way, Reallocation Request message. When the message is used in this way,
the Result field in the Bandwidth Transfer message MUST be set to the Result field in the Bandwidth Transfer message MUST be set to
Ignore (0x0). Ignore (0x0).
This allows the receiver to distinguish between an autonomous This allows the receiver to distinguish between an autonomous
transfer and a response to a previous Bandwidth Reallocation transfer and a response to a previous Bandwidth Reallocation
Request, for purposes of validation. Request, for purposes of validation.
The Message Type for the Bandwidth Transfer message is 0x95. The The Message Type for the Bandwidth Transfer message is 0x95. The
Bandwidth Transfer message MUST contain the following TLVs: Bandwidth Transfer message contains the following TLVs:
o the Target TLV, designating the access line concerned; o the Target TLV, designating the access line concerned;
o an instance of the Bandwidth-Allocation TLV (Section 5.3). o an instance of the Bandwidth-Allocation TLV (Section 5.3). The
bandwidth value in the Bandwidth-Allocation TLV is the new amount
of delegated bandwidth allocated to the target.
The bandwidth value in the Bandwidth-Allocation TLV is the new amount 4.6.1. Sender Behaviour
of delegated bandwidth. The following relationships MUST hold:
When sending a Bandwidth Transfer message where the Result value is
Ignore (0x0) or Success (0x3), the following relationships MUST hold:
o if the message is sent by the NAS, the bandwidth value in the o if the message is sent by the NAS, the bandwidth value in the
Bandwidth-Allocation TLV MUST be greater than or equal to the Bandwidth-Allocation TLV MUST be greater than or equal to the
current amount of delegated bandwidth for the access line sender's view of the current amount of delegated bandwidth for the
concerned; access line concerned;
o if the message is sent by the AN, the bandwidth value in the o if the message is sent by the AN, the bandwidth value in the
Bandwidth-Allocation TLV MUST be less than or equal to the current Bandwidth-Allocation TLV MUST be less than or equal to the
amount of delegated bandwidth for the access line concerned. sender's view of the current amount of delegated bandwidth for the
access line concerned.
In either case, equality to the current delegated bandwidth is Further sender behaviour is specified above, in Section 4.5.2.
permitted only for a failure response to a previous Bandwidth
Reallocation Request.
If the Bandwidth Transfer message satifies these conditions, the 4.6.2. Receiver Behaviour
receiver MUST update its view of the amount of delegated bandwidth to
the value given in the Bandwidth-Allocation TLV. If, on the other
hand, the bandwidth value in the Bandwidth-Value TLV is invalid, the
receiver MAY either accept the new value or MAY choose to initiate
the delegated bandwidth reset procedure described in Section 4.10.
4.8. Delegated Bandwidth Query Request and Response Messages 4.6.2.1. Behaviour of the NAS
The Message Type for the Delegated Bandwidth Query Request and If the amount of delegated bandwidth provided in the Bandwidth-
Response messages is 0x96. Allocation TLV is not greater than the NAS's view of the current
amount of delegated bandwidth, the NAS MUST update its view of the
current amount of delegated bandwidth to the amount indicated in the
Bandwidth Transfer message. This is required regardless of whether
the Result field of that message indicates Success or Failure.
The Delegated Bandwidth Query Request message MAY be sent by the NAS If the amount of delegated bandwidth provided in the Bandwidth-
to retrieve the AN's view of the total amount of delegated bandwidth Allocation TLV is greater than the NAS's view of the current amount
and the amount that is already committed. The request contains one of delegated bandwidth, the NAS MAY accept the given value as its new
TLV: value of delegated bandwidth. Alternatively, the NAS MAY force the
AN to modify its view of the amount of delegated bandwidth to that
held by the NAS, by sending a Port Management message for the target
access line concerned, containing a Bandwidth-Allocation TLV with a
value equal to the amount of delegated bandwidth the NAS wishes to
enforce.
o a Target TLV designating the access line(s) for which the 4.6.2.2. Behaviour of the AN
information is requested.
Consistently with other multicast-related messages, the Result field If the amount of delegated bandwidth provided in the Bandwidth-
in the header of the Delegated Bandwidth Query Request message MUST Allocation TLV of the Bandwidth Transfer message differs from the
be set to Ignore (0x0). AN's view of the current amount of delegated bandwidth, the AN MUST
update its view of the current amount of delegated bandwidth to the
amount indicated in the Bandwidth Transfer message. This is required
with the exception of a Bandwidth Transfer message with a Result
field equal to Failure (0x4) and a Code field equal to 0x104
"Inconsistent views of delegated bandwidth amount" or 0x105
"Bandwidth request conflict". If Code value 0x104 is received, the
AN MUST issue a Delegated Bandwidth Query Request message to
determine the NAS's current view of the amount of delegated
bandwidth. The AN MUST update its own view based on the value
returned in the Delegated Bandwidth Query Response. If Code value
0x105 is received, the AN SHOULD carry out this procedure unless it
can account for the discrepancy as a result of a transfer of
bandwidth to the NAS that was carried out just before the incoming
Bandwidth Transfer message was processed.
If the AN receives an invalid Delegated Bandwidth Query Request The two Code values indicate a race condition where the AN may
message, it MUST return a Multicast Status message with the Result have just completed a transfer of bandwidth to the NAS. As a
field in the header set to Failure (0x4). The following cases may result, the value given in the Bandwidth Transfer message may be
occur: outdated, and the AN needs to query the NAS to find its latest
view. The procedure assumes that ordering is preserved between
the Bandwidth Transfer message sent by the AN in response to the
NAS's request and the subsequent Delegated Bandwidth Query Request
message.
o if the Target is invalid, the Status-Info TLV contains the If as the result of the procedures just described the AN determines
following values: that it has over-committed multicast bandwidth, it MUST NOT terminate
any currently-active programs, but MUST NOT honour any more "join"
requests until it is possible to do so within the limit set by its
current value of delegated bandwidth.
Result Code = unrecognized target (0x04); 4.7. Delegated Bandwidth Query Request Message
Command Number = the order of the invalid Target TLV within the The Message Type for the Delegated Bandwidth Query Request (and
request, numbering from 1 for the first one listed; Response) messages is 0x96.
Error Message Length = 0x0 (or optionally the length of an The Delegated Bandwidth Query Request message MAY be sent either by
error message, padded to a four-octet boundary); the NAS or by the AN to retrieve the peer's view of the amount of
delegated bandwidth. The request contains one TLV:
Error Message (optional text); o a Target TLV designating the access line for which the information
is requested.
the invalid Target TLV, copied from the Delegated Bandwidth 4.7.1. Sender Behaviour
Query Request message.
o if bandwidth delegation is not activated on the AN, the Status- The sender MUST set the Result field in the header of the Delegated
Info TLV contains the following values: Bandwidth Query Request message to AckAll (0x2). The Code value MUST
be set to 0x000. 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-protocol].
Result Code = bandwidth delegation not activated (0x12); 4.7.2. Receiver Behaviour
Command Number = 0x1; If the AN or NAS receives a valid Delegated Bandwidth Query Request
message, it MUST respond with a Delegated Bandwidth Query Response
message. The Result field in the header of the response MUST be set
to Success (0x3). The Code field MUST be set to 0x000. The
Transaction-Id field MUST be copied from the request message. The
body of the response MUST contain the Target TLV, copied from the
request message. Finally, the body of the response MUST contain a
Bandwidth-Allocation TLV, containing the current amount of delegated
bandwidth from the point of view of the receiver of the request.
Error Message Length = 0x0 (or optionally the length of an If the contents of the Delegated Bandwidth Query Request message are
error message, padded to a four-octet boundary); in error, the receiver MUST return a Delegated Bandwidth Query
Response message with the Result field in the header set to Failure
(0x3). The Code field MUST be set to the value that indicates the
nature of the error (e.g., 0x004 "Unrecognized target"). The
Transaction-Id field MUST be copied from the request. The body of
the response MUST contain the Target TLV copied from the request.
This MAY be followed by a Status-Info TLV giving further infromation
about the error.
Error Message (optional text). 4.8. Delegated Bandwidth Query Response Message
The AN MUST respond to a valid request with a Delegated Bandwidth The Delegated Bandwidth Query Response message is sent in reply to a
Query Response. The Result field in the header of this message MUST Delegated Bandwidth Query Request. The response to a valid request
be set to Success (0x3). This message contains the following TLVs: contains two TLVs:
o the Target TLV, copied from the request; o the Target TLV, copied from the request;
o one instance of the Bandwidth-Status TLV (Section 5.5) for each o a Bandwidth-Allocation TLV, giving the responder's view of the
access line designated in the Target TLV. The instances MUST have current amount of multicast bandwidth delegated to the AN.
the same order in the response as the corresponding access lines
in the Target TLV.
[Editor's Note: the base protocol draft is incomplete regarding the The Message Type for the Delegated Bandwidth Query Response message
specification of multiple access lines in the Target TLV.] is 0x96.
4.8.1. Sender Behaviour
Sender behaviour for the Delegated Bandwidth Query Response message
is specified in Section 4.7.2.
4.8.2. Receiver Behaviour
If the Delegated Bandwidth Query Response message indicates Success
(0x3), the following actions apply.
4.8.2.1. Behaviour at the NAS
If the amount of delegated bandwidth provided in the Bandwidth-
Allocation TLV is less than the NAS's view of the current amount of
delegated bandwidth, the NAS MUST update its view of the current
amount of delegated bandwidth to the amount indicated in the
Delegated Bandwidth Query Response message.
If the amount of delegated bandwidth provided in the Bandwidth-
Allocation TLV is greater than the NAS's view of the current amount
of delegated bandwidth, the NAS MAY accept the given value as its new
value of delegated bandwidth. Alternatively, the NAS MAY force the
AN to modify its view of the amount of delegated bandwidth to that
held by the NAS, by sending a Port Management message for the target
access line concerned, containing a Bandwidth-Allocation TLV with a
value equal to the amount of delegated bandwidth the NAS wishes to
enforce.
4.8.2.2. Behaviour at the AN
The AN SHOULD accept the value returned in the Bandwidth- Allocation
TLV of the Delegated Bandwidth Query Response message as the correct
value of the current amount of delegated bandwidth. If the AN has
currently committed more than this amount to active programs, it MUST
NOT cease replicating the flows concerned, but MUST NOT honour any
more Join requests until possible to do so within the new limit.
A race condition is possible, where the AN sends a query, the NAS
requests more bandwidth, then receives and responds to the query,
then receives the Bandwidth Transfer message responding to its
request. It is up to the AN to take appropriate action in this
case. The best action appears to be not to act on the result of
the first query, but to repeat the query after sending the
Bandwidth Transfer message. Similar considerations apply to a
race between queries from both sides.
4.9. Multicast Flow Query Request and Response Messages 4.9. Multicast Flow Query Request and Response Messages
This section defines two new messages called the Multicast Flow Query This section defines two new messages called the Multicast Flow Query
Request and Multicast Flow Query Response. The Multicast Flow Query Request and Multicast Flow Query Response. The Multicast Flow Query
Request is sent by the NAS to request information about the multicast Request is sent by the NAS to request information about the multicast
flows that are active on the AN. The Multicast Flow Query Response flows that are active on the AN. The Multicast Flow Query Response
is sent in response by the AN to provide the requested information to is sent in response by the AN to provide the requested information to
the NAS. the NAS.
The Message Type for the Multicast Flow Query Request and Multicast The Message Type for the Multicast Flow Query Request and Multicast
Flow Query Response messages is 0x97. The sender of a Multicast Flow Flow Query Response messages is 0x97.
Query Request and Multicast Flow Query Response message MUST set the
Result field to "0x00" meaning "Ignore".
The Multicast Flow Query Request message MAY be sent by the NAS to The contents of the Multicast Flow Query Request and Response depend
retrieve the AN's view of which multicast flows are currently active on the nature of the query, as described below.
on one (or multiple) given port(s) of the AN. In that case, the
Multicast Flow Query Request payload MUST contain the following TLVs:
o Target TLV. It MUST appear at least once. Each occurence 4.9.1. Sender Behaviour
identifies one AN port for which information on active multicast
flows is queried. It is encoded as specified in
[I-D.ietf-ancp-protocol].
The Multicast Flow Query Request message MAY be sent by the NAS to The sender of a Multicast Flow Query Request message MUST set the
retrieve the AN's view of which ports one (or multiple) given Result field to AckAll (0x2). The Code field MUST be set to 0x000.
multicast flow(s) is (are) currently active on. In that case, the The sender MUST populate the ANCP Transaction Identifier field with a
Multicast Flow Query Request payload MUST contain the following TLVs: unique value, as described in section 5.4.5 of [I-D.ietf-ancp-
protocol].
o Multicast-Flow TLV. It MUST appear at least once. Each occurence The Multicast Flow Query Request MAY be used by the NAS to retrieve:
identifies one multicast flow for which information is queried.
It is encoded as specified in Section 5.9.
The Multicast Flow Query Request message MAY be sent by the NAS to o the AN's view of which multicast flows are currently active on a
retrieve the AN's view of all the multicast flows currently active on specified set of access ports; or
each and every port of the AN. In that case, the Multicast Flow
Query Request payload MUST NOT contain the Target TLV nor the
Multicast-Flow TLV.
If the AN receives an invalid Multicast Flow Query Request message, o the AN's view of the access ports on which a specified set of
it MUST return a Multicast Status message with the Result field in multicast flows are currently active; or
the header set to Failure (0x4). The following cases may occur:
o if the Target is invalid, the Status-Info TLV contains the o the AN's view of all the multicast flows currently active on each
following values: and every port of the AN.
Result Code = unrecognized target (0x04); To retrieve the AN's view of which multicast flows are currently
Command Number = the order of the invalid Target TLV within the active on one (or multiple) given port(s) of the AN, the Multicast
request, numbering from 1 for the first one listed; Flow Query Request payload MUST contain the following TLVs:
Error Message Length = 0x0 (or optionally the length of an o Target TLV. It MUST appear at least once. Each occurence
error message, padded to a four-octet boundary); identifies one AN port for which information on active multicast
flows is queried. It is encoded as specified in
[I-D.ietf-ancp-protocol].
Error Message (optional text); To retrieve the AN's view of which ports one (or multiple) given
multicast flow(s) is (are) currently active on, the Multicast Flow
Query Request payload MUST contain the following TLVs:
the invalid Target TLV, copied from the Multicast Flow Query o Multicast-Flow TLV. It MUST appear at least once. Each occurence
Request message. identifies one multicast flow for which information is queried.
It is encoded as specified in Section 5.10.
o [Editor's note: if needed, add other error codes ???- eg if query To retrieve the AN's view of all the multicast flows currently active
contained both Target TLV and Multicast Flow TLV] on each port of the AN, the Multicast Flow Query Request payload MUST
NOT contain any instance of the Target TLV or the Multicast-Flow TLV.
The AN MUST respond to a valid Multicast Flow Query Request message 4.9.2. Receiver Behaviour
with a Multicast Flow Query Response message.
The AN MUST respond to a Multicast Flow Query Request message that
has a valid format and a valid content with a Multicast Flow Query
Response message. The Result field in the response MUST be set to
Success (0x3). The Code field MUST be set to 0x000. The
Transaction-Id field MUST be copied from the request.
If the Multicast Flow Query Request contained one (or more) Target If the Multicast Flow Query Request contained one (or more) Target
TLV, the AN MUST include, for each of these Target TLVs, the TLVs, the AN MUST include, for each of these Target TLVs, the
following set of TLVs: following set of TLVs:
o Target TLV. This MUST be identical to the Target TLV in the o Target TLV. This MUST be identical to the Target TLV in the
received Multicast Flow Query Request message. received Multicast Flow Query Request message.
o Multicast Flow TLV(s). The Multicast Flow TLV MUST appear once o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once
per Multicast Flow that is currently active on the AN port per multicast flow that is currently active on the AN port
identified in the preceding Target TLV. identified in the preceding Target TLV.
The Target TLVs MUST appear in the response from the AN in the same The Target TLVs MUST appear in the response from the AN in the same
order as in the query from the NAS. order as in the query from the NAS.
If the Multicast Flow Query Request contained one (or more) Multicast If the Multicast Flow Query Request contained one (or more)
Flow TLV, the AN MUST include, for each of these Multicast Flow TLVs, Multicast-Flow TLVs, the AN MUST include, for each of these
the following set of TLVs: Multicast-Flow TLVs, the following set of TLVs:
o Multicast Flow TLV.This MUST be identical to the Target TLV in the o Multicast-Flow TLV.This MUST be identical to the Target TLV in the
received Multicast Flow Query Request message. received Multicast Flow Query Request message.
o Target TLV(s). The Target TLV MUST appear once per AN port on o Target TLV(s). The Target TLV MUST appear once per AN port on
which the multicast flow identified in the preceding Multicast which the multicast flow identified in the preceding Multicast
Flow TLV is active. Flow TLV is active.
The Multicast Flow TLVs MUST appear in the response from the AN in The Multicast-Flow TLVs MUST appear in the response from the AN in
the same order as in the query from the NAS. the same order as in the query from the NAS.
If the Multicast Flow Query Request contained no Target TLV and no If the Multicast Flow Query Request contained no Target TLV and no
Multicast Flow TLV, the AN MUST include, for each and every AN port, Multicast Flow TLV, the AN MUST include, for each AN port, the
the following set of TLVs: following set of TLVs:
o Target TLV. This MUST identify one AN port. o Target TLV. This MUST identify one AN port.
o Multicast Flow TLV(s). The Multicast Flow TLV MUST appear once o Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once
per Multicast Flow that is currently active on the AN port per Multicast Flow that is currently active on the AN port
identified in the preceding Target TLV. identified in the preceding Target TLV.
4.10. Delegated Bandwidth Reset Procedure If the contents of the Multicast Flow Query Request are in error, the
AN MUST reply with a Multicast Flow Query Response message with the
As described above, the receiver of a Bandwidth Reallocation Request Result field set to Failure (0x4) and the Code field set to indicate
or Bandwidth Transfer message may determine that a bandwidth value in the nature of the error. If the request contained multiple instances
that message bears an incorrect relationship to its view of the of the Target TLV or the Multicast-Flow TLV and one of these is in
current amount of delegated bandwidth. The probable cause of this error, the response message MUST contain the results for the
condition is a discrepancy between its view and its peer's view of preceding instances of the TLV as if there had been no error. These
this amount. Upon detecting this condition, the receiver MAY choose successful results MUST be followed by the TLV in error, copied from
to initiate the reset procedure described in this section. If so, it the request. The AN MUST NOT do further processing of the request.
MUST send a Multicast Status message to its peer with the Result The AN MAY add a Status-Info TLV to provide further information on
field in the header set to Failure (0x4) and a Status-Info TLV the nature of the error.
containing the following values:
Result Code = delegated bandwidth reset required (0x13);
Command Number = 0x1;
Error Message Length = 0x0 (or optionally the length of an error
message, padded to a four-octet boundary);
Error Message (optional text);
the Target TLV, copied from the received message
an instance of the Bandwidth-Allocation TLV containing the
receiver's view of the current amount of delegated bandwidth.
Upon sending or receiving a Multicast Status message containing this
Result Code, the NAS MUST take the following actions:
1. halt processing of admission requests for the access line
indicated by the Target TLV until the reset procedure is
complete;
2. issue a Delegated Bandwidth Query request message to the AN to
determine the amount of bandwidth it has currently committed to
multicast usage, and its view of the amount of delegated
bandwidth;
3. based on the reply and possibly in consultation with the Policy
Server, apply policy to determine what the amount of delegated
bandwidth should be;
4. issue a Port Management message where the Access-Loop-Circuit-Id
TLV is derived from the Target TLV in the Multicast Status
message. The Port Management message MUST contain a Bandwidth-
Allocation TLV giving the decided amount of delegated bandwidth.
5. update its own view of the current amount of delegated bandwidth
to the decided amount.
At this point the reset procedure is complete and the NAS can resume
processing of admission requests for the affected access line.
Upon sending or receiving a Multicast Status message containing this
Result Code, the AN MUST take the following actions:
1. halt processing of admission requests for the access line
indicated by the Target TLV until the reset procedure is
complete;
2. wait for and respond to a Delegated Bandwidth Query request
message, indicating the amount of bandwidth it has currently
committed to multicast usage and its view of the amount of
delegated bandwidth;
3. wait for a Port Management message giving the decided amount of
delegated bandwidth for the access line concerned;
4. update its view of the current amount of delegated bandwidth to
the amount received in the Port Management message.
At this point the reset procedure is complete and the AN can resume
processing of admission requests for the affected access line.
5. ANCP TLVs and Sub-TLVs 5. ANCP TLVs and Sub-TLVs
This section defines new ANCP TLVs and sub-TLVs or extends existing This section defines new ANCP TLVs and sub-TLVs or extends existing
ones. ones.
5.1. Multicast-Service-Profile TLV 5.1. Multicast-Service-Profile TLV
This document defines the new Multicast-Service-Profile TLV. This document defines the new Multicast-Service-Profile TLV.
The Multicast-Service-Profile TLV MAY be included in a Provisioning The Multicast-Service-Profile TLV MAY be included in a Provisioning
message as specified in Section 4.1. message as specified in Section 4.1.
The Multicast-Service-Profile is illustrated in Figure 5: The Multicast-Service-Profile is illustrated in Figure 6. It
consists of a TLV header, a Multicast-Service-Profile-Name sub-TLV,
and one or more List-Action sub-TLVs. The sub-TLVs are packed
consecutively with no intervening padding.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Mcast Service Profile | TLV Length | |TLV Type = Mcast Service Profile | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Service-Profile-Name Sub-TLV | | Multicast-Service-Profile-Name Sub-TLV |
| Sub-TLV type = 0x0001 | | Sub-TLV type = 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| White-List Sub-TLV | | List-Action Sub-TLV |
| Sub-TLV type = 0x0002 | | Sub-TLV type = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Grey-List Sub-TLV | | ... |
| Sub-TLV type = 0x0003 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Black-List Sub-TLV | | List-Action Sub-TLV |
| Sub-TLV type = 0x0004 | | Sub-TLV type = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Multicast-Servive-Profile TLV Figure 6: Multicast-Servive-Profile TLV
Multicast Service Profile TLV Type: Multicast Service Profile TLV Type:
TLV (0x13) : indicating that this is a Multicast Service TLV (0x13) : indicating that this is a Multicast Service
Profile TLV Profile TLV
Each of the four sub-TLVs begins with a 32-bit header consisting of a The Multicast-Service-Profile-Name sub-TLV is shown in Figure 7. It
16-bit sub-TLV type code followed by a 16-bit length field giving the consists of an eight-bit sub-TLV identifier with value 0x01, an
amount of data following this sub-TLV header in octets. The type eight-bit length field, and an identifier. The length field gives
code values for the respective sub-TLVs are indicated in the figure. the length of the identifier in octets. The identifier consists of
The content of the sub-TLV follows immediately after the sub-TLV an opaque sequence of octets used to refer to the profile when
header. The sub-TLVs are placed into the list consecutively without activating it for a given target within a Port Management message
intervening padding. The Multicast Service Profile Name sub-TLV MUST (see Section 4.2). The identifier MUST be unique over all profiles
be present, and MUST be unique over all profiles provisioned to the provisioned to the same AN partition.
same AN partition. At least one other sub-TLV MUST be present, but
any of White List, Grey List, or Black List sub-TLV MAY be omitted if
not applicable to this profile.
The Multicast-Service-Profile-Name sub-TLV is an opaque sequence of 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
octets used to refer to the profile when activating it for a given +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
target within a Port Management message (see Section 4.2). | Type = 0x01 | Length | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The content of the White-List, Grey-List, and Black-List sub-TLVs Figure 7: Multicast-Service-Profile-Name sub-TLV
following their respective headers is in each case a sequence of
multicast flow fields organized by address family. IPv4 addresses The List-Action sub-TLV is shown in Figure 8. It consists of an
are listed first, followed by IPv6 addresses. Either set of eight-bit sub-TLV identifier with value 0x02, a four-bit action
addresses MAY be omitted if not applicable, but at least one set of field, a four-bit list type field, a sixteen-bit length, and a
addresses MUST be present. Figure 6 shows the detailed layout of a sequence of multicast flow fields organized by address family.
white, grey, or black list, where the detailed layout of an Either an IPv4 list or an IPv6 list or both MAY be present in the
individual multicast flow field is described below. The list length sub-TLV.
in Figure 6 is the number of octets of multicast flow field data for
that address family following the list header.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV tag = 0x0002,3,4 | Sub-TLV Length | | Type = 0x02 | Oper | LType | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Ver=0x0000 (IPv4) | List Length | | IP Version | List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields | | Multicast flow fields |
...... ......
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Ver=0x0001 (IPv6) | List Length | | IP Version | List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields | | Multicast flow fields |
...... ......
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Organization of a White, Grey, or Black List Figure 8: List-Action Sub-TLV
The fields within the List-Action TLV are defined as follows:
Type: always 0x02.
Oper: operation to be performed. The possible values are Add (0x1),
Delete (0x2), or Replace (0x3). The operation indicates whether
the listed multicast flows are to be added to the list identified
by the list type field within the profile identified by the
Multicast-Service-Profile-Name sub-TLV, deleted from that list, or
whether the listed flows should replace the current contents of
the identified list.
Ltype: the list type being modified by this list action. The
possible values are White (0x1), Black (0x2), or Grey (0x3).
Length: the length (in octets) of the contents of the List-Action
sub-TLV following the Length field itself.
IP Version: the IP version of the set of multicast flow fields that
follow. Possible values are 0x0000 (IPv4) or 0x0001 (IPv6). As
indicated above, either an IPv4 list or an IPv6 list or both MAY
be present in the sub-TLV.
List length: the length (in octets) of the list of multicast flow
fields following the list length field.
Multicast flow field: a field identifying one or more multicast
flows. It consists of an 8-bit group address prefix length, an
8-bit source address prefix length, a 0-16 octet group prefix, and
a 0-16 octet source prefix, as shown in Figure 9.
Each multicast flow field refers either to a Single Source Multicast Each multicast flow field refers either to a Single Source Multicast
(SSM) channel or to an Any Source Multicast (ASM) group. The scope (SSM) channel or to an Any Source Multicast (ASM) group. The scope
of the designation may be broadened to multiple channels or groups of the designation may be broadened to multiple channels or groups
through use of prefix length values smaller than the total address through use of prefix length values smaller than the total address
length for the given address family. Multicast flow fields MUST be length for the given address family. Multicast flow fields MUST be
placed consecutively within the sub-TLV without intervening padding placed consecutively within the sub-TLV without intervening padding
except to round out individual addresses to the nearest octet except to round out individual addresses to the nearest octet
boundary. 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 7: 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 7: 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. A match to the multicast flow to 128 in the IPv6 sub-list.
specification is performed based on the prefix values only, ignoring
lower-order bits in the respective addresses.
A value of 0x00 for either the Group PrefLen (prefix length) or the A value of 0x00 for either the Group PrefLen (prefix length) or the
Source PrefLen indicates that any value of the corresponding address Source PrefLen indicates that any value of the corresponding address
will match (wild card). If the value 0x00 is provided for a will match (wild card). If the value 0x00 is provided for a
particular prefix length, the corresponding prefix MUST be omitted particular prefix length, the corresponding prefix MUST be omitted
from the field contents. In particular, a value of 0x00 for the from the field contents. In particular, a value of 0x00 for the
Source PrefLen indicates an ASM multicast entry, and the Source Source PrefLen indicates an ASM multicast entry, and the Source
Prefix will be absent. Prefix will be absent.
The length of a Source or Group Prefix field is equal to (PrefLen + The length of a Source or Group Prefix field is equal to (PrefLen +
7)/8 octets, truncated to the nearest integer. Unused bits at the 7)/8 octets, truncated to the nearest integer. Unused bits at the
end of the prefix MUST be set to zeroes. end of the prefix MUST be set to zeroes.
5.1.1. Profile Processing At the Access Node 5.2. Command Number TLV
When the AN receives an IGMP/MLD Join request, it first checks
whether the program limit for that subscriber has been exceeded. If
so, it discards the request. Otherwise its next step is to determine
whether the source and group of the request match a multicast flow
specification in the white list, the grey list, or the black list
according to the profile assigned to the access line.
If the requested multicast flow matches multiple lists associated
with the access line, then the most specific match will be considered
by the AN. If the most specific match occurs in multiple lists, the
Black list entry takes precedence over the Grey list, which takes
precedence over the White list. In this context, the most specific
match is defined as:
o first, most specific match on the multicast flow address (i.e. on
G of <S,G>)
o then, most specific match on the multicast source address (i.e. on
S of <S,G>)
If the requested multicast flow is not part of any list, the join
message SHOULD be discarded by the AN. This default behavior can
easily be changed by means of a "catch-all" statement in either the
White list or the Grey list. For instance, adding (<S=*,G=*>) in the
White List would make the default behavior to accept join messages
for a multicast flow that has no other match on any list.
If the requested multicast flow matches a flow in the black list, the
AN discards the Join request.
Otherwise, if bandwidth delegation is active for the access line, the
AN determines whether it has enough unused capacity out of the total
video bandwidth that has been delegated to it for multicast admission
control. If so, it does white or grey list processing as described
below. If there is not enough unused bandwidth, it MAY issue a
Bandwidth Reallocation Request message. The required bandwidth
amount in the Bandwidth-Request TLV MUST be large enough that if the
request is granted, there will be sufficient unused capacity to
accommodate the Join request. The AN MAY set the preferred amount in
the Bandwidth-Request TLV to the same value as the required amount,
or to some higher amount determined by configured policy. If the
request fails or if the AN does not choose to issue a Bandwidth
Reallocation Request (e.g., because another such request failed
recently), it does no further processing of the Join request.
If the bandwidth check succeeds or if bandwidth delegation is not
active, then:
o if the requested multicast flow matches a flow in the white list,
the AN MUST autonomously start replicating multicast traffic
according to the request;
o if the requested flow matches a flow in the grey list, the AN MUST
send a Multicast Admission Control message (Section 4.5) to the
NAS with the value of Command set to Add (0x01) and await the
Multicast Replication Control message (Section 4.3) which responds
to it. Note that, when bandwidth delegation is active, the AN
MUST NOT send the Multicast Admission Control message until it has
fully established that the bandwidth checks succeeds (either
because the AN has enough unused capacity in the delegated
bandwidth or because the AN requested and obtained the necessary
increased delegated bandwidth in a Bandwidth REallocation Response
from the NAS). When the Multicast ReplicationControl message
arrives, the AN MUST act according to its content. The AN MAY set
a timer after which it will take no further action on the Join
request and will ignore the Multicast Replication Control
response, if any.
[Editor's Note: for grey list requests, there is a currently
unfulfilled need to indicate to the NAS (or require the NAS to know)
whether admission control has been done at the AN. If so, the NAS
can skip the admission control step and just apply policy.]
When the AN receives a Leave request for an admitted flow, it halts
replication of the indicated channel to the access line concerned.
In the case of a grey list flow, it also notifies the NAS using the
Multicast Admission Control message with the Command TLV set to
Delete (0x03).
5.2. Bandwidth-Delegation-Control TLV
This document defines the new Bandwidth-Delegation-Control TLV.
The Bandwidth-Delegation-Control TLV MAY be included in a The Command Number TLV conveys the sequence number of a specific
Provisioning message as specified in Section 4.1. command within a Multicast Replication Control or Multicast Admission
Request message. Within this specification, the Command Number TLV
itself is used as a sub-TLV within a Status-Info TLV, in a Generic
Response reporting a failed command.
The Bandwidth-Delegation-Control is illustrated below: The Command TLV has the format shown in Figure 10. The sequnce
number field is the sequence number of a specific command within a
request, where numbering starts from 1 for the first command.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 = Band-Del-Control | TLV Length = 4 | |TLV Type = Command Number | TLV Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Bandwidth-Delegation-Control TLV Figure 10: Structure of the Command Number TLV
Bandwidth-Delegation-Control TLV Type:
TLV (0x14) : indicating that this is a Bandwidth-
Delegation-Control TLV
Bandwidth-Delegation-Control TLV Length:
Combined length in bytes of the data inside sub-TLV.
Excludes the sub-TLV Header.
E Flag::
When set to 0, indicates that Bandwidth Delegation is to be
disabled on the AN. When set to 1, indicates that
Bandwidth Delegation is to be enabled on the AN. When
Bandwidth Delegation is enabled, the AN MUST subject
multicast channels matching the White List or the Grey List
to admission control according to the Bandwidth Delegation
procedures defined in [I-D.ietf-ancp-framework].
If Bandwidth Delegation is enabled, the NAS SHOULD provision an
initial value for the amount of bandwidth delegated to the AN for
multicast admission control for each line, in a Port Management (Line
Configuration) message. An initial delegated amount MAY be
configured directly on the AN. A delegated bandwidth value received
in a Port Management message overrides any configured value. If no
value is configured and no value is provisioned by the NAS, the
default initial amount of delegated bandwidth is zero.
This implies that in the absence of provisioning or configuration,
the AN will issue a Bandwidth Reallocation Request message to the
NAS asking for multicast bandwidth, the first time it receives an
IGMP/MLD Join for the given line.
5.3. Bandwidth-Allocation TLV 5.3. 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 line, in kilobits per second. The TLV has the format for a given access line, in kilobits per second. The TLV has the
shown in Figure 8. format shown in Figure 11. The TLV Type for the Bandwidth-Allocation
TLV is 0x15.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 = Band-Alloc | TLV Length = 4 | |TLV Type = BW-Allocation | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount (kbits/s) | | Delegated amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: The Bandwidth-Allocation TLV Figure 11: The Bandwidth-Allocation TLV
Bandwidth-Allocationl TLV Type: 5.4. White-List-CAC TLV
TLV (0x15) : indicating that this is a Bandwidth-Allocation The White-List-CAC TLV is used to indicate that the NAS wishes the AN
TLV to do admission control for White-listed flows. Details on when the
White-List-CAC TLV may be provisioned are specified in Section 6.
5.4. Bandwidth-Request TLV The White-List-CAC TLV contains no data, thus its TLV Length field
MUST have value 0.
5.5. MRepCtl-CAC TLV
The MRepCtl-CAC TLV is used to indicate that the NAS wishes the AN to
do admission control for flows added by the Multicast Replication
Control message. Details on when the MRepCtl-CAC TLV may be
provisioned are specified in Section 6.
The MRepCtl-CAC TLV contains no data, thus its TLV Length field MUST
have value 0.
5.6. 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 delegated 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.6 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 delegated to the AN. current values of total bandwidth allocated to the AN.
The Bandwidth-Request TLV has the format shown in Figure 9. The Bandwidth-Request TLV has the format shown in Figure 12. The TLV
Type for the Bandwidth-Request TLV is 0x16.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 = Band-Req | TLV Length = 8 | |TLV Type = 0x16 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required amount (kbits/s) | | Required amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred amount (kbits/s) | | Preferred amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The Bandwidth-Request TLV Figure 12: The Bandwidth-Request TLV
Bandwidth-Request TLV Type:
TLV (0x16) : indicating that this is a Bandwidth-Request
TLV
5.5. Bandwidth-Status TLV
The Bandwidth-Status TLV is used in the Delegated Bandwidth Query
Response to report the AN's view of the current amount of delegated
bandwidth and the amount of bandwidth within that quantity that is
already committed to active programs. The Bandwidth-Status TLV has
the format shown in Figure 10.
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 = Band-Status | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: The Bandwidth-Status TLV
Bandwidth-Status TLV Type:
TLV (0x17) : indicating that this is a Bandwidth-Status TLV
The committed amount SHOULD be less than or equal to the delegated
amount. One case where this may not be so is if the procedure
described in Section 4.10 has been performed and the NAS returned a
delegated amount lower than the current committed amount. Another
case might be if bandwidth delegation was activated after multicast
bandwidth had been allocated by other means. Obviously such cases
are exceptional and transient in nature.
5.6. Multicast-Service-Profile-Name TLV
[I-D.ietf-ancp-protocol] defines an Extension TLV that can be used in 5.7. Multicast-Service-Profile-Name TLV
ANCP messages. It also defines a number of TLVs that can be included
in the Extension TLV when present (with a Tech Type set to "DSL") in
a Port Management message (e.g. "Access-Loop-Circuit-ID", "Service-
Profile-Name").
This document defines an additional TLV that can appear in an The Multicast-Service-Profile-Name TLV carries the identifier of a
Extension TLV of Tech Type "DSL" in a Port Management message: multicast service profile provisioned on the AN.
o Type (Multicast-Service-Profile-Name = 0x18): Reference to a o Type (Multicast-Service-Profile-Name = 0x18): Reference to a
multicast service profile on the AN, that defines a <White List, multicast service profile on the AN, that defines a White, Black,
Black List, Grey List> triple. and/or Grey List depending on the set of negotiated capabilities.
Length : (up to 64 bytes) o Length : (up to 255 octets)
Value : ASCII string containing the multicast profile name. o Value : opaque sequence of octets identifying a specific profile.
This MUST match one of the multicast service profile names
provisioned on the AN in a Provisioning message or by other means.
5.7. Request-Source-IP sub-TLV 5.8. Request-Source-IP sub-TLV
[I-D.ietf-ancp-protocol] defines the Command TLV that can be used in [I-D.ietf-ancp-protocol] defines the Command TLV that can be used in
a Multicast Replication Control message and (as defined in this a Multicast Replication Control message and (as defined in this
document) in the Admission Control message. The Command TLV MAY document) in the Admission Control message. The Command TLV MAY
include sub-TLVs immediately following the Command Info field. include sub-TLVs immediately following the Command Info field.
This document defines the new Request-Source-IP sub-TLV. This document defines the new Request-Source-IP sub-TLV.
The Request-Source-IP sub-TLV MAY be included in a Command TLV inside The Request-Source-IP sub-TLV MAY be included in a Command TLV inside
an Admission Control message. an Admission Control message.
skipping to change at page 40, line 30 skipping to change at page 44, line 23
Excludes the sub-TLV Header. Excludes the sub-TLV Header.
Address Family, Encoding type and Unicast Address: Address Family, Encoding type and Unicast Address:
Contains the IP address of the sender of the join/leave Contains the IP address of the sender of the join/leave
message (e.g. IGMP/MLD Join/Leave) that triggered the AN message (e.g. IGMP/MLD Join/Leave) that triggered the AN
to include the corresponding Command TLV in an Admission to include the corresponding Command TLV in an Admission
Control message. The IP address is encoded as per Control message. The IP address is encoded as per
[IANAAEA]. [IANAAEA].
5.8. Request-Source-MAC sub-TLV 5.9. Request-Source-MAC sub-TLV
This document defines the new Request-Source-MAC sub-TLV. This document defines the new Request-Source-MAC sub-TLV.
The Request-Source-MAC sub-TLV MAY be included in a Command TLV The Request-Source-MAC sub-TLV MAY be included in a Command TLV
inside an Admission Control message. inside an Admission Control message.
The Request-Source-MAC sub-TLV is illustrated below: The Request-Source-MAC sub-TLV is illustrated below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 41, line 18 skipping to change at page 45, line 11
Excludes the sub-TLV Header. Excludes the sub-TLV Header.
TBD: TBD:
Contains the IEEE MAC address of the sender of the join/ Contains the IEEE MAC address of the sender of the join/
leave message (e.g. IGMP/MLD Join/Leave) that triggered leave message (e.g. IGMP/MLD Join/Leave) that triggered
the AN to include the corresponding Command TLV in an the AN to include the corresponding Command TLV in an
Admission Control message. The IP address is encoded as Admission Control message. The IP address is encoded as
per TBD. per TBD.
5.9. Multicast-Flow TLV 5.10. Multicast-Flow TLV
This document defines the new Multicast-Flow TLV. This document defines the new Multicast-Flow TLV.
The Multicast-Flow TLV MAY be included in a Multicast Flow Query The Multicast-Flow TLV MAY be included in a Multicast Flow Query
Request or Response message as specified in Section 4.9. Request or Response message as specified in Section 4.9.
The Multicast-Flow TLV is illustrated below: The Multicast-Flow TLV is illustrated below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Multicast Flow Source Address | | Addr Family | Encoding Type | Multicast Flow Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Flow Source Address (Ctnd) ... | | Multicast Flow Source Address (Cont'd) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Multicast Flow Group Address | | Addr Family | Encoding Type | Multicast Flow Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Flow Group Address (Ctnd) ... | | Multicast Flow Group Address (Cont'd) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding to 32-bit boundary | | ... | Padding to 32-bit boundary |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Multicast-Flow TLV Multicast-Flow TLV
Multicast-Flow TLV Type: Multicast-Flow TLV Type:
TLV (0x19) : indicating that this is a Multicast-Flow TLV TLV (0x19) : indicating that this is a Multicast-Flow TLV
Multicast-Flow TLV Length: Multicast-Flow TLV Length:
Length in bytes of the Value field of the TLV. Excludes Length in bytes of the Value field of the TLV. Excludes
the TLV Header (Type and Length). the TLV Header (Type and Length).
Addr Family, Encoding Type, Multicast Flow Source Address, Multicast Addr Family, Encoding Type, Multicast Flow Source Address, Multicast
Flow Group Address and Padding are encoded as specified for the Flow Group Address and Padding are encoded as specified for the
corresponding field of the Command TLV in Section 4.3. corresponding field of the Command TLV in Section 4.3.
6. New Capabilities 6. Multicast Capabilities
[I-D.ietf-ancp-protocol] defines a capability negotiation mechanism Section 5.3 of [I-D.ietf-ancp-protocol] defines a capability
as well as a number of capabilities. negotiation mechanism as well as a number of capabilities. This
section defines four new capabilities in support of different modes
of multicast operation:
This document defines the following generic Multicast Capability Type o NAS-initiated replication (capability type 0x05);
allowing negotiation of the level of subcapability within the
Multicast capability:
o Capability Type : Multicast = 0x03 o conditional access with white and black lists (capability type
0x06);
Length (in bytes) : 1 o conditional access with grey lists (capability type 0x07);
Capability Data (1 byte): The following values are defined: o bandwidth delegation (capability type 0x08).
+ 0x00: Reserved The "Capability Data" field within the Capability TLV for all of
these capabilities is empty.
+ 0x01: "Transactional Multicast" The remainder of this section consists of three sub-sections.
Section 6.1 specifies the protocol elements that must be implemented
in order to support each capability. Section 6.2 specifies the
procedures that apply to each capability on its own. Section 6.3
specifies how the capabilities interact if more than one multicast
capability is included in the set of capabilities negotiated between
the AN and the NAS.
+ 0x02: "Transactional Multicast" and "Multicast Admission Note that if a request contains content that is not supported
Control without Bandwidth Delegation" (according to the tables in Section 6.1) by the negotiated set of
multicast capabilities, the appropriate response is to return a
Generic Response message indicating Failure (0x4) with an appropriate
code value (e.g., 0x84 "TLV or value not supported by negotiated
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]
for more details.
+ 0x03: "Transactional Multicast", "Multicast Admission 6.1. Required Protocol Support
Control without Bandwidth Delegation" and "Multicast
Admission Control with Bandwidth Delegation"
+ other values: Reserved This section specifies the protocol elements that must be implemented
to support each of the four multicast capabilities. Support of
multiple multicast capabilities requires implementation of the union
of the sets of protocol elements applying to each of the individual
capabilities in the supported set.
Both the NAS and the AN MUST advertise the Multicast capability in 6.1.1. Protocol Requirements For NAS-initiated Replication
their originated adjacency messages when they support it. Initially,
they indicate the full set of multicast subcapabilities that they
respectively support by setting the Capability Value to the value
corresponding to their respective supported set of subcapabilities.
Then, if a received adjacency message indicates that the originating
device supports a smaller set of multicast subcapabilities that the
device receiving the message, the receiving device will turn off the
multicast subcapabilities that are not supported by the other device
and will send an updated adjacency message with an updated Capability
Value that now matches the one of the other device. This process
will eventually result in both sides agreeing on the common set of
supported multicast subcapabilities.
For example, if the NAS supports "Transactional Multicast" and Table 1 specifies the protocol elements within Section 4 and
"Multicast Admission Control without Bandwidth Delegation" while the Section 5 that must be implemented to support the NAS-initiated
AN only supports "Transactional Multicast", the NAS and AN will replication multicast capability.
initially advertise the Multicast capability with a respective
Capability Data of 0x02 and 0x01. On receipt of the adjacency
message from the AN, the NAS will turn off its "Multicast Admission
Control without Bandwidth Delegation" subcapability and will send a
new adjacency message with a Multicast capability containing a
Capability Data of 0x01. From there on, the NAS and AN agree to make
use of (only) the "Transactional Multicast" subcapability.
A NAS or AN supporting the "Transactional Multicast" subcapability +--------------+----------------------------------------------------+
MUST support the Multicast Replication message and the Multicast | Reference | Protocol Element |
Status message. +--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with MRepCtl_CAC TLV |
| | |
| Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV. |
| | |
| Section 4.3 | Multicast Replication Control message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.2 | Command Number TLV |
| | |
| Section 5.5 | MRepCtl-CAC TLV |
| | |
| Section 5.10 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
A NAS or AN supporting the "Transactional Multicast" and "Multicast Table 1: Protocol Support Requirements For NAS-initiated Replication
Admission Control without Bandwidth Delegation" subcapabilities MUST
support the Multicast Admission Control message, the Multicast
Replication message and the Multicast Status message.
A NAS or AN supporting the "Transactional Multicast", "Multicast 6.1.2. Protocol requirements For Conditional Access With White and
Admission Control without Bandwidth Delegation" and "Multicast Black Lists
Admission Control with Bandwidth Delegation" capability MUST support
the Multicast Admission Control message, the Multicast Replication Table 2 specifies the protocol elements within Section 4 and
message, the Multicast Status message, the Bandwidth Reallocation Section 5 that must be implemented to support the conditional access
Request and Response messages, the Autonomous Bandwidth Transfer with white and black lists multicast capability.
message and the Delegated Bandwidth Query Request and Response
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with |
| | Multicast-Service-Profile TLV, White and Black |
| | lists only, and White-List-CAC TLV |
| | |
| Section 4.2 | Port Management message with |
| | Multicast-Service-Profile-Name and |
| | Bandwidth-Allocation TLVs. |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.1 | Multicast-Service-Profile TLV, White and Black |
| | lists only |
| | |
| Section 5.3 | Bandwidth-Allocation TLV |
| | |
| Section 5.4 | White-List-CAC TLV |
| | |
| Section 5.7 | Multicast-Service-Profile-Name TLV |
| | |
| Section 5.10 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 2: Protocol Support Requirements For Conditional Access with
White and Black Lists
6.1.3. Protocol requirements For Conditional Access With Grey Lists
Table 3 specifies the protocol elements within Section 4 and
Section 5 that must be implemented to support the conditional access
with grey lists multicast capability.
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with |
| | Multicast-Service-Profile TLV, Grey lists only, |
| | and MRepCtl_CAC TLV |
| | |
| Section 4.2 | Port Management message with |
| | Multicast-Service-Profile-Name and |
| | Bandwidth-Allocation TLVs. |
| | |
| Section 4.3 | Multicast Replication Control message |
| | |
| Section 4.4 | Multicast Admission Control Message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.1 | Multicast-Service-Profile TLV, Grey lists only |
| | |
| Section 5.2 | Command Number TLV |
| | |
| Section 5.3 | Bandwidth-Allocation TLV |
| | |
| Section 5.5 | MRepCtl-CAC TLV |
| | |
| Section 5.7 | Multicast-Service-Profile-Name TLV |
| | |
| Section 5.8 | Request-Source-IP sub-TLV |
| | |
| Section 5.9 | Request-Source-MAC sub-TLV |
| | |
| Section 5.10 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 3: Protocol Support Requirements For Conditional Access with
Grey Lists
6.1.4. Protocol requirements For Delegated Bandwidth
Table 4 specifies the protocol elements within Section 4 and
Section 5 that must be implemented to support the delegated bandwidth
multicast capability.
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV. |
| | |
| Section 4.5 | Bandwidth Reallocation Request Message |
| | |
| Section 4.6 | Bandwidth Transfer Message |
| | |
| Section 4.7 | Delegated Bandwidth Query Request Message |
| | |
| Section 4.8 | Delegated Bandwidth Query Response Message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.3 | Bandwidth-Allocation TLV |
| | |
| Section 5.6 | Bandwidth-Request TLV |
| | |
| Section 5.10 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 4: Protocol Support Requirements For Delegated Bandwidth
6.2. Capability-Specific Procedures for Providing Multicast Service
This section describes multicast service procedures for each
capability as if it were the only multicast capability within the
negotiated set. Procedures involving combinations of multicast
capabilities are described in Section 6.3.
The use of the Multicast Flow Query Request and Response messages to
determine the association between multicast flows and ports is common
to all multicast capabilities. No additional text is required here,
beyond that already given in Section 4.9 to describe the use of those
messages. messages.
7. Example of Messages and Message Flows 6.2.1. Procedures For NAS-initiated Replication
NAS-initiated replication MAY be negotiated to support a mode of
operation where IGMP/MLD requests are terminated on the NAS.
Alternatively, it MAY be negotiated to allow the NAS to respond to
requests sent by other means (e.g., through application signalling)
that require the replication of multicast channels to a given access
line.
The NAS MAY enable admission control at the AN for Nas-initiated
replication. To do this, it MUST include the MRepCtl-CAC TLV in a
Provisioning message sent to the AN. It MUST also include a
Bandwidth-Allocation TLV in a Port Management message for each access
line.
The procedures associated with NAS-initiated replication are
straightforward. To initiate replication, the NAS MUST send a
Multicast Replication Control message to the AN, containing one or
more commands adding flows, as described in section ReplicSend. If
it does admission control itself, it MUST set the R flag in the Add
commands. If it has enabled admission control in the AN and wishes
the AN to perform admission control for the flows, it MUST clear the
R flag in the Command TLV requesting the flow addition. To terminate
replication the NAS MUST send a a Multicast Replication Control
message where the commands delete instead of adding them flows.
6.2.2. Procedures For Conditional Access With Black and White Lists
6.2.2.1. Provisioning
The NAS provisions named multicast service profiles containing White
and Black lists on the AN using the Provisioning message containing
one or more Multicast-Service-Profile TLVs. The NAS MAY update the
contents of these profiles from time to time as required, by sending
additional Provisioning messages with Multicast-Service-Profile TLVs
containing incremental modifications to the existing White and Black
lists or replacements for them.
The NAS assigns a specific multicast service profile to an individual
access line using the Port Management message containing a Multicast-
Service-Profile-Name TLV.
The NAS MAY choose to enable admission control at the AN for White-
listed flows. To do this, it MUST send a Provisioning message as
described in section provisioning, which includes the White-List-CAC
TLV. It MUST also provide a multicast bandwidth allocation for each
access line by including a Bandwidth-Allocation TLV in a Port
Management message.
6.2.2.2. Multicast Service Procedures
The conditional access with White and Black lists capability assumes
that IGMP/MLD requests are terminated on the AN. When the AN
receives a "join" request, it MUST check to see whether the requested
flow is White-listed or Black-listed as described below. Requests
for Black-listed flows MUST be discarded. If the NAS has enabled
admission control on the given access line as described in the
previous section, but the flow would cause the amount of committed
multicast bandwidth to exceed the provisioned limit, the request MUST
be discarded. Flows passing these checks are replicated to the
access line.
To determine if a requested flow is White-listed, the AN searches for
a best match to the flow in the applicable multicast service profile.
Matching is done on the prefixes specified in the profile, ignoring
the address bits of lower order than those in the prefix.
If the requested multicast flow matches multiple lists associated
with the access line, then the most specific match will be considered
by the AN. If the most specific match occurs in multiple lists, the
Black list entry takes precedence over the White list. In this
context, the most specific match is defined as:
o first, most specific match (longest prefix length) on the
multicast flow address (i.e., on G of <S,G>)
o then, most specific match (longest prefix length) on the multicast
source address (i.e. on S of <S,G>)
If the requested multicast flow is not part of any list, the join
message SHOULD be discarded by the AN. This default behavior can
easily be changed by means of a "catch-all" statement in the White
list. For instance, adding (<S=*,G=*>) in the White List would make
the default behavior to accept join messages for a multicast flow
that has no other match on any list.
When the AN receives a "leave" request, it terminates replication of
the multicast flow.
6.2.3. Procedures For Conditional Access With Grey Lists
6.2.3.1. Provisioning
The NAS provisions named multicast service profiles containing Grey
lists on the AN using the Provisioning message containing one or more
Multicast-Service-Profile TLVs. The NAS MAY update the contents of
these profiles from time to time as required, by sending additional
Provisioning messages with Multicast-Service-Profile TLVs containing
incremental modifications to the existing Grey lists or replacements
for them.
The NAS assigns a specific multicast service profile to an individual
access line using the Port Management message containing a Multicast-
Service-Profile-Name TLV.
The NAS can enable admission control at the AN for Grey-listed flows.
To do this, it MUST include the MRepCtl-CAC TLV in a Provisioning
message sent to the AN. It MUST also provide a Bandwidth-Allocation
TLV in a Port Management message for each access line.
6.2.3.2. Multicast Service Procedures
The conditional access with Grey lists capability assumes that IGMP/
MLD requests are terminated on the AN. When the AN receives a "join"
request, it MUST determine whether there is a match to the requested
flow in the Grey list of the multicast service profile provisioned
against the given access line. If there is no match, the request is
discarded. Otherwise, the AN MUST send a Multicast Admission Control
message to the NAS with content identifying the access line and the
multicast flow to be added. As indicated in Section 4.4, the AN MAY
add information identifying the requestor by IP address and/or MAC
address.
If the NAS decides to enable the flow, it MUST send a Multicast
Replication Control request to the AN to replicate the flow to the
access line with the Result field set to Nack (0x1), as described in
section ReplicSend. If admission control has been enabled at the AN
for flows added by Multicast Replication Control messages, the NAS
MAY invoke admission control for a specific flow at the AN by
clearing the R flag in the Command TLV that adds the flow.
When the AN receives the Multicast Replication Control request, it
performs admission control if admission control has been enabled and
invoked by the clearing of the R flag. If admitting the flow would
cause the committed multicast bandwidth at the access line to exceed
the provisioned limit, the AN reports an error to the NAS as
described in section ReplicRecv. Otherwise it replicates the
multicast flow as requested.
If the NAS decides not to permit the flow, it MAY send a Multicast
Replication Control message in response to the Multicast Admission
Control message to allow the AN to update its internal records. The
content of this message is described in Section 4.4.2.
When the AN receives a "leave" request, it MUST terminate replication
of the flow to the access line. It MUST then send a Multicast
Admission Control message to the NAS indicating the deletion. The
NAS updates its internal records but MUST NOT respond to the message.
6.2.4. Procedures For Delegated Bandwidth
6.2.4.1. Provisioning
The NAS SHOULD provision an initial amount of delegated multicast
bandwidth for each access line using the Port Management message
containing the Bandwidth-Allocation TLV. (If it fails to do so and a
value has not been provisioned on the AN by other means, the AN will
be forced to request a bandwidth allocation as soon as it receives a
"join" request.)
6.2.4.2. Multicast Service Procedures
The delegated bandwidth capability assumes that IGMP/MLD requests are
terminated on the AN. When the AN receives a "join" request, it
checks whether it has sufficient remaining uncommitted multicast
bandwidth on the access line to accommodate the new multicast flow.
If not, it MAY send a request to the NAS for an increased allocation
of delegated bandwidth, using the Bandwidth Reallocation Request
message. The NAS MUST return a Bandwidth Transfer message indicating
whether it has granted the request, and if so, what is the new amount
of delegated bandwidth.
If the AN has sufficient uncommitted multicast capacity to admit the
request, either originally or as the result of a successful request
to the NAS, it replicates the requested flow to the access line.
Otherwise it discards the request.
When the AN receives a "leave" request for an active flow, it ceases
replication.
The NAS or AN MAY at some point detect that their respective views of
the amount of delegated bandwidth are inconsistent. If so, they can
recover using procedures described in Section 4.5 and Section 4.6.
As a further aid to synchronization, either the NAS or the AN MAY
from time to time check the peer's view of the amount of delegated
bandwidth using the Delegated Bandwidth Query message.
The NAS or AN MAY at any time release bandwidth to the peer using an
autonomous Bandwidth Transfer message. The contents of this message
are described in Section 4.6.
6.3. Combinations of Multicast Capabilities
6.3.1. Combination of NAS-Initiated Replication with Other Capabilities
NAS-initiated replication can coexist with the other capabilities,
but some means must exist to prevent double replication of flows.
The simplest way to do this is to terminate all IGMP/MLD requests on
the AN, so that NAS-initiated replication is stimulated by signalling
through other channels. Other arrangements are possible, but need
not be discussed here.
Assuming the necessary separation of responsibilities, the only point
of interaction between NAS-initiated replication and the other
multicast capabilities is in the area of admission control.
Specifically, inclusion of the MRepCtl-CAC TLV in a Provisiong
message enables admission control for flows added by Multicast
Replication Control messages, regardless of whether they are part of
NAS-initiated replication or Grey list multicast service processing.
The NAS can control whether the AN does admission control for
individual flows by its setting or clearing of the R flag in the
Command TLV. It is up to the NAS to choose how video bandwidth will
be allocated between itself and the AN, and to choose which
allocation must support specific requests.
6.3.2. Conditional Access With White, Black, and Grey Lists
If conditional access with White and Black lists is combined with
conditional access with Grey lists, provisioning of the multicast
service profiles is as described in Section 6.2.2.1 except that
multicast service profiles will also include Grey lists. Admission
control is enabled independently for White lists by including the
White-list-CAC TLV in the Provisioning message and for Grey lists by
including the MRepCtl-CAC TLV in the Provisioning message. The
Bandwidth-Allocation TLV provisions an amount that applies to both
White- and Grey- listed flows if admission control is enabled for
both.
With regard to multicast service procedures, one point of difference
from the individual capabilities must be noted. This is an
interaction during the profile matching procedure. The AN MUST seek
the best match amongst multiple lists as described in
Section 6.2.2.2. However, if there are multiple matches of equal
precision, the order of priority is Black list first, Grey list
second, and White list last.
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
flows or Section 6.2.3.2 for Grey listed flows. Requests that do not
match any list SHOULD be discarded.
When the AN receives a "leave" request, it MUST terminate replication
of the flow to the access line. If the flow was Grey-listed, the AN
MUST then send a Multicast Admission Control message to the NAS
indicating the deletion. Thus the AN needs to retain the fact that
the flow was Grey-listed for the life of the flow.
6.3.3. Conditional Access Combined With Delegated Bandwidth
If either or both conditional access capabilities are combined with
the delegated bandwidth capability, the AN always does admission
control. Delegated bandwith simply provides a means for flexible
sharing of video bandwidth between the AN and the NAS or Policy
Server. The provisioning, admission, and bandwidth management
procedures of Section 6.2.4 apply in addition to the procedures in
Section 6.2.2, Section 6.2.3, or Section 6.3.2 as applicable.
7. Security Considerations
The security considerations of ANCP are discussed in
[I-D.ietf-ancp-protocol] and in [I-D.ietf-ancp-security-threats].
8. IANA Considerations
This document defines the following additional values within the
GSMPv3 Message Type Name Space registry:
+--------------------------------+--------+---------------+
| Message | Number | Source |
+--------------------------------+--------+---------------+
| Multicast Replication Control | 90 | This document |
| | | |
| Multicast Status | 91 | This document |
| | | |
| Multicast Admission Control | 92 | This document |
| | | |
| Bandwidth Reallocation Request | 94 | This document |
| | | |
| Bandwidth Transfer | 95 | This document |
| | | |
| Delegated Bandwidth Query | 96 | This document |
| | | |
| Multicast Flow Query | 97 | This document |
+--------------------------------+--------+---------------+
This document defines the following values for the ANCP Status-Info
Result Code Registry :
+----------------------------------------------+--------+-----------+
| Status | Number | Reference |
+----------------------------------------------+--------+-----------+
| Command not supported | 0x02 | This |
| | | document |
| | | |
| Flag set but not supported | 0x03 | This |
| | | document |
| | | |
| Unsupported Address Family | 0x05 | This |
| | | document |
| | | |
| Malformed flow address | 0x06 | This |
| | | document |
| | | |
| Configuration error (such as Port not | 0x0a | This |
| enabled for multicast) | | document |
| | | |
| Multicast flow does not exist | 0x0b | This |
| | | document |
| | | |
| Unsupported address encoding | 0x0c | This |
| | | document |
| | | |
| Additional info needed to execute command | 0x0d | This |
| (payload MAY contain an indication of the | | document |
| expected info) | | |
| | | |
| Multicast flow count exceeded | 0x0e | This |
| | | document |
| | | |
| M Flag set, but no IP Source address | 0x0f | This |
| provided | | document |
| | | |
| Invalid preferred bandwidth amount | 0x11 | This |
| | | document |
| | | |
| bandwidth delegation not activated | 0x12 | This |
| | | document |
| | | |
| Delegated bandwidth reset required | 0x13 | This |
| | | document |
+----------------------------------------------+--------+-----------+
This document defines the following additional values within the ANCP
TLV Type Registry:
+--------------------------------+-----------+---------------+
| TLV Name | Type Code | Reference |
+--------------------------------+-----------+---------------+
| Multicast-Service-Profile | 0x13 | This document |
| | | |
| Bandwidth-Delegation-Control | 0x14 | This document |
| | | |
| Bandwidth-Allocation | 0x15 | This document |
| | | |
| Bandwidth-Request | 0x16 | This document |
| | | |
| Bandwidth-Status | 0x17 | This document |
| | | |
| Multicast-Service-Profile-Name | 0x18 | This document |
| | | |
| Multicast-Flow | 0x19 | This document |
+--------------------------------+-----------+---------------+
This document defines the following values for the ANCP Command Code
registry:
+-------------------------------------+----------------+------------+
| Command Code Directive Name | Command Code | Reference |
| | Value | |
+-------------------------------------+----------------+------------+
| Add | 0x01 | This |
| | | document |
| | | |
| Delete | 0x02 | This |
| | | document |
| | | |
| Delete All | 0x03 | This |
| | | document |
| | | |
| Admission Control Reject | 0x04 | This |
| | | document |
| | | |
| Conditional Access Reject | 0x05 | This |
| | | document |
| | | |
| Admission Control and Conditional | 0x06 | This |
| Access Reject | | document |
+-------------------------------------+----------------+------------+
This document defines the following additional values to the ANCP
sub-TLV Type registry:
+--------------------+-----------+---------------+
| sub-TLV Name | Type Code | Reference |
+--------------------+-----------+---------------+
| Request-Source-IP | 0x92 | This document |
| | | |
| Request-Source-MAC | 0x93 | This document |
+--------------------+-----------+---------------+
9. Acknowledgements
The authors would like to acknowledge Wojciech Dec for providing
useful input to this document, Robert Rennison for his help in
shaping the definition of the Multicast-Service-Profile TLV, Shridhar
Rao for his comments and suggestions and Aniruddha A for his proposal
that formed the base of the Multicast Flow Reporting solution.
Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided
substantial contributions on the solution for the NAS initiated
multicast control use case.
10. 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-12 (work in progress),
October 2009.
[I-D.ietf-ancp-protocol]
Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., Voigt,
N., and R. Maglione, "Protocol for Access Node Control
Mechanism in Broadband Networks",
draft-ietf-ancp-protocol-07 (work in progress),
October 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
10.2. Informative References
[I-D.ietf-ancp-security-threats]
Moustafa, H., Tschofenig, H., and S. Cnodder, "Security
Threats and Security Requirements for the Access Node
Control Protocol (ANCP)",
draft-ietf-ancp-security-threats-08 (work in progress),
July 2009.
[I-D.morin-mboned-igmpmld-error-feedback]
Morin, T. and B. Haberman, "IGMP/MLD Error Feedback",
draft-morin-mboned-igmpmld-error-feedback-02 (work in
progress), November 2008.
[IANAAEA] "http://www.iana.org/assignments/address-family-numbers",
2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
Appendix A. Example of Messages and Message Flows
This section provides example message flows. This section provides example message flows.
7.1. Multicast Conditional Access and CAC without AN Bandwidth A.1. Multicast Conditional Access and CAC without AN bandwidth
Delegation delegation
This section describes ANCP operations when multicast flows are This section describes ANCP operations when multicast flows are
subject to multicast Conditional Access and Admission Control without subject to multicast Conditional Access and Admission Control without
Bandwidth Delegation. bandwidth delegation.
7.1.1. List/Profile Provisioning A.1.1. List/Profile Provisioning
The AN provisioning is performed by NAS using a Provisioning message The AN provisioning is performed by NAS using a Provisioning message
that contains White/Black/Grey lists and their corresponding that contains White/Black/Grey lists and their corresponding
"Multicast Service Profile Name". To indicate to the AN that it need "Multicast Service Profile Name". To indicate to the AN that it need
not perform any CAC operation on those flows, the Provisioning not perform any CAC operation on those flows, the Provisioning
message also conveys an indication that Bandwidth Delegation is to be message also conveys an indication that bandwidth delegation is to be
deactivated. The corresponding message flow is illustrated in deactivated. The corresponding message flow is illustrated in
Figure 11. Figure 13.
+----------+ +---------+ +-----+ +-----+ +----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS | |Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+ +----------+ | Gateway | +-----+ +-----+
| +---------+ | | | +---------+ | |
| | | | | | | |
| | |(M1) Provisioning | | | |(M1) Provisioning |
| | | (Mcast S Prof name, | | | | (Mcast S Prof name, |
| | | White List, | | | | White List, |
| | | Grey List, | | | | Grey List, |
| | | Black List, | | | | Black List, |
| | | Bw Del Deactivated) | | | | Bw Del Deactivated) |
| | |<--------------------| | | |<--------------------|
Figure 11: Provisioning AN with White/Grey/Black Lists for Figure 13: Provisioning AN with White/Grey/Black Lists for
Conditional Access Conditional Access
The Provisioning message M1 contains: The Provisioning message M1 contains:
o an ANCP Header with: o an ANCP Header with:
* Message-Type = 93 - Provisioning * Message-Type = 93 - Provisioning
* Result= 0x00 * Result= 0x00
skipping to change at page 46, line 45 skipping to change at page 66, line 45
~ Multicast service profile name ~ ~ Multicast service profile name ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLV Type = 0x0003 | sub-TLV Length = 0x06 | | sub-TLV Type = 0x0003 | sub-TLV Length = 0x06 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP ver = 0x00 | List length = 0x02 | | IP ver = 0x00 | List length = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Grp PLen=0x00 | Src PLen=0x00 | | Grp PLen=0x00 | Src PLen=0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12 Figure 14
7.1.2. Profile Mapping A.1.2. Profile Mapping
As soon as the AN port comes up, the AN sends an ANCP PORT_UP message As soon as the AN port comes up, the AN sends an ANCP PORT_UP message
to the NAS specifying the Access Loop Circuit ID. The NAS replies to the NAS specifying the Access Loop Circuit ID. The NAS replies
with an ANCP PORT_MNGT message that, together with the other with an ANCP PORT_MNGT message that, together with the other
parameters, includes the Multicast Service Profile Name to be parameters, includes the Multicast Service Profile Name to be
associated to that Port. The corresponding message flow is associated to that Port. The corresponding message flow is
illustrated in Figure 13. illustrated in Figure 15.
+----------+ +---------+ +-----+ +-----+ +----------+ +---------+ +-----+ +-----+
|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)|
| | |<--------------------| | | |<--------------------|
(*) 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 13: Associating Profile ID to AN Port Figure 15: Associating Profile ID to AN Port
7.1.3. Successful Join/Leave Operations A.1.3. Successful Join/Leave Operations
The message flows in Figure 14 illustrates the ANCP message flow in The message flows in Figure 16 illustrates the ANCP message flow in
case of a simple join and leave for a multicast flow that matches the case of a simple join and leave for a multicast flow that matches the
grey list and when the "Bandwidth Delegation" mechanism is not grey list and when the "bandwidth delegation" mechanism is not
activated in the AN. In that case the AN queries the NAS that activated in the AN. In that case the AN queries the NAS that
performs Conditional Access and Admission Control. performs Conditional Access and Admission Control.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS | |Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | | | | | |
| Join(Grey-Fl) | Admission | | Join(Grey-Fl) | Admission |
|-----------+---------->| Control (M1) | |-----------+---------->| Control (M1) |
skipping to change at page 48, line 28 skipping to change at page 68, line 28
|<======================+ | |<======================+ |
| | | | | | | |
~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | |
| Leave(Grey-Fl) | Admission | | Leave(Grey-Fl) | Admission |
|-----------+---------->| Control (M3) | |-----------+---------->| Control (M3) |
| | |------------------>| | | |------------------>|
| | | | | | | |
Grey-Fl : Multicast Flow matching an entry in Grey List Grey-Fl : Multicast Flow matching an entry in Grey List
(Bandwidth Delegation not activated on AN) (bandwidth delegation not activated on AN)
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Autorization/Policy Server Autorization/Policy Server
Figure 14: Successful Join/Leave Operations Figure 16: Successful Join/Leave Operations
The Multicast Admission Control message M1 contains: The Multicast Admission Control message M1 contains:
o an ANCP Header with: o an ANCP Header with:
* Message-Type = 92 - Multicast Admission Control * Message-Type = 92 - Multicast Admission Control
* Result= 0x00 * Result= 0x00
* Transaction-ID = Transaction-ID maintained by AN * Transaction-ID = Transaction-ID maintained by AN
skipping to change at page 53, line 38 skipping to change at page 73, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 | | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = 0xTBD (Request-S.) TLV | Request-S.-TLV Length | |Type = 0xTBD (Request-S.) TLV | Request-S.-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
7.1.4. Admission Control Reject without NAS Response A.1.4. Admission Control Reject without NAS Response
The message flow in Figure 15 illustrates the ANCP message flow in The message flow in Figure 17 illustrates the ANCP message flow in
case of a join that is rejected by the NAS because of admission case of a join that is rejected by the NAS because of admission
control and without explicit response from the NAS. In that case, control and without explicit response from the NAS. In that case,
the multicast flow is never replicated simply by virtue of the NAS the multicast flow is never replicated simply by virtue of the NAS
not requesting replication. not requesting replication.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS | |Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | | | | | |
skipping to change at page 54, line 21 skipping to change at page 74, line 21
|-----------+---------->| Control (M1) | |-----------+---------->| Control (M1) |
| | |------------------>| | | |------------------>|
| | | | | | | |
| | | (*) | | | (*)
| | | | | | | |
| Mcast Grey Flow | | | Mcast Grey Flow | |
| not replicated x | | not replicated x |
| | | | | | | |
Grey-Fl : Multicast Flow matching an entry in Grey List Grey-Fl : Multicast Flow matching an entry in Grey List
(Bandwidth Delegation not activated on AN) (bandwidth delegation not activated on AN)
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Autorization/Policy Server Autorization/Policy Server
Figure 15: Admission Control Reject without NAS Response Figure 17: Admission Control Reject without NAS Response
The Multicast Admission Control message M1 contains: The Multicast Admission Control message M1 contains:
o an ANCP Header with: o an ANCP Header with:
* Message-Type = 92 - Multicast Admission Control * Message-Type = 92 - Multicast Admission Control
* Result= 0x00 * Result= 0x00
* Transaction-ID = Transaction-ID maintained by AN * Transaction-ID = Transaction-ID maintained by AN
skipping to change at page 55, line 41 skipping to change at page 75, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.3 | | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
7.1.5. Admission Control Reject with NAS Response A.1.5. Admission Control Reject with NAS Response
The message flow in Figure 16 illustrates the ANCP message flow in The message flow in Figure 18 illustrates the ANCP message flow in
case of a join that is rejected by the NAS because of admission case of a join that is rejected by the NAS because of admission
control and with explicit response from the NAS. In that case, the control and with explicit response from the NAS. In that case, the
multicast flow is not replicated by virtue of the NAS explicitely multicast flow is not replicated by virtue of the NAS explicitely
signaling to the AN that the multicast flow is not to be replicated. signaling to the AN that the multicast flow is not to be replicated.
+----------+ +-------+ +-----+ ANCP +-----+ +----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS | |Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+ +----------+ |Gateway| +-----+ +-----+
| +-------+ | | | +-------+ | |
| | | | | | | |
skipping to change at page 56, line 22 skipping to change at page 76, line 22
| | |------------------>| | | |------------------>|
| | | | | | | |
| | | Multicast (*) | | | Multicast (*)
| | | Replication | | | | Replication |
| | | Control (M2) | | | | Control (M2) |
| Mcast Grey Flow |<------------------| | Mcast Grey Flow |<------------------|
| not replicated x | | not replicated x |
| | | | | | | |
Grey-Fl : Multicast Flow matching an entry in Grey List Grey-Fl : Multicast Flow matching an entry in Grey List
(Bandwidth Delegation not activated on AN) (bandwidth delegation not activated on AN)
(*) The NAS may optionally seek direction from an external (*) The NAS may optionally seek direction from an external
Autorization/Policy Server Autorization/Policy Server
Figure 16: Admission Control Reject with NAS Response Figure 18: Admission Control Reject with NAS Response
The Multicast Admission Control message M1 contains: The Multicast Admission Control message M1 contains:
o an ANCP Header with: o an ANCP Header with:
* Message-Type = 92 - Multicast Admission Control * Message-Type = 92 - Multicast Admission Control
* Result= 0x00 * Result= 0x00
* Transaction-ID = Transaction-ID maintained by AN * Transaction-ID = Transaction-ID maintained by AN
skipping to change at page 59, line 36 skipping to change at page 79, line 36
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length | |Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 | | AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
7.2. Example Flows For Bandwidth Delegation A.2. Example Flows For bandwidth delegation
As noted in Section 5.1.1, the operation of bandwidth delegation is As noted in TBD, the operation of bandwidth delegation is
supplemental to the operation of request processing in the absence of supplemental to the operation of request processing in the absence of
bandwidth delegation. Thus the same flows shown in the previous bandwidth delegation. Thus the same flows shown in the previous
section continue to hold, except that the AN does multicast call section continue to hold, except that the AN does multicast call
admission before doing grey and white list processing. The example admission before doing grey and white list processing. The example
flows of this section are therefore limited to the incremental flows of this section are therefore limited to the incremental
operations of bandwidth delegation. They include initial operations of bandwidth delegation. They include initial
provisioning, a successful request from the AN for an increase in provisioning, a successful request from the AN for an increase in
delegated bandwidth, an autonomous transfer of the borrowed bandwidth total multicast bandwidth, an autonomous transfer of the borrowed
back to the NAS, and the initiation of the bandwidth reset procedure bandwidth back to the NAS, and the initiation of the bandwidth reset
(Section 4.10) by the NAS when it finds that the amount of delegated procedure [text to be modified] by the NAS when it finds that the
bandwidth passed by the AN is larger than its current view of that amount of total multicast bandwidth passed by the AN is larger than
amount. its current view of that amount.
7.2.1. Activation and Provisioning of Delegated Bandwidth A.2.1. Activation and Provisioning of total multicast Bandwidth
Activation of bandwidth delegation occurs at the level of the AN as a Activation of bandwidth delegation occurs at the level of the AN as a
whole and is done by including a Bandwidth-Delegation-Control TLV in whole and is done by including a Bandwidth-Delegation-Control TLV in
the Provisioning message with the E-flag set to 1. The message flow the Provisioning message with the E-flag set to 1. The message flow
is as shown in Figure 11. In place of Figure 12 we have the is as shown in Figure 13. In place of Figure 14 we have the
following content within the Provisioning message: following content within the Provisioning 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length | | Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=93 | 0x00 | Code | | Vers | Sub |MessageType=93 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0008 | | Partition ID | Transaction Identifier = 0008 |
skipping to change at page 60, line 43 skipping to change at page 80, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP ver = 0x00 | List length = 0x02 | | IP ver = 0x00 | List length = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Grp PLen=0x00 | Src PLen=0x00 | Padding = 0x00 | | Grp PLen=0x00 | Src PLen=0x00 | Padding = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Band-Del-Control | TLV Length = 0x04 | | TLV Type = Band-Del-Control | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Reserved = 0x00 | Reserved = 0x00 | |E| Reserved = 0x00 | Reserved = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17 Figure 19
Once bandwidth delegation has been activated, the NAS must provision Once bandwidth delegation has been activated, the NAS must provision
the amount of delegated bandwidth for each access line (unless it is the amount of total multicast bandwidth for each access line (unless
pre-configured on the AN). This requires a Port Management message it is pre-configured on the AN). This requires a Port Management
with a Bandwidth-Allocation TLV. The same Port Management message message with a Bandwidth-Allocation TLV. The same Port Management
may be used to provision other information, such as the multicast message may be used to provision other information, such as the
service profile name applicable to the access line. The information multicast service profile name applicable to the access line. The
flow is therefore similar to that in Figure 13. In the following information flow is therefore similar to that in Figure 15. In the
figure, an initial allocation of 8000 kbits/s is provided. following figure, an initial allocation of 8000 kbits/s is provided.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type = 32 |Rslt =1| Code = 0 | | Vers | Sub | Msg Type = 32 |Rslt =1| Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 61, line 39 skipping to change at page 81, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Access-Loop-Circuit-ID ~ ~ Access-Loop-Circuit-ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Bandwidth-Alloc | TLV length = 4 | | TLV Type = Bandwidth-Alloc | TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount = 8000 | | Delegated amount = 8000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Port Management Message Allocating Delegated Bandwidth Figure 20: Port Management Message Allocating total multicast
Bandwidth
7.2.2. Successful Request For More Delegated Bandwidth A.2.2. Successful Request For More Multicast Bandwidth
Suppose that the AN allocates all 8000 kbits/s of its delegated Suppose that the AN allocates all 8000 kbits/s of its total multicast
amount and receives a Join request requiring another 2000 kbits/s. amount and receives a Join request requiring another 2000 kbits/s.
The AN issues a Bandwidth Reallocation Request message where the The AN issues a Bandwidth Reallocation Request message where the
required amount field is set to acquire this amount of additional required amount field is set to acquire this amount of additional
bandwidth. Since the request is framed in terms of total delegated bandwidth. Since the request is framed in terms of total total
bandwidth, required amount is 10000 kbits/s. Suppose that the AN is multicast bandwidth, required amount is 10000 kbits/s. Suppose that
configured with a policy that causes it to request enough for one the AN is configured with a policy that causes it to request enough
additional channel as a preferred amount. Hence the preferred amount for one additional channel as a preferred amount. Hence the
is set to 12000 kbits/s. The Bandwidth Reallocation Request message preferred amount is set to 12000 kbits/s. The Bandwidth Reallocation
has the following format: Request message has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | MsgTyp = 94 |Rslt=0 | Code = 0 | | Vers | Sub | MsgTyp = 94 |Rslt=0 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 62, line 29 skipping to change at page 82, line 30
~ Access Loop Circuit ID ~ ~ Access Loop Circuit ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Request | TLV Length = 8 | |TLV Type = Bandwidth-Request | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required amount = 10000 | | Required amount = 10000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred amount = 12000 | | Preferred amount = 12000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Example Bandwidth Reallocation Request Message Figure 21: Example Bandwidth Reallocation Request Message
In response to this request, the NAS is willing to grant the full In response to this request, the NAS is willing to grant the full
preferred amount. (It could have granted any value between 10000 and preferred amount. (It could have granted any value between 10000 and
12000, or it could have rejected the request.) The Bandwidth 12000, or it could have rejected the request.) The Bandwidth
Transfer message sent as a response indicates that the new delegated Transfer message sent as a response indicates that the new total
bandwidth amount is 12000 kbits/s, as shown in the next figure. multicast bandwidth amount is 12000 kbits/s, as shown in the next
figure.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | MsgTyp = 95 |Rslt=3 | Code = 0 | | Vers | Sub | MsgTyp = 95 |Rslt=3 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 63, line 27 skipping to change at page 83, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Access Loop Circuit ID ~ ~ Access Loop Circuit ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Alloc | TLV Length = 4 | |TLV Type = Bandwidth-Alloc | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount = 12000 | | Delegated amount = 12000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Example Bandwidth Transfer Message (Success Response) Figure 22: Example Bandwidth Transfer Message (Success Response)
7.2.3. Failed Autonomous Transfer With Reset A.2.3. Failed Autonomous Transfer With Reset
Suppose the AN decides after an interval that it should return 2000 Suppose the AN decides after an interval that it should return 2000
kbits/s of the 4000 kbits/s that it acquired from the NAS in the kbits/s of the 4000 kbits/s that it acquired from the NAS in the
previous transaction. It therefore issues a Bandwidth Transfer previous transaction. It therefore issues a Bandwidth Transfer
message of its own. This message differs from the message in message of its own. This message differs from the message in
Figure 20 in two ways. First, because this is an autonomous transfer Figure 22 in two ways. First, because this is an autonomous transfer
rather than a response, the Result field in the header is set to rather than a response, the Result field in the header is set to
Ignore (0x0). Secondly, the Delegated amount is reduced to 10000 Ignore (0x0). Secondly, the Delegated amount is reduced to 10000
kbits/s. kbits/s.
Now suppose that somehow the NAS forgot that it passed an additional Now suppose that somehow the NAS forgot that it passed an additional
4000 kbits/s to the AN. Thus its current view of the amount of 4000 kbits/s to the AN. Thus its current view of the amount of total
delegated bandwidth is 8000 kbits/s. The 10000 kbits/s appearing in multicast bandwidth is 8000 kbits/s. The 10000 kbits/s appearing in
the Bandwidth Transfer message is higher than this, so there is the Bandwidth Transfer message is higher than this, so there is
clearly a disgareement between the NAS and the AN. The NAS chooses clearly a disgareement between the NAS and the AN. The NAS chooses
to initiate the reset procedure, perhaps because it is close to to initiate the reset procedure, perhaps because it is close to
committing all of its available video bandwidth for unicast service. committing all of its available video bandwidth for unicast service.
As the initial step in this procedure, it issues a Multicast Status As the initial step in this procedure, it issues a Multicast Status
message indicating that a reset of the delegated amount is required. message indicating that a reset of the total multicast amount is
This is shown in the following figure. required. This is shown in the following figure.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length | | Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=91 | 0x4 | Code = 0 | | Vers | Sub |MessageType=91 | 0x4 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
skipping to change at page 64, line 35 skipping to change at page 84, line 35
| | | |
~ Access Loop Circuit ID ~ ~ Access Loop Circuit ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Alloc | TLV Length = 4 | |TLV Type = Bandwidth-Alloc | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount = 8000 | | Delegated amount = 8000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Result Code field within the Status-Info TLV contains the value: The Result Code field within the Status-Info TLV contains the value:
delegated bandwidth reset required (0xTBD). total multicast bandwidth reset required (0xTBD).
Figure 21: Example Initiation of Delegated Bandwidth Reset Figure 23: Example Initiation of Multicast Bandwidth Reset
The NAS stops processing video service requests for the given access The NAS stops processing video service requests for the given access
line when it sends this message. Similarly, the AN stops processing line when it sends this message. Similarly, the AN stops processing
multicast video service requests when it receives the message. [To multicast video service requests when it receives the message. [To
think about: can service requests that release bandwidth be safely think about: can service requests that release bandwidth be safely
processed? Probably.] The next step is up to the NAS: it sends a processed? Probably.] The next step is up to the NAS: it sends a
Bandwidth Delegation Query Request message to the AN. The Result bandwidth delegation Query Request message to the AN. The Result
field in the header is set to Ignore (0x0) as usual for multicast- field in the header is set to Ignore (0x0) as usual for multicast-
related messages. The Target TLV is a copy of the one received in related messages. The Target TLV is a copy of the one received in
the original Bandwidth Transfer message. The message is shown in the the original Bandwidth Transfer message. The message is shown in the
following figure: following figure:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | MsgTyp = 96 |Rslt=0 | Code = 0 | | Vers | Sub | MsgTyp = 96 |Rslt=0 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 65, line 23 skipping to change at page 85, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length | | TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Access Loop Circuit ID ~ ~ Access Loop Circuit ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Example Delegated Bandwidth Query Request Message Figure 24: Example Delegated Bandwidth Query Request Message
The AN returns a Delegated Bandwidth Query Response message showing The AN returns a Delegated Bandwidth Query Response message showing
that it believes that the amount of delegated bandwidth is 10000 that it believes that the amount of total multicast bandwidth is
kbits/s and it has committed 8000 kbits/s of it. The Result field in 10000 kbits/s and it has committed 8000 kbits/s of it. The Result
the header shows Success (0x3) to distinguish the response. [... in field in the header shows Success (0x3) to distinguish the response.
case we decide to make the query bidirectional ...] [... in case we decide to make the query bidirectional ...]
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | MsgTyp = 96 |Rslt=3 | Code = 0 | | Vers | Sub | MsgTyp = 96 |Rslt=3 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length | | TLV Type = Target | Target-TLV Length |
skipping to change at page 66, line 28 skipping to change at page 86, line 28
~ Access Loop Circuit ID ~ ~ Access Loop Circuit ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Request | TLV Length = 8 | |TLV Type = Bandwidth-Request | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount = 10000 | | Delegated amount = 10000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed amount = 8000 | | Committed amount = 8000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Example Delegated Bandwidth Query Response Message Figure 25: Example Delegated Bandwidth Query Response Message
The NAS decides to reset the delegated bandwidth amount to 8000 The NAS decides to reset the total multicast bandwidth amount to 8000
kbits/s. It issues a Port Management message looking exactly like kbits/s. It issues a Port Management message looking exactly like
the one in Figure 18. Once it sends this message, it resumes the one in Figure 20. Once it sends this message, it resumes
processing service requests for the access line concerned. processing service requests for the access line concerned.
Similarly, the AN resumes request processing after it receives the Similarly, the AN resumes request processing after it receives the
Port Management message and resets its view of the current delegated Port Management message and resets its view of the current total
bandwidth. In the short run, this means that it will have to ask for multicast bandwidth. In the short run, this means that it will have
more bandwidth if it receives another Join request. [It seems to ask for more bandwidth if it receives another Join request. [It
reasonable that the AN would not do so for a period of time after a seems reasonable that the AN would not do so for a period of time
reset or a response to a Bandwidth Reallocation Request that grants after a reset or a response to a Bandwidth Reallocation Request that
less than the preferred amount. Should we establish a timer?] grants less than the preferred amount. Should we establish a timer?]
7.3. Example Flows For Multicast Flow Reporting A.3. Example Flows For Multicast Flow Reporting
7.3.1. Per Port Multicast Flow Reporting A.3.1. Per Port Multicast Flow Reporting
Figure 24 illustrate a message flow in the case where the NAS queries Figure 26 illustrate a message flow in the case where the NAS queries
the AN about which multicast flow is active on port 10, on port 20 the AN about which multicast flow is 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 24: Per Port Multicast Flow Reporting Figure 26: 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 25. Figure 27.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type = 97 |Rslt=00| Code = 0 | | Vers | Sub | Msg Type = 97 |Rslt=00| Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 68, line 39 skipping to change at page 88, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 25: Multicast Flow Query Request message for per-port Mulicast Figure 27: Multicast Flow Query Request message for per-port Mulicast
Flow Reporting Flow Reporting
The Multicast Flow Query Response message (M2) is illustrated in The Multicast Flow Query Response message (M2) is illustrated in
Figure 26. It indicates that there is one active multicast flow Figure 28. It indicates that there is one active multicast flow
[(192.0.2.1, 233.252.2.4)] on port 10, no active multicast flow on [(192.0.2.1, 233.252.2.4)] on port 10, no active multicast flow on
port 20 and two active multicast flows [(192.0.2.1, 233.252.2.4) and port 20 and two active multicast flows [(192.0.2.1, 233.252.2.4) and
(192.0.2.2, 233.252.2.10)] on port 11. (192.0.2.2, 233.252.2.10)] on port 11.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type = 97 |Rslt=00| Code = 0 | | Vers | Sub | Msg Type = 97 |Rslt=00| Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
skipping to change at page 70, line 4 skipping to change at page 90, line 4
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 | | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 | | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length | |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 | | AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.10 | | AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
Figure 26: Multicast Flow Query Response message for per-port Figure 28: Multicast Flow Query Response message for per-port
Mulicast Flow Reporting Mulicast Flow Reporting
8. Security Considerations
The security considerations of ANCP are discussed in
[I-D.ietf-ancp-protocol] and in [I-D.ietf-ancp-security-threats].
9. IANA Considerations
This document defines the following additional values within the
GSMPv3 Message Type Name Space registry:
+--------------------------------+--------+---------------+
| Message | Number | Source |
+--------------------------------+--------+---------------+
| Multicast Replication Control | 90 | This document |
| | | |
| Multicast Status | 91 | This document |
| | | |
| Multicast Admission Control | 92 | This document |
| | | |
| Bandwidth Reallocation Request | 94 | This document |
| | | |
| Bandwidth Transfer | 95 | This document |
| | | |
| Delegated Bandwidth Query | 96 | This document |
| | | |
| Multicast Flow Query | 97 | This document |
+--------------------------------+--------+---------------+
This document defines the following values for the ANCP Status-Info
Result Code Registry :
+----------------------------------------------+--------+-----------+
| Status | Number | Reference |
+----------------------------------------------+--------+-----------+
| Command not supported | 0x02 | This |
| | | document |
| | | |
| Flag set but not supported | 0x03 | This |
| | | document |
| | | |
| Unsupported Address Family | 0x05 | This |
| | | document |
| | | |
| Malformed flow address | 0x06 | This |
| | | document |
| | | |
| Configuration error (such as Port not | 0x0a | This |
| enabled for multicast) | | document |
| | | |
| Multicast flow does not exist | 0x0b | This |
| | | document |
| | | |
| Unsupported address encoding | 0x0c | This |
| | | document |
| | | |
| Additional info needed to execute command | 0x0d | This |
| (payload MAY contain an indication of the | | document |
| expected info) | | |
| | | |
| Multicast flow count exceeded | 0x0e | This |
| | | document |
| | | |
| M Flag set, but no IP Source address | 0x0f | This |
| provided | | document |
| | | |
| Invalid preferred bandwidth amount | 0x11 | This |
| | | document |
| | | |
| Bandwidth delegation not activated | 0x12 | This |
| | | document |
| | | |
| Delegated bandwidth reset required | 0x13 | This |
| | | document |
+----------------------------------------------+--------+-----------+
This document defines the following additional values within the ANCP
TLV Type Registry:
+--------------------------------+-----------+---------------+
| TLV Name | Type Code | Reference |
+--------------------------------+-----------+---------------+
| Multicast-Service-Profile | 0x13 | This document |
| | | |
| Bandwidth-Delegation-Control | 0x14 | This document |
| | | |
| Bandwidth-Allocation | 0x15 | This document |
| | | |
| Bandwidth-Request | 0x16 | This document |
| | | |
| Bandwidth-Status | 0x17 | This document |
| | | |
| Multicast-Service-Profile-Name | 0x18 | This document |
| | | |
| Multicast-Flow | 0x19 | This document |
+--------------------------------+-----------+---------------+
This document defines the following values for the ANCP Command Code
registry:
+-------------------------------------+----------------+------------+
| Command Code Directive Name | Command Code | Reference |
| | Value | |
+-------------------------------------+----------------+------------+
| Add | 0x01 | This |
| | | document |
| | | |
| Delete | 0x02 | This |
| | | document |
| | | |
| Delete All | 0x03 | This |
| | | document |
| | | |
| Admission Control Reject | 0x04 | This |
| | | document |
| | | |
| Conditional Access Reject | 0x05 | This |
| | | document |
| | | |
| Admission Control and Conditional | 0x06 | This |
| Access Reject | | document |
+-------------------------------------+----------------+------------+
This document defines the following additional values to the ANCP
sub-TLV Type registry:
+--------------------+-----------+---------------+
| sub-TLV Name | Type Code | Reference |
+--------------------+-----------+---------------+
| Request-Source-IP | 0x92 | This document |
| | | |
| Request-Source-MAC | 0x93 | This document |
+--------------------+-----------+---------------+
10. Acknowledgements
The authors would like to acknowledge Wojciech Dec for providing
useful input to this document, Robert Rennison for his help in
shaping the definition of the Multicast-Service-Profile TLV, Shridhar
Rao for his comments and suggestions and Aniruddha A for his proposal
that formed the base of the Multicast Flow Reporting solution.
Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided
substantial contributions on the solution for the NAS initiated
multicast control use case.
11. References
11.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-10 (work in progress), May 2009.
[I-D.ietf-ancp-protocol]
Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., Voigt,
N., and R. Maglione, "Protocol for Access Node Control
Mechanism in Broadband Networks",
draft-ietf-ancp-protocol-05 (work in progress),
March 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
11.2. Informative References
[I-D.ietf-ancp-security-threats]
Moustafa, H., Tschofenig, H., and S. Cnodder, "Security
Threats and Security Requirements for the Access Node
Control Protocol (ANCP)",
draft-ietf-ancp-security-threats-07 (work in progress),
March 2009.
[I-D.morin-mboned-igmpmld-error-feedback]
Morin, T. and B. Haberman, "IGMP/MLD Error Feedback",
draft-morin-mboned-igmpmld-error-feedback-02 (work in
progress), November 2008.
[IANAAEA] "http://www.iana.org/assignments/address-family-numbers",
2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
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
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com Email: flefauch@cisco.com
skipping to change at page 79, line 32 skipping to change at page 91, line 32
Phone: Phone:
Email: roberta.maglione@telecomitalia.it Email: roberta.maglione@telecomitalia.it
Tom Taylor Tom Taylor
Huawei Technologies Huawei Technologies
1852 Lorraine Ave 1852 Lorraine Ave
Ottawa, Ontario K1H 6Z8 Ottawa, Ontario K1H 6Z8
Canada Canada
Phone: +1 613 680 2675 Phone: +1 613 680 2675
Email: tom.taylor@rogers.com Email: tom111.taylor@bell.net
 End of changes. 286 change blocks. 
1200 lines changed or deleted 1739 lines changed or added

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