One document matched: draft-lefaucheur-ancp-mc-extensions-01.txt
Differences from draft-lefaucheur-ancp-mc-extensions-00.txt
ANCP F. Le Faucheur
Internet-Draft Cisco
Intended status: Standards Track R. Maglione
Expires: September 10, 2009 Telecom Italia
T. Taylor
Huawei
March 9, 2009
Additional Multicast Control Extensions for ANCP
draft-lefaucheur-ancp-mc-extensions-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Le Faucheur, et al. Expires September 10, 2009 [Page 1]
Internet-Draft ANCP Multicast Extensions March 2009
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Le Faucheur, et al. Expires September 10, 2009 [Page 2]
Internet-Draft ANCP Multicast Extensions March 2009
Abstract
This memorandum aims at defining additional ANCP protocol extensions
(beyond those already defined) to support some of the Multicast use
cases defined in the ANCP Framework document that are not yet
supported.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 7
3.2. Port Management Message . . . . . . . . . . . . . . . . . 8
3.3. Multicast Admission Control Message . . . . . . . . . . . 8
3.4. Multicast Replication Control Message . . . . . . . . . . 10
3.5. Multicast Status Message . . . . . . . . . . . . . . . . . 12
3.6. Bandwidth Reallocation Request Message . . . . . . . . . . 12
3.7. Bandwidth Transfer Message . . . . . . . . . . . . . . . . 14
3.8. Delegated Bandwidth Query Request and Response Messages . 15
3.9. Delegated Bandwidth Reset Procedure . . . . . . . . . . . 17
4. ANCP TLVs and Sub-TLVs . . . . . . . . . . . . . . . . . . . . 19
4.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 19
4.1.1. Processing of Joins/Leaves at the Access Node
based on Multicast-Service-Profile . . . . . . . . . . 21
4.2. Service-Profile TLV . . . . . . . . . . . . . . . . . . . 23
4.3. Bandwidth-Delegation-Control TLV . . . . . . . . . . . . . 23
4.4. Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 24
4.5. Bandwidth-Request TLV . . . . . . . . . . . . . . . . . . 24
4.6. Bandwidth-Status TLV . . . . . . . . . . . . . . . . . . . 25
4.7. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 25
4.8. Request-Source-IP sub-TLV . . . . . . . . . . . . . . . . 26
4.9. Request-Source-MAC sub-TLV . . . . . . . . . . . . . . . . 27
4.10. Command Codes of Command TLV . . . . . . . . . . . . . . . 27
5. New Capabilities . . . . . . . . . . . . . . . . . . . . . . . 29
6. Example of Messages and Message Flows . . . . . . . . . . . . 31
6.1. Multicast Conditional Access and CAC without AN
Bandwidth Delegation . . . . . . . . . . . . . . . . . . . 31
6.1.1. List/Profile Provisioning . . . . . . . . . . . . . . 31
6.1.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 33
6.1.3. Successful Join/Leave Operations . . . . . . . . . . . 33
6.1.4. Admission Control Reject without NAS Response . . . . 39
6.1.5. Admission Control Reject with NAS Response . . . . . . 41
6.2. Example Flows For Bandwidth Delegation . . . . . . . . . . 45
6.2.1. Activation and Provisioning of Delegated Bandwidth . . 46
6.2.2. Admission Control of White Flow Without Change in
Delegated Bandwidth . . . . . . . . . . . . . . . . . 49
Le Faucheur, et al. Expires September 10, 2009 [Page 3]
Internet-Draft ANCP Multicast Extensions March 2009
6.2.3. Admission Control of White Flow with Increase in
Delegated Bandwidth . . . . . . . . . . . . . . . . . 50
6.2.4. Admission Control of Grey Flow Without Change in
Delegated Bandwidth . . . . . . . . . . . . . . . . . 53
6.2.5. Admission Control of Grey Flow with Increase in
Delegated Bandwidth . . . . . . . . . . . . . . . . . 54
6.2.6. Failed Autonomous Bandwidth Transfer With Reset . . . 55
7. Security Considerations . . . . . . . . . . . . . . . . . . . 60
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
10.1. Normative References . . . . . . . . . . . . . . . . . . . 64
10.2. Informative References . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
Le Faucheur, et al. Expires September 10, 2009 [Page 4]
Internet-Draft ANCP Multicast Extensions March 2009
1. Introduction
[I-D.ietf-ancp-framework] defines a framework and requirements for an
Access Node Control Mechanism between a Network Access Server (NAS)
and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer
(DSLAM)) in a multi-service reference architecture in order to
perform QoS-related, service-related and Subscriber-related
operations. [I-D.ietf-ancp-protocol] specifies a Protocol for Access
Node Control Mechanism in Broadband Networks in line with this
framework.
[I-D.ietf-ancp-framework] defines multicast use cases as well as the
corresponding ANCP multicast requirements, ANCP Access Node multicast
requirements and ANCP NAS multicast requirements. The current
version of [I-D.ietf-ancp-protocol] incorporates (or will
incorporate) the extensions proposed in [I-D.ancp-mc-extensions].
Therefore it supports a subset of the multicast use cases
(specifically it supports the NAS initiated ANCP Multicast Control
use case). This memorandum proposes some extensions to the ANCP
protocol to cover a bigger subset of the multicast use cases
(specifically the Conditional Access use case and the Multicast
Admission Control use cases with and without Bandwidth delegation).
Le Faucheur, et al. Expires September 10, 2009 [Page 5]
Internet-Draft ANCP Multicast Extensions March 2009
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The expression "delegated bandwidth" is used as a shorter way of
saying: "the total amount of video bandwidth delegated to the AN for
multicast admission control".
Le Faucheur, et al. Expires September 10, 2009 [Page 6]
Internet-Draft ANCP Multicast Extensions March 2009
3. ANCP Messages
This section defines new ANCP messages and new usage of existing ANCP
messages as well as procedures associated with the use of these
messages.
3.1. Provisioning Message
This section defines a new message called the Provisioning message.
The Provisioning message is sent by the NAS to the AN to provision
information in the AN. This message can be used to provision
multicast-related information (e.g. Multicast Service Profiles,
Bandwidth Delegation activation/deactivation) as well as non-
multicast-related information (e.g. Service Profile).
The Message Type for the Provisioning message is 93 (TBC).
The NAS sending the Provisioning message MUST set the Result field to
0x00.
The NAS MUST populate the ANCP Transaction Identifier field with a
distinct non-zero, linearly incrementing value for each request per
adjacency, as described in [I-D.ietf-ancp-protocol] .
The ANCP Provisioning message payload MAY contain the following TLVs:
o Service-Profile TLV: the Service-Profile TLV is defined in the
present document in Section 4.2. It MAY appear zero, one or
multiple times.
o Multicast-Service-Profile TLV: the Multicast-Service-Profile TLV
is defined in the present document in Section 4.1. It MAY appear
zero, one or multiple times. Each instance of the Multicast-
Service-Profile TLV contains a (possibly empty) White List, a
(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
TLV is defined in the present document in Section 4.3. It MAY
appear zero times or once. When present, it instructs the AN on
whether Bandwidth Delegation is to be activated or deactivated.
The AN MUST interpret the absence of the Bandwidth-Delegation-
Control TLV as indicating that bandwidth delegation is to be
deactivated.
On receipt of the Provisioning message, the AN MUST:
Le Faucheur, et al. Expires September 10, 2009 [Page 7]
Internet-Draft ANCP Multicast Extensions March 2009
o ignore the Result field
o if the AN can process the message successfully and accept all the
provisioning directives contained in it, the AN MUST NOT send any
response.
o [Editor's note: the behavior of the AN when it cannot process the
message, or when it cannot accept all the provisioning directives
contained in it is for further study.]
3.2. Port Management Message
As defined in [I-D.ietf-ancp-protocol], the NAS may send line
configuration information to the AN ("ANCP based Line Configuration"
use case) using GSMP Port Management messages modified to contain an
extension block. [I-D.ietf-ancp-protocol] defines a number of TLVs
that can be included in the Extension Value field inside a Port
Management message (e.g. "Access-Loop-Circuit-ID", "Service-
Profile-Name").
This document specifies that the Port Management message MAY also be
used by the NAS to associate a "Multicast-Service-Profile" (aka. a
triple of White, Grey and Black lists) to a AN port. To do so, the
NAS includes a "Multicast-Service-Profile-Name" TLV as defined in
Section 4.7 in the Port Management message.
In addition, when bandwidth delegation is activated for this AN, the
Port Management message MAY be used to provision the initial amount
of bandwidth delegated to the AN for multicast admission control
(hereafter referred to as the "delegated bandwidth"). To do so, the
NAS includes a "Bandwidth-Allocation" TLV as defined in Section 4.4
in the Port Management message.
Editor's Note: the Port Management message requires the specification
of an Access-Loop-Circuit-Id TLV indicating the target of the
assignment. Thinking about the possibility of PON, will we be
updating the definition of Access-Loop-Circuit-Id TLV to include
default naming formats for PON? Of the authors, TT prefers this
route, leaving Target to designate multiple targets for the same
command.
3.3. Multicast Admission Control Message
This section defines a new message called the Multicast Admission
Control message. The Multicast Admission Control message is sent by
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
NAS will use a Multicast Replication Control message (as discussed in
Le Faucheur, et al. Expires September 10, 2009 [Page 8]
Internet-Draft ANCP Multicast Extensions March 2009
Section 3.4) in order to convey back to the AN the outcome of the
admission request.
The Message Type for the Multicast Admission Control message is 92
(TBC).
The AN sending the Multicast Admission Control message MUST set the
Result field to "0x00".
The AN MUST populate the ANCP Transaction Identifier field with a
distinct non-zero, linearly incrementing value for each request per
adjacency, as described in [I-D.ietf-ancp-protocol] .
The ANCP Multicast Admission Control message payload contains two
TLVs:
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
Control message. It is encoded as specified in
[I-D.ietf-ancp-protocol] and identifies the AN port subject to the
request for admission or release.
o Command TLV: The Command TLV is defined in
[I-D.ietf-ancp-protocol]. It MUST be present. If it appears more
than once, only the first instance is considered meaningful in the
present version of the document and the other instances are
ignored . The Command TLV is encoded as specified in
[I-D.ietf-ancp-protocol] with the following additional rules:
* the R flag is set to 0
* the O flag is set to 0
* the Command field is set to "0x01 - Add" when the message
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
of the Command TLV identify the multicast flow subject to the
request for admission or release.
* a Request-Source-IP sub-TLV (as defined in Section 4.8) MAY be
included by the AN to convey the IP address of the sender of
the join/leave message (e.g. IGMP 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
Le Faucheur, et al. Expires September 10, 2009 [Page 9]
Internet-Draft ANCP Multicast Extensions March 2009
instances are ignored.
* a Request-Source-MAC sub-TLV (as defined in Section 4.9) MAY be
included by the AN to convey the MAC address of the sender of
the join/leave message (e.g. IGMP 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
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
3.4. Multicast Replication Control Message
[I-D.ietf-ancp-framework] describes the "NAS initiated ANCP Multicast
Control" use case. In this use case, the NAS issues ANCP directives
to the AN to instruct the AN to either add (join) or delete (leave)
multicast flows without the AN having previously issued corresponding
ANCP requests. To support this use case, [I-D.ietf-ancp-protocol]
defines the Multicast Replication Control message and how that
message can be used from the NAS to the AN to convey a directive to
either add (join) or delete (leave) one or more multicast flows.
The present section specifies another use of the Multicast
Replication Control message in order to support the "Multicast
Admission Control" use case defined in [I-D.ietf-ancp-framework]. To
support that use case, the Multicast Replication Control message can
also be used by the NAS in response to a Multicast Admission Control
message from the AN.
On receipt of an Multicast Admission Control message, the NAS:
o MUST ignore the Result field
o if the directive in the Multicast Admission Control message is
"0x02 - Delete" or "0x03 - Delete All" and is processed correctly
by the NAS, the NAS MUST NOT generate any ANCP message in response
to the Multicast Admission Control message
Le Faucheur, et al. Expires September 10, 2009 [Page 10]
Internet-Draft ANCP Multicast Extensions March 2009
o if the directive in the Multicast Admission Control message is
"0x01 - Add" and is accepted by the NAS, the NAS MUST generate a
Multicast Replication Control in response to the Multicast
Admission Control message. The Multicast Replication Control
message:
* MUST contain a Result set to 0x00
* MUST contain a Transaction ID generated by the NAS (distinct
non-zero, and linearly incremented by NAS for each request per
adjacency).
* MUST contain the directive as accepted by the NAS
o if the directive in the Multicast Admission Control message is
"0x01 - Add", is processed correctly but not accepted by the NAS
(i.e. it does not pass the admission control or conditional access
check), the NAS MAY generate a Multicast Replication Control
message in response to the Multicast Admission Control message.
This optional message can be used by the AN to maintain statistics
about admission control reject and, in the future, when the
protocol between the subscriber and the AN allows explicit
notification of join reject (e.g.
[I-D.morin-mboned-igmpmld-error-feedback]). When used, the
Multicast Replication Control message:
* MUST contain a Result set to 0x00
* MUST contain a Transaction ID generated by the NAS (distinct
non-zero, and linearly incremented by NAS for each request per
adjacency).
* MUST contain the directive rejected by the NAS (i.e. Target
TLV and Command TLV) but with a Command Code set to "0xTBD -
Admission Control Reject", "0xTBD - Conditional Access Reject"
or "0xTBD - Admission Control and Conditional Access Reject".
o if the Multicast Admission Control message cannot be processed
correctly by the NAS (e.g. the message is malformed, the multicast
flow does not exist etc.), the NAS MUST generate a Multicast
Status message in response to the Multicast Admission Control
message. The Multicast Status message:
* MUST contain a Result set to "Failure" in the ANCP header
* MUST contain a Transaction ID that echoes the value of the
Transaction ID received in the Multicast Admission Control
message.
Le Faucheur, et al. Expires September 10, 2009 [Page 11]
Internet-Draft ANCP Multicast Extensions March 2009
* MUST contain a Status TLV including a Result Code indicating
the reason why the Admission Control message could not be
processed and encoded as specified in [I-D.ietf-ancp-protocol].
3.5. Multicast Status Message
[I-D.ietf-ancp-protocol] defines the Multicast Status message and how
that message can be used in response to a Replication Control message
in order to support of the NAS initiated ANCP Multicast Control use
case. Section 3.4 of the present document also specifies use of the
Multicast Status message by the NAS on receipt of a Multicast
Admission Control message that cannot be processed correctly.
This section specifies another use of the Multicast Status message in
order to support the Multicast Admission Control use cases defined in
[I-D.ietf-ancp-framework]. When the AN receives a Multicast
Replication Control message (that is a response to a Multicast
Admission Control message sent earlier by the AN), the AN can use the
Multicast Status message to respond to the Multicast Replication
Control message exactly as already defined in
[I-D.ietf-ancp-protocol] for the NAS initiated ANCP Multicast Control
use case. For example, if the AN cannot process the Multicast
Replication Control message, it MUST respond with a Multicast Status
message with a Result set to Failure and a Status TLV indicating the
reason of the failure (e.g. 0x09 - Target port down).
3.6. Bandwidth Reallocation Request Message
The Bandwidth Reallocation Request message is used when the Bandwidth
Delegation capability has been activated. It MAY be 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 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 94
(TBC). The Result field in the header of the Bandwidth Reallocation
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]),
specifying a single access line; [TT - I would prefer the Access-
Loop-Circuit-Id TLV, believing it should evolve to include non-DSL
Le Faucheur, et al. Expires September 10, 2009 [Page 12]
Internet-Draft ANCP Multicast Extensions March 2009
identifiers, but the majority overruled me];
o the Bandwidth-Request TLV (Section 4.5), specifying the required
and preferred amounts of delegated bandwidth.
The bandwidth values in the Bandwidth-Request TLV are expressed in
terms of total bandwidth delegated to the AN.
The choice of "total bandwidth" rather than "incremental
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
bandwidth synchronized.
Because the values are totals rather than desired increments/
decrements, the relationship between the Required Delegated Bandwidth
and the Preferred Delegated Bandwidth will differ depending on
whether the Bandwidth Reallocation Request message is issued by the
NAS or the AN.
o If the NAS is making the request, the Preferred Delegated
Bandwidth MUST be less than or equal to the Required Delegated
Bandwidth. The Required Delegated Bandwidth MUST be less than the
current delegated bandwidth value.
o If the AN is making the request, the Preferred Delegated Bandwidth
MUST be greater than or equal to the Required Delegated Bandwidth.
The Required Delegated Bandwidth MUST be greater than the current
delegated bandwidth value.
If these conditions are violated and the problem is the relationship
between the required amount and the receiver's view of the current
delegated bandwidth, the delegated bandwidth reset procedure
described in Section 3.9 MUST be performed. If the problem is the
relationship between the Preferred and Required Delegated Bandwidth
values, 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 Delegated Bandwidth value (0xTBD);
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);
Le Faucheur, et al. Expires September 10, 2009 [Page 13]
Internet-Draft ANCP Multicast Extensions March 2009
the Target TLV, copied from the Bandwidth Reallocation Request
message;
the Bandwidth-Request TLV, also copied from the request message.
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 Delegated Bandwidth
indicated in the Bandwidth Reallocation Request message. The peer
MUST return a Bandwidth Transfer message Section 3.7 indicating its
decision. If the request is met, the Result field of the Bandwidth
Transfer message MUST be set to Success (0x3), and the Bandwidth-
Allocation TLV (Section 4.4) MUST contain the new value of delegated
bandwidth. This new value MUST lie between the Required and
Preferred Delegated Bandwidth 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) and the
Bandwidth Allocation TLV MUST contain the value of the current amount
of delegated bandwidth as the responder views it.
To avoid deadlock due to race conditions, the following rules MUST be
applied:
a. If the NAS receives a Bandwidth Reallocation Request message
while it has a Bandwidth Reallocation Request message of its own
outstanding for the same access line, the NAS MUST provide an
immediate failure response to the request from the AN.
b. If the AN receives a Bandwidth Reallocation Request message while
it has a Bandwidth Reallocation Request message of its own
outstanding for the same access line, the AN MUST release any
bandwidth it has already committed to an outstanding Join request
while it is awaiting a response from the NAS. It MUST decide
upon and send its response to the NAS taking the released
bandwidth into account.
[Editor's Note: This is an arbitrary rule which effectively gives
priority to unicast over multicast. Is that the right direction?]
3.7. Bandwidth Transfer Message
The Bandwidth Transfer message is used to transfer video bandwidth
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
previous section, it is the required response to a valid Bandwidth
Reallocation Request message.
Le Faucheur, et al. Expires September 10, 2009 [Page 14]
Internet-Draft ANCP Multicast Extensions March 2009
The Bandwidth Transfer message MAY also be used to transfer bandwidth
autonomously from one peer to another. One example of this usage is
to release bandwidth borrowed earlier by means of the Bandwidth
Reallocation Request message. When the message is used in this way,
the Result field in the Bandwidth Transfer message MUST be set to
Ignore (0x0). This allows the receiver to distinguish between an
autonomous transfer and a response to a previous Bandwidth
Reallocation Request, for purposes of validation.
The Message Type for the Bandwidth Transfer message is 95 (TBC). The
Bandwidth Transfer message MUST contain the following TLVs:
o the Target TLV, designating the access line concerned;
o an instance of the Bandwidth-Allocation TLV (Section 4.4).
The bandwidth value in the Bandwidth-Allocation TLV is the new amount
of delegated bandwidth. The following relationships MUST hold:
o if the message is sent by the NAS, the Delegated Bandwidth value
in the Bandwidth-Allocation TLV MUST be greater than or equal to
the current amount of delegated bandwidth for the access line
concerned;
o if the message is sent by the AN, the Delegated Bandwidth value in
the Bandwidth-Allocation TLV MUST be less than or equal to the
current amount of delegated bandwidth for the access line
concerned.
In either case, equality to the current delegated bandwidth is
permitted only for a failure response to a previous Bandwidth
Reallocation Request.
If the Bandwidth Transfer message satisfies these conditions, the
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 does not satisfy
the conditions, the receiver MAY either accept the new value or MAY
choose to initiate the delegated bandwidth reset procedure described
in Section 3.9.
3.8. Delegated Bandwidth Query Request and Response Messages
The Message Type for the Delegated Bandwidth Query Request and
Response messages is 96 (TBC).
The Delegated Bandwidth Query Request message MAY be sent by the NAS
to retrieve the AN's view of the total amount of delegated bandwidth
Le Faucheur, et al. Expires September 10, 2009 [Page 15]
Internet-Draft ANCP Multicast Extensions March 2009
and the amount that is already committed. The request contains one
TLV:
o a Target TLV designating the access line(s) for which the
information is requested.
Consistently with other multicast-related messages, the Result field
in the header of the Delegated Bandwidth Query Request message MUST
be set to Ignore (0x0).
If the AN receives an invalid Delegated Bandwidth Query Request
message, it MUST return a Multicast Status message with the Result
field in the header set to Failure (0x4). The following cases may
occur:
o if the Target is invalid, the Status-Info TLV contains the
following values:
Result Code = unrecognized target (0x04);
Command Number = the order of the invalid Target TLV within the
request, numbering from 1 for the first one listed;
Error Message Length = 0x0 (or optionally the length of an
error message, padded to a four-octet boundary);
Error Message (optional text);
the invalid Target TLV, copied from the Delegated Bandwidth
Query Request message.
o if bandwidth delegation is not activated on the AN, the Status-
Info TLV contains the following values:
Result Code = bandwidth delegation not activated (0xTBD);
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 AN MUST respond to a valid request with a Delegated Bandwidth
Query Response. The Result field in the header of this message MUST
be set to Success (0x3). This message contains the following TLVs:
Le Faucheur, et al. Expires September 10, 2009 [Page 16]
Internet-Draft ANCP Multicast Extensions March 2009
o the Target TLV, copied from the request;
o one instance of the Bandwidth-Status TLV (Section 4.6) for each
access line designated in the Target TLV. The instances MUST have
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
specification of multiple access lines in the Target TLV.]
3.9. Delegated Bandwidth Reset Procedure
The bandwidth delegation reset procedure defined in this section
reuses existing ANCP messages or messages defined in other section of
this document. No new ANCP messages are defined in this section.
As described above, the receiver of a Bandwidth Reallocation Request
or Bandwidth Transfer message may determine that a bandwidth value in
that message bears an incorrect relationship to its view of the
current amount of delegated bandwidth. The probable cause of this
condition is a discrepancy between its view and its peer's view of
the current delegated bandwidth. Upon detecting this condition, the
receiver MAY choose to initiate the reset procedure described in this
section. If so, it MUST send a Multicast Status message to its peer
with the Result field in the header set to Failure (0x4) and a
Status-Info TLV containing the following values:
Result Code = delegated bandwidth reset required (0xTBD);
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;
Le Faucheur, et al. Expires September 10, 2009 [Page 17]
Internet-Draft ANCP Multicast Extensions March 2009
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.
Le Faucheur, et al. Expires September 10, 2009 [Page 18]
Internet-Draft ANCP Multicast Extensions March 2009
4. ANCP TLVs and Sub-TLVs
This section defines new ANCP TLVs and sub-TLVs or extends existing
ones.
4.1. Multicast-Service-Profile TLV
This document defines the new Multicast-Service-Profile TLV.
The Multicast-Service-Profile TLV MAY be included in a Provisioning
message as specified in Section 3.1.
The Multicast-Service-Profile is illustrated in Figure 1:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Mcast Service Profile | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Service-Profile-Name Sub-TLV |
| Sub-TLV type = 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| White-List Sub-TLV |
| Sub-TLV type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Grey-List Sub-TLV |
| Sub-TLV type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Black-List Sub-TLV |
| Sub-TLV type = 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Multicast-Servive-Profile TLV
Each of the four sub-TLVs begins with a 32-bit header consisting of a
16-bit sub-TLV type code followed by a 16-bit length field giving the
amount of data following this sub-TLV header in octets. The type
code values for the respective sub-TLVs are indicated in the figure.
The content of the sub-TLV follows immediately after the sub-TLV
header. The sub-TLVs are placed into the list consecutively without
intervening padding. The Multicast Service Profile Name sub-TLV MUST
be present, and MUST be unique over all profiles provisioned to the
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
octets used to refer to the profile when activating it for a given
Le Faucheur, et al. Expires September 10, 2009 [Page 19]
Internet-Draft ANCP Multicast Extensions March 2009
target within a Port Management message (see Section 3.2).
The content of the White-List, Grey-List, and Black-List sub-TLVs
following their respective headers is in each case a sequence of
multicast flow fields organized by address family. IPv4 addresses
are listed first, followed by IPv6 addresses. Either set of
addresses MAY be omitted if not applicable, but at least one set of
addresses MUST be present. Figure 2 shows the detailed layout of a
white, grey, or black list, where the detailed layout of an
individual multicast flow field is described below. The list length
in Figure 2 is the number of octets of multicast flow field data for
that address family following the list header.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV tag = 0x0002,3,4 | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Ver=0x0000 (IPv4) | List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Ver=0x0001 (IPv6) | List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Organization of a White, Grey, or Black List
Each multicast flow field refers either to a Single Source Multicast
(SSM) channel or to an Any Source Multicast (ASM) group. The scope
of the designation may be broadened to multiple channels or groups
through use of prefix length values smaller than the total address
length for the given address family. Multicast flow fields MUST be
placed consecutively within the sub-TLV without intervening padding
except to round out individual addresses to the nearest octet
boundary.
A multicast flow field consists of two single-octet prefix lengths
followed by zero to two prefix values as shown in Figure 3:
Le Faucheur, et al. Expires September 10, 2009 [Page 20]
Internet-Draft ANCP Multicast Extensions March 2009
+-+-+-+-+-+-+-+-+
| Group PrefLen |
+-+-+-+-+-+-+-+-+
| Source PrefLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Prefix (multicast) (0 to 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Prefix (unicast, SSM only) (0 to 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Organization of a Single Multicast Flow Field
The prefix length has its usual meaning. It is the number of most-
significant bits specified within the corresponding prefix. The
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
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
Source PrefLen indicates that any value of the corresponding address
will match (wild card). If the value 0x00 is provided for a
particular prefix length, the corresponding prefix MUST be omitted
from the field contents. In particular, a value of 0x00 for the
Source PrefLen indicates an ASM multicast entry, and the Source
Prefix will be absent.
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
end of the prefix MUST be set to zeros.
4.1.1. Processing of Joins/Leaves at the Access Node based on
Multicast-Service-Profile
When the AN receives an IGMP 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:
Le Faucheur, et al. Expires September 10, 2009 [Page 21]
Internet-Draft ANCP Multicast Extensions March 2009
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 Delegated
Bandwidth 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 Delegated
Bandwidth in the Bandwidth-Request TLV to the same value as the
Required Delegated Bandwidth, or to some higher amount determined by
local 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 delegation 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 3.3) to the
NAS with the value of Command set to Add (0x01). If and when a
responding Multicast Replication Control message (Section 3.4)
arrives from the NAS, the AN SHOULD 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.
Le Faucheur, et al. Expires September 10, 2009 [Page 22]
Internet-Draft ANCP Multicast Extensions March 2009
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). If bandwidth delegation is active for the access
line, the AN updates accordingly its view of the amount of committed
bandwidth within the delegated bandwidth.
4.2. Service-Profile TLV
This TLV is outside the scope of the present document as it is not
related to Multicast. It may be defined as part of a separate effort
and is expected to allow configuration of all the relevant parameters
of a service profile as well as its Service Profile Name.
4.3. Bandwidth-Delegation-Control TLV
This document defines the new Bandwidth-Delegation-Control TLV.
The Bandwidth-Delegation-Control TLV MAY be included in a
Provisioning message as specified in Section 3.1.
The Bandwidth-Delegation-Control TLV is illustrated below in
Figure 4.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Bandwidth-Delegation-Control TLV
Bandwidth-Delegation-Control TLV Type:
TLV (0xTBD) : 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::
Le Faucheur, et al. Expires September 10, 2009 [Page 23]
Internet-Draft ANCP Multicast Extensions March 2009
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 the AN
with an initial value for the delegated bandwidth for each line using
the Port Management (Line Configuration) message. An default initial
delegated bandwidth value 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 Join for the given line.
4.4. Bandwidth-Allocation TLV
The Bandwidth-Allocation TLV is used to indicate the total amount of
video bandwidth delegated to the AN for multicast admission control
for a given line, in kilobits per second. The TLV has the format
shown in Figure 5.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Bandwidth (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Bandwidth-Allocation TLV
4.5. Bandwidth-Request TLV
The Bandwidth-Request TLV is used to request an adjustment of the
total amount of video bandwidth delegated to the AN for multicast
admission control for a given line. The "Required Delegated
Bandwidth" field indicates the minimum adjustment required to meet
the request. The "Preferred Delegated Bandwidth" field indicates the
adjustment the requestor would prefer to have, if possible.
Section 3.6 discusses the required relationships between the
"Required Delegated Bandwidth", "Preferred Delegated Bandwidth", and
Le Faucheur, et al. Expires September 10, 2009 [Page 24]
Internet-Draft ANCP Multicast Extensions March 2009
current values of total bandwidth delegated to the AN.
The Bandwidth-Request TLV has the format shown in Figure 6.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Delegated Bandwidth (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Delegated Bandwidth (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The Bandwidth-Request TLV
4.6. 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 7.
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 Bandwidth (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Bandwidth (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: The Bandwidth-Status TLV
The Committed Bandwidth SHOULD be less than or equal to the Delegated
Bandwidth. One case where this may not be so is if the procedure
described in Section 3.9 has been performed and the NAS returned a
Delegated Bandwidth lower than the current Committed Bandwidth.
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.
4.7. Multicast-Service-Profile-Name TLV
[I-D.ietf-ancp-protocol] defines an Extension TLV that can be used in
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-
Le Faucheur, et al. Expires September 10, 2009 [Page 25]
Internet-Draft ANCP Multicast Extensions March 2009
Profile-Name").
This document defines an additional TLV that can appear in an
Extension TLV of Tech Type "DSL" in a Port Management message:
o Type (Multicast-Service-Profile-Name = 0x06 - TBC): Reference to a
multicast service profile on the AN, that defines a <White List,
Black List, Grey List> triple.
Length : (up to 64 bytes)
Value : ASCII string containing the multicast profile name.
4.8. Request-Source-IP sub-TLV
[I-D.ietf-ancp-protocol] defines the Command TLV that can be used in
a Multicast Replication Control message and (as defined in this
document) in the Admission Control message. The Command TLV MAY
include sub-TLVs immediately following the Command Info field.
This document defines the new Request-Source-IP sub-TLV.
The Request-Source-IP sub-TLV MAY be included in a Command TLV inside
an Admission Control message.
The Request-Source-IP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|sub-TLV Type = Request-Source-IP | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request-Source-IP sub-TLV Type:
sub-TLV (0xTBD) indicating the contents to be one or more
command directives.
Request-Source-IP sub-TLV Length:
Combined length in bytes of the data inside sub-TLV.
Excludes the sub-TLV Header.
Address Family, Encoding type and Unicast Address:
Le Faucheur, et al. Expires September 10, 2009 [Page 26]
Internet-Draft ANCP Multicast Extensions March 2009
Contains the IP address of the sender of the join/leave
message (e.g. IGMP Join/Leave) that triggered the AN to
include the corresponding Command TLV in an Admission
Control message. The IP address is encoded as per
[IANAAEA].
4.9. 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
inside an Admission Control message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|sub-TLV Type=Request-Source-MAC |Request-S-MAC sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request-Source-MAC sub-TLV Type:
sub-TLV (0xTBD) indicating the contents to be one or more
command directives.
Request-Source-MAC sub- TLV Length:
Combined length in bytes of the data inside sub-TLV.
Excludes the sub-TLV Header.
TBD:
Contains the IEEE MAC address of the sender of the join/
leave message (e.g. IGMP Join/Leave) that triggered the AN
to include the corresponding Command TLV in an Admission
Control message. The IP address is encoded as per TBD.
4.10. Command Codes of Command TLV
[I-D.ietf-ancp-protocol] defines a number of Command Codes for the
Command TLV (e.g. "0x01 - Add").
The present document specifies the following new additional values
for the Command Code of the Command TLV:
Le Faucheur, et al. Expires September 10, 2009 [Page 27]
Internet-Draft ANCP Multicast Extensions March 2009
0xTBD - Admission Control Reject
0xTBD - Conditional Access Reject
0xTBD - Admission Control and Conditional Access Reject
Le Faucheur, et al. Expires September 10, 2009 [Page 28]
Internet-Draft ANCP Multicast Extensions March 2009
5. New Capabilities
[I-D.ietf-ancp-protocol] defines a capability negotiation mechanism
as well as a number of capabilities. In particular,
[I-D.ietf-ancp-protocol] currently defines the Transactional-
Multicast capability in the following way:
"
3. Capability Type : Transactional-Multicast = 0x03 (controller i.e.
NAS terminates IGMP messages from subscribers, and via l2 control
protocol, signals state to the access-nodes (e.g. DSLAMs) to enable
layer2 replication of multicast streams. In ATM access network this
implies that NAS instructs the access-node to setup a P2MP cross-
connect. The details of this will be covered in a separate ID.
Length (in bytes) : 0
Capability Data : NULL
"
This document redefines this Capability Type into a more generic
Multicast Capability Type allowing negotiation of the level of
subcapability within the Multicast capability. The updated
capability definition is:
o Capability Type : Multicast = 0x03
Length (in bytes) : 1
Capability Data (1 byte): The following values are defined:
+ 0x00: Reserved
+ 0x01: "Transactional Multicast"
+ 0x02: "Transactional Multicast" and "Multicast Admission
Control without Bandwidth Delegation"
+ 0x03: "Transactional Multicast", "Multicast Admission
Control without Bandwidth Delegation" and "Multicast
Admission Control with Bandwidth Delegation"
+ other values: Reserved
Both the NAS and the AN MUST advertise the Multicast capability in
their originated adjacency messages when they support it. Initially,
Le Faucheur, et al. Expires September 10, 2009 [Page 29]
Internet-Draft ANCP Multicast Extensions March 2009
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
"Multicast Admission Control without Bandwidth Delegation" while the
AN only supports "Transactional Multicast", the NAS and AN will
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
Status message.
A NAS or AN supporting the "Transactional Multicast" and "Multicast
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
Admission Control without Bandwidth Delegation" and "Multicast
Admission Control with Bandwidth Delegation" capability MUST support
the Multicast Admission Control message, the Multicast Replication
message, the Multicast Status message, the Bandwidth Reallocation
Request and Response messages, the Autonomous Bandwidth Transfer
message and the Delegated Bandwidth Query Request and Response
messages.
Le Faucheur, et al. Expires September 10, 2009 [Page 30]
Internet-Draft ANCP Multicast Extensions March 2009
6. Example of Messages and Message Flows
This section provides example message flows.
6.1. Multicast Conditional Access and CAC without AN Bandwidth
Delegation
This section describes ANCP operations when multicast flows are
subject to multicast Conditional Access and Admission Control without
Bandwidth Delegation.
6.1.1. List/Profile Provisioning
The AN provisioning is performed by NAS using a Provisioning message
that contains White/Black/Grey lists and their corresponding
"Multicast Service Profile Name". To indicate to the AN that it need
not perform any CAC operation on those flows, the Provisioning
message also conveys an indication that Bandwidth Delegation is to be
deactivated. The corresponding message flow is illustrated in
Figure 8.
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | |(M1) Provisioning |
| | | (Mcast S Prof name, |
| | | White List, |
| | | Grey List, |
| | | Black List, |
| | | Bw Del Deactivated) |
| | |<--------------------|
Figure 8: Provisioning AN with White/Grey/Black Lists for Conditional
Access
The Provisioning message M1 contains:
o an ANCP Header with:
* Message-Type = 93 - Provisioning
* Result= 0x00
* Transaction-ID = Transaction-ID maintained by NAS
Le Faucheur, et al. Expires September 10, 2009 [Page 31]
Internet-Draft ANCP Multicast Extensions March 2009
o a Multicast-Service-Profile TLV containing:
* a Multicast-Service-Profile-Name sub-TLV
* an Empty White-List in our example (and hence no White-List
sub-TLV)
* a Grey-List sub-TLV containing a catch-all entry for IPv4 (in
our example)
* an Empty Black-List in our example (and hence no Black-List
sub-TLV)
The Provisioning message M1 is illustrated below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=93 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Service-Prof TLV Type | Mcast-Service-Prof TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLV Type = 0x0001 | sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Multicast service profile name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLV Type = 0x0003 | sub-TLV Length = 0x06 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP ver = 0x00 | List length = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Grp PLen=0x00 | Src PLen=0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9
Le Faucheur, et al. Expires September 10, 2009 [Page 32]
Internet-Draft ANCP Multicast Extensions March 2009
6.1.2. Profile Mapping
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
with an ANCP PORT_MNGT message that, together with the other
parameters, includes the Multicast Service Profile Name to be
associated to that Port. The corresponding message flow is
illustrated in Figure 10.
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | | |
| | DSL Synch. | |
| |--------------------->| |
| | |(M1)PORT_UP(Port ID) |
| | |-------------------->|
| | | (*)
| | |(M2) PORT_MNGT |
| | | (Port ID, |
| | |Mcast S Profile Name)|
| | |<--------------------|
(*) The NAS may optionally seek direction from an external
Autorization/Policy Server
Figure 10: Associating Profile ID to AN Port
6.1.3. Successful Join/Leave Operations
The message flows in Figure 11 illustrates the ANCP message flow in
case of a simple join and leave for a multicast flow that matches the
grey list and when the "Bandwidth Delegation" mechanism is not
activated in the AN. In that case the AN queries the NAS that
performs Conditional Access and Admission Control.
Le Faucheur, et al. Expires September 10, 2009 [Page 33]
Internet-Draft ANCP Multicast Extensions March 2009
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(Grey-Fl) | Admission |
|-----------+---------->| Control (M1) |
| | |------------------>|
| | | |
| | | Multicast |
| | | Replication (*)
| | | Control (M2) |
| Mcast Grey-Fl |<------------------|
|<======================+ |
| | | |
~ ~ ~ ~
| | | |
| Leave(Grey-Fl) | Admission |
|-----------+---------->| Control (M3) |
| | |------------------>|
| | | |
Grey-Fl : Multicast Flow matching an entry in Grey List
(Bandwidth Delegation not activated on AN)
(*) The NAS may optionally seek direction from an external
Autorization/Policy Server
Figure 11: Successful Join/Leave Operations
The Multicast Admission Control message M1 contains:
o an ANCP Header with:
* Message-Type = 92 - Multicast Admission Control
* Result= 0x00
* Transaction-ID = Transaction-ID maintained by AN
o a Target TLV identifying the AN Port
o a Command TLV containing:
* a Command Code = Add
Le Faucheur, et al. Expires September 10, 2009 [Page 34]
Internet-Draft ANCP Multicast Extensions March 2009
* R = 0
* O = 0
* the multicast flow for which the IGMP Join was received by AN=
(192.0.2.1, 233.252.2.2)
* a Request-Source-IP sub-TLV containing the IGMP join source IP
(192.0.2.100).
The Multicast Admission Control message M1 is illustrated below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=92 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xTBD (Command) TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
The Multicast Replication Control message M2 contains:
Le Faucheur, et al. Expires September 10, 2009 [Page 35]
Internet-Draft ANCP Multicast Extensions March 2009
o an ANCP Header with:
* Message-Type = 90 - Multicast Replication Control
* Result= 0x00
* Transaction-ID = Transaction-ID maintained by NAS
o a Target TLV identifying the AN Port
o a Command TLV containing:
* a Command Code = Add
* R= 1 (since in our example the flow resources have been
admitted by NAS)
* O = 0 (since in our example flow accounting is not required)
* the multicast flow for which the IGMP Join was received by AN=
(192.0.2.1, 233.252.2.2)
* a Request-Source-IP sub-TLV containing the IGMP join source IP
(192.0.2.100).
The Multicast Admission Control message M2 is illustrated below:
Le Faucheur, et al. Expires September 10, 2009 [Page 36]
Internet-Draft ANCP Multicast Extensions March 2009
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=90 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0009 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xTBD (Command) TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 |1 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
The Multicast Admission Control message M3 contains:
o an ANCP Header with:
* Message-Type = 92 - Multicast Admission Control
* Result= 0x00
* Transaction-ID = Transaction-ID maintained by AN
o a Target TLV identifying the AN Port
o a Command TLV containing:
Le Faucheur, et al. Expires September 10, 2009 [Page 37]
Internet-Draft ANCP Multicast Extensions March 2009
* a Command Code = Delete
* R = 0
* O = 0
* the multicast flow for which the IGMP leave was received by AN=
(192.0.2.1, 233.252.2.2)
* a Request-Source-IP sub-TLV containing the IGMP join source IP
(192.0.2.100).
The Multicast Admission Control message M3 is illustrated below:
Le Faucheur, et al. Expires September 10, 2009 [Page 38]
Internet-Draft ANCP Multicast Extensions March 2009
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=92 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0002 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xTBD (Command) TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x02 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = 0xTBD (Request-S.) TLV | Request-S.-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
6.1.4. Admission Control Reject without NAS Response
The message flow in Figure 12 illustrates the ANCP message flow in
case of a join that is rejected by the NAS because of admission
control and without explicit response from the NAS. In that case,
the multicast flow is never replicated simply by virtue of the NAS
not requesting replication.
Le Faucheur, et al. Expires September 10, 2009 [Page 39]
Internet-Draft ANCP Multicast Extensions March 2009
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(Grey-Fl) | Admission |
|-----------+---------->| Control (M1) |
| | |------------------>|
| | | |
| | | (*)
| | | |
| Mcast Grey Flow | |
| not replicated x |
| | | |
Grey-Fl : Multicast Flow matching an entry in Grey List
(Bandwidth Delegation not activated on AN)
(*) The NAS may optionally seek direction from an external
Autorization/Policy Server
Figure 12: Admission Control Reject without NAS Response
The Multicast Admission Control message M1 contains:
o an ANCP Header with:
* Message-Type = 92 - Multicast Admission Control
* Result= 0x00
* Transaction-ID = Transaction-ID maintained by AN
o a Target TLV identifying the AN Port
o a Command TLV containing:
* a Command Code = Add
* R = 0
* O = 0
* the multicast flow for which the IGMP join was received by AN=
(192.0.2.1, 233.252.2.3).
Le Faucheur, et al. Expires September 10, 2009 [Page 40]
Internet-Draft ANCP Multicast Extensions March 2009
* a Request-Source-IP sub-TLV containing the IGMP join source IP
(192.0.2.100).
The Multicast Admission Control message M1 is illustrated below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=92 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xTBD (Command) TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
6.1.5. Admission Control Reject with NAS Response
The message flow in Figure 13 illustrates the ANCP message flow in
case of a join that is rejected by the NAS because of admission
control and with explicit response from the NAS. In that case, the
multicast flow is not replicated by virtue of the NAS explicitly
signaling to the AN that the multicast flow is not to be replicated.
Le Faucheur, et al. Expires September 10, 2009 [Page 41]
Internet-Draft ANCP Multicast Extensions March 2009
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(Grey-Fl) | Admission |
|-----------+---------->| Control (M1) |
| | |------------------>|
| | | |
| | | Multicast (*)
| | | Replication |
| | | Control (M2) |
| Mcast Grey Flow |<------------------|
| not replicated x |
| | | |
Grey-Fl : Multicast Flow matching an entry in Grey List
(Bandwidth Delegation not activated on AN)
(*) The NAS may optionally seek direction from an external
Autorization/Policy Server
Figure 13: Admission Control Reject with NAS Response
The Multicast Admission Control message M1 contains:
o an ANCP Header with:
* Message-Type = 92 - Multicast Admission Control
* Result= 0x00
* Transaction-ID = Transaction-ID maintained by AN
o a Target TLV identifying the AN Port
o a Command TLV containing:
* a Command Code = Add
* R = 0
* O = 0
* the multicast flow for which the IGMP join was received by AN=
(192.0.2.1, 233.252.2.4).
Le Faucheur, et al. Expires September 10, 2009 [Page 42]
Internet-Draft ANCP Multicast Extensions March 2009
* a Request-Source-IP sub-TLV containing the IGMP join source IP
(192.0.2.100).
The Multicast Admission Control message M1 is illustrated below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=92 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xTBD (Command) TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
The Multicast Replication Control message M2 contains:
o an ANCP Header with:
* Message-Type = 90 - Multicast Replication Control
* Result= 0x00
* Transaction-ID = Transaction-ID maintained by NAS
Le Faucheur, et al. Expires September 10, 2009 [Page 43]
Internet-Draft ANCP Multicast Extensions March 2009
o a Target TLV identifying the AN Port
o a Command TLV containing:
* a Command Code = Admission Control Reject (since in our example
the flow is rejected by NAS because of bandwidth admission
control and not because of conditional access)
* R= 0 (since in our example the flow resources have not been
admitted by NAS)
* O = 0 (since in our example flow accounting is not required)
* the multicast flow (192.0.2.1, 233.252.2.4)
* a Request-Source-IP sub-TLV containing the IGMP join source IP
(192.0.2.100).
The Multicast Admission Control message M2 is illustrated below:
Le Faucheur, et al. Expires September 10, 2009 [Page 44]
Internet-Draft ANCP Multicast Extensions March 2009
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=90 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0010 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xTBD (Command) TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0xTBD|0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
6.2. Example Flows For Bandwidth Delegation
As noted in Section 4.1.1, the operation of bandwidth delegation is
supplemental to the operation of request processing in the absence of
bandwidth delegation. Thus the same flows shown in the previous
section continue to hold, except that the AN does multicast call
admission before doing grey and white list processing. The example
flows of this section are therefore limited to the incremental
operations of bandwidth delegation. They include initial
provisioning, a successful request from the AN for an increase in
delegated bandwidth, an autonomous transfer of the borrowed bandwidth
back to the NAS, and the initiation of the bandwidth reset procedure
(Section 3.9) by the NAS when it finds that the amount of delegated
bandwidth passed by the AN is larger than its current view of that
amount.
Le Faucheur, et al. Expires September 10, 2009 [Page 45]
Internet-Draft ANCP Multicast Extensions March 2009
6.2.1. Activation and Provisioning of Delegated Bandwidth
Activation of bandwidth delegation occurs at the level of the AN as a
whole and is done by including in the Provisioning message a
Bandwidth-Delegation-Control TLV in the Provisioning message with the
E-flag set to 1. The corresponding message flow is illustrated in
Figure 14 .
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | |(M1) Provisioning |
| | | (Mcast S Prof name, |
| | | White List, |
| | | Grey List, |
| | | Black List, |
| | | Bw Del Activated) |
| | |<--------------------|
Figure 14: Provisioning AN with White/Grey/Black Lists for
Conditional Access
In place of the message content shown in Figure 9 we have the
following content within the Provisioning message (illustrating
provisioning of a multicast service profile containing a grey list
with a catch-all statement - i.e., match on any source and any group
address) :
Le Faucheur, et al. Expires September 10, 2009 [Page 46]
Internet-Draft ANCP Multicast Extensions March 2009
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=93 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Service-Prof TLV Type | Mcast-Service-Prof TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLV Type = 0x0001 | sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Multicast service profile name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLV Type = 0x0003 | sub-TLV Length = 0x06 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP ver = 0x00 | List length = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Grp PLen=0x00 | Src PLen=0x00 | Padding = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Band-Del-Control | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved = 0x00 | Reserved = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15
Once bandwidth delegation has been activated, the NAS provisions the
amount of delegated bandwidth for each access line (unless it decides
to rely on default values pre-configured on the AN). This requires a
Port Management message with a Bandwidth-Allocation TLV. The same
Port Management message may be used to provision other information,
such as the multicast service profile name applicable to the access
line. The information flow is therefore similar to that in Figure 10
but illustrated more precisely in Figure 16.
Le Faucheur, et al. Expires September 10, 2009 [Page 47]
Internet-Draft ANCP Multicast Extensions March 2009
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | | |
| | DSL Synch. | |
| |--------------------->| |
| | |(M1)PORT_UP(Port ID) |
| | |-------------------->|
| | | (*)
| | |(M2) PORT_MNGT |
| | | (Port ID, |
| | |Mcast S Profile Name,|
| | |Initial Delegated Bw)|
| | |<--------------------|
(*) The NAS may optionally seek direction from an external
Autorization/Policy Server
Figure 16: Provisioning of Initial Delegated Bandwidth to AN Port
The content of the Port Management message M2 is illustrated below
assuming an initial delegated bandwidth of 8000 kbits/s:
Le Faucheur, et al. Expires September 10, 2009 [Page 48]
Internet-Draft ANCP Multicast Extensions March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Msg Type = 32 |Rslt =1| Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Duration | Func = 8 | X-Func = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Flow Control Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Msg Type = 32 | Tech Type = 5 | Block Len = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs = 2 | Ext Block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x01 | Access-Loop-Cct-ID length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access-Loop-Circuit-ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Bandwidth-Alloc | TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Bandwidth = 8000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Port Management Message Allocating Delegated Bandwidth
6.2.2. Admission Control of White Flow Without Change in Delegated
Bandwidth
The message flow in Figure 18 illustrates the message flow for
admission of a new flow matching the White List when bandwidth
delegation is activated and the AN has sufficient unused bandwidth
within the delegated bandwidth for the new flow. In that case, no
ANCP message needs to be exchanged.
Le Faucheur, et al. Expires September 10, 2009 [Page 49]
Internet-Draft ANCP Multicast Extensions March 2009
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(White-Fl) | |
|-----------+---------->| |
| | | |
| Mcast White-Fl | |
|<======================| |
| | | |
White-Fl : Multicast Flow matching an entry in White List
(Bandwidth Delegation activated on AN)
(*) The NAS may optionally seek direction from an external
Autorization/Policy Server
Figure 18: Admission Control without change in Delegated Bandwidth
6.2.3. Admission Control of White Flow with Increase in Delegated
Bandwidth
The message flow in Figure 19 illustrates the message flow for
admission of a new flow matching the White List when bandwidth
delegation is activated and the AN does not have sufficient unused
bandwidth within the delegated bandwidth for the new flow. The flow
illustrates the case where the AN requests a sufficiently larger
delegated bandwidth and where that request is accepted by the NAS.
Le Faucheur, et al. Expires September 10, 2009 [Page 50]
Internet-Draft ANCP Multicast Extensions March 2009
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(White-Fl) | Bw Reallocation |
|-----------+---------->| Request (M1) |
| | |------------------>|
| | | |
| | | (*)
| | | Bw Transfer (M2) |
| Mcast White-Fl |<------------------|
|<======================| |
| | | |
White-Fl : Multicast Flow matching an entry in White List
(Bandwidth Delegation activated on AN)
(*) The NAS may optionally seek direction from an external
Autorization/Policy Server
Figure 19: Admission Control of White Flow with Increase of Bandwidth
Delegation
Suppose that when the new Join is received, the AN had already
committed all the 8000 kbits/s of its delegated amount to established
multicast flows and the received Join request requires another 2000
kbits/s. The AN issues a Bandwidth Reallocation Request message M1
where the Required Delegated Bandwidth value is set in order to
acquire this amount of additional bandwidth. Since the request is
expressed in terms of total delegated bandwidth, the Required
Delegated Bandwidth value is set by the AN to 10000 kbits/s. Suppose
that the AN is configured with a local policy that causes it to
request enough for one extra channel as a Preferred Delegated
Bandwidth. Then, the Preferred Delegated Bandwidth is set to 12000
kbits/s. This Bandwidth Reallocation Request message M1 has the
following format:
Le Faucheur, et al. Expires September 10, 2009 [Page 51]
Internet-Draft ANCP Multicast Extensions March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | MsgTyp = 94 |Rslt=0 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | AN-allocated Transaction Identifier=100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Request | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Delegated Bandwidth = 10000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Delegated Bandwidth = 12000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Example Bandwidth Reallocation Request Message
In response to this request, we assume that the NAS is willing to
grant the full preferred amount. (It could have granted any value
between 10000 and 12000, or it could have rejected the request.) The
Bandwidth Transfer message M2 sent as a response indicates that the
new delegated bandwidth amount is 12000 kbits/s, as shown in the next
figure.
Le Faucheur, et al. Expires September 10, 2009 [Page 52]
Internet-Draft ANCP Multicast Extensions March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | MsgTyp = 95 |Rslt=3 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier=100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Alloc | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Bandwidth = 12000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Example Bandwidth Transfer Message (Success Response)
6.2.4. Admission Control of Grey Flow Without Change in Delegated
Bandwidth
Figure 22 illustrates the message flow for admission of a new flow
matching the Grey List when bandwidth delegation is activated and the
AN has sufficient unused bandwidth within the delegated bandwidth for
the new flow. The flow is similar to the flow shown in Figure 11 for
the case without bandwidth delegation. The key difference is that
with bandwidth delegation:
o the AN performs bandwidth check before issuing the Admission
Control message M1 to the NAS
o the NAS sets the R flag to 0 in the Command TLV within the
Multicast Replication Control message M2 to indicate that the NAS
has not reserved bandwidth for that flow (since it relies on the
AN to do so via bandwidth delegation).
Le Faucheur, et al. Expires September 10, 2009 [Page 53]
Internet-Draft ANCP Multicast Extensions March 2009
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(Grey-Fl) | |
|-----------+---------->| |
| | | Admission |
| | | Control (M1) |
| | |------------------>|
| | | |
| | | Multicast |
| | | Replication (*)
| | | Control (M2) |
| | | (R=0) |
| | |<------------------|
| Mcast Grey-Fl | |
|<======================| |
| | | |
Grey-Fl : Multicast Flow matching an entry in Grey List
(Bandwidth Delegation activated on AN)
(*) The NAS may optionally seek direction from an external
Autorization/Policy Server
Figure 22: Admission Control of Grey Flow Without Change of Delegated
Bandwidth
6.2.5. Admission Control of Grey Flow with Increase in Delegated
Bandwidth
The message flow in Figure 23 illustrates the message flow for
admission of a new flow matching the Grey List when bandwidth
delegation is activated and the AN does not have sufficient unused
bandwidth within the delegated bandwidth for the new flow. The flow
illustrates the case where the AN requests a sufficiently larger
delegated bandwidth and where that request is accepted by the NAS.
Le Faucheur, et al. Expires September 10, 2009 [Page 54]
Internet-Draft ANCP Multicast Extensions March 2009
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(Grey-Fl) | Bw Reallocation |
|-----------+---------->| Request (M1) |
| | |------------------>|
| | | |
| | | (*)
| | | Bw Transfer (M2) |
| | |<------------------|
| | | |
| | | Admission |
| | | Control (M3) |
| | |------------------>|
| | | |
| | | Multicast |
| | | Replication (*)
| | | Control (M4) |
| | |<------------------|
| Mcast Grey-Fl | |
|<======================| |
| | | |
Grey-Fl : Multicast Flow matching an entry in Grey List
(Bandwidth Delegation activated on AN)
(*) The NAS may optionally seek direction from an external
Autorization/Policy Server
Figure 23: Admission Control of Grey Flow with Increase of Delegated
Bandwidth
6.2.6. Failed Autonomous Bandwidth Transfer With Reset
Suppose the AN decides after some period of time that it should
return 2000 kbits/s of the 4000 kbits/s that it acquired from the NAS
in a previous transaction but have since not been unused. It
therefore issues a Bandwidth Transfer message of its own. This
message differs from the message in Figure 21 in two ways. First,
because this is an autonomous transfer rather than a response, the
Result field in the header is set to Ignore (0x0). Secondly, the
Delegated Bandwidth is reduced to 10000 kbits/s.
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
Le Faucheur, et al. Expires September 10, 2009 [Page 55]
Internet-Draft ANCP Multicast Extensions March 2009
delegated bandwidth is 8000 kbits/s. The 10000 kbits/s appearing in
the Bandwidth Transfer message is higher than this, so there is
clearly a loss of synchronization between the NAS and the AN as to
their respective view of the current delegated bandwidth. The NAS
chooses to initiate the reset procedure, perhaps because it is close
to committing all of its available video bandwidth for unicast
service. As the initial step in this procedure, it issues a
Multicast Status message indicating that a reset of the delegated
amount is required. This is shown in the following figure.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=91 | 0x4 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-info-TLV=TBD | Status-TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rslt Code = xx | Cmd No = 1 | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4) if Length > 0 |
+---------------------------------------------------------------+
| TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Alloc | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount = 8000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Result Code field within the Status-Info TLV contains the value:
delegated bandwidth reset required (0xTBD).
Figure 24: Example Initiation of Delegated Bandwidth Reset
The NAS stops processing video service requests for the given access
line when it sends this message. Similarly, the AN stops processing
multicast video service requests when it receives the message. [To
think about: can service requests that release bandwidth be safely
Le Faucheur, et al. Expires September 10, 2009 [Page 56]
Internet-Draft ANCP Multicast Extensions March 2009
processed? Probably.] The next step is up to the NAS: it sends a
Bandwidth Delegation Query Request message to the AN. The Result
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
the original Bandwidth Transfer message. The message is shown in the
following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | MsgTyp = 96 |Rslt=0 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Example Delegated Bandwidth Query Request Message
The AN returns a Delegated Bandwidth Query Response message showing
that it believes that the amount of delegated bandwidth is 10000
kbits/s and it has committed 8000 kbits/s of it. The Result field in
the header shows Success (0x3) to distinguish the response. [... in
case we decide to make the query bidirectional ...]
Le Faucheur, et al. Expires September 10, 2009 [Page 57]
Internet-Draft ANCP Multicast Extensions March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | MsgTyp = 96 |Rslt=3 | Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Bandwidth-Request | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount = 10000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed amount = 8000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Example Delegated Bandwidth Query Response Message
The NAS decides to reset the delegated bandwidth amount to 8000
kbits/s. It issues a Port Management message looking exactly like
the one in Figure 17. Once it sends this message, it resumes
processing service requests for the access line concerned.
Similarly, the AN resumes request processing after it receives the
Port Management message and resets its view of the current delegated
bandwidth. In the short run, this means that it will have to ask for
more bandwidth if it receives another Join request. [It seems
reasonable that the AN would not do so for a period of time after a
reset or a response to a Bandwidth Reallocation Request that grants
less than the preferred amount. Should we establish a timer?]
The overall message flow for this failed autonomous bandwidth
transfer with reset is illustrated in Figure 27.
Le Faucheur, et al. Expires September 10, 2009 [Page 58]
Internet-Draft ANCP Multicast Extensions March 2009
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<------------>| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| | | Bw Transfer (M1) |
| | |-------------------->|
| | | |
| | | Multicast |
| | | Status (M2) |
| | | (Del Bw Reset Rqd) |
| | |<--------------------|
| | | |
| | | Delegated Bw |
| | | Query request (M3) |
| | |<--------------------|
| | | |
| | | Delegated Bw |
| | |Query response (M4) |
| | | (Committed Bw) |
| | |-------------------->|
| | | (*)
| | |(M5) PORT_MNGT |
| | | (Port ID, |
| | |Mcast S Profile Name,|
| | |Initial Delegated Bw)|
| | |<--------------------|
| | | |
(*) The NAS may optionally seek direction from an external
Autorization/Policy Server
Figure 27: Failed Autonomous Bandwidth Transfer with Reset
Le Faucheur, et al. Expires September 10, 2009 [Page 59]
Internet-Draft ANCP Multicast Extensions March 2009
7. Security Considerations
The security considerations of ANCP are discussed in
[I-D.ietf-ancp-protocol] and in [I-D.ietf-ancp-security-threats].
Le Faucheur, et al. Expires September 10, 2009 [Page 60]
Internet-Draft ANCP Multicast Extensions March 2009
8. IANA Considerations
[This document defines new ANCP messages, TLVs, sub-TLVs, error codes
and Capability Types. The corresponding IANA considerations will be
specified when the proposed extensions are folded into the ANCP
protocol document.]
This document defines the following additional values within the
GSMPv3 Message Type Name Space registry:
+--------------------------------+--------+---------------+
| Message | Number | Source |
+--------------------------------+--------+---------------+
| Multicast Admission Control | 92 | This document |
| | | |
| Provisioning | 93 | This document |
| | | |
| Bandwidth Reallocation Request | 94 | This document |
| | | |
| Bandwidth Transfer | 95 | This document |
| | | |
| Delegated Bandwidth Query | 96 | This document |
+--------------------------------+--------+---------------+
This document defines the following additional values within the ANCP
Multicast Status-Info Result Code Registry:
+------------------------------------+--------+---------------+
| Status | Number | Reference |
+------------------------------------+--------+---------------+
| 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:
Le Faucheur, et al. Expires September 10, 2009 [Page 61]
Internet-Draft ANCP Multicast Extensions March 2009
+--------------------------------+-----------+---------------+
| 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 |
+--------------------------------+-----------+---------------+
Le Faucheur, et al. Expires September 10, 2009 [Page 62]
Internet-Draft ANCP Multicast Extensions March 2009
9. Acknowledgements
The authors would like to acknowledge Wojciech Dec for providing
useful input to this document. Robert Rennison had a major role in
shaping the definition of the Multicast-Service-Profile TLV.
Le Faucheur, et al. Expires September 10, 2009 [Page 63]
Internet-Draft ANCP Multicast Extensions March 2009
10. References
10.1. Normative References
[I-D.ancp-mc-extensions]
Champagne, P., Dec, W., Wadhwa, S., Cnodder, S., and R.
Maglione, "Multicast Control Extensions for ANCP",
draft-ancp-mc-extensions-00 (work in progress), July 2008.
[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-08 (work in progress),
February 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-04 (work in progress),
November 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
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-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.
Le Faucheur, et al. Expires September 10, 2009 [Page 64]
Internet-Draft ANCP Multicast Extensions March 2009
Authors' Addresses
Francois Le Faucheur
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
France
Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com
Roberta Maglione
Telecom Italia
Via Reiss Romoli 274
Torino 10148
Italy
Phone:
Email: roberta.maglione@telecomitalia.it
Tom Taylor
Huawei Technologies
1852 Lorraine Ave
Ottawa, Ontario K1H 6Z8
Canada
Phone: +1 613 680 2675
Email: tom.taylor@rogers.com
Le Faucheur, et al. Expires September 10, 2009 [Page 65]
| PAFTECH AB 2003-2026 | 2026-04-23 04:09:41 |