One document matched: draft-lefaucheur-ancp-mc-extensions-00.txt
ANCP F. Le Faucheur
Internet-Draft Cisco
Intended status: Standards Track R. Maglione
Expires: April 30, 2009 Telecom Italia
T. Taylor
Huawei
October 27, 2008
Additional Multicast Control Extensions for ANCP
draft-lefaucheur-ancp-mc-extensions-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 30, 2009.
Le Faucheur, et al. Expires April 30, 2009 [Page 1]
Internet-Draft ANCP Multicast Extensions October 2008
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ANCP Messages . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 5
3.2. Port Management Message . . . . . . . . . . . . . . . . . 6
3.3. Multicast Admission Control Message . . . . . . . . . . . 6
3.4. Multicast Replication Control Message . . . . . . . . . . 8
3.5. Multicast Status Message . . . . . . . . . . . . . . . . . 9
4. ANCP TLVs and Sub-TLVs . . . . . . . . . . . . . . . . . . . . 11
4.1. Multicast-Service-Profile TLV . . . . . . . . . . . . . . 11
4.2. Service-Profile TLV . . . . . . . . . . . . . . . . . . . 14
4.3. Bandwidth-Delegation-Control TLV . . . . . . . . . . . . . 14
4.4. Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 15
4.5. Request-Source-IP sub-TLV . . . . . . . . . . . . . . . . 15
4.6. Request-Source-MAC sub-TLV . . . . . . . . . . . . . . . . 16
4.7. Status-Info TLV and Error Codes . . . . . . . . . . . . . 17
5. New Capabilities . . . . . . . . . . . . . . . . . . . . . . . 18
6. Example of Messages and Message Flows . . . . . . . . . . . . 19
6.1. Multicast Conditional Access and CAC without AN
Bandwidth Delegation . . . . . . . . . . . . . . . . . . . 19
6.1.1. List/Profile Provisioning . . . . . . . . . . . . . . 19
6.1.2. Profile Mapping . . . . . . . . . . . . . . . . . . . 20
6.1.3. Successful Join/Leave Operations . . . . . . . . . . . 21
6.1.4. Admission Control Reject . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Normative References . . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
Le Faucheur, et al. Expires April 30, 2009 [Page 2]
Internet-Draft ANCP Multicast Extensions October 2008
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 without Bandwidth delegation use case).
Le Faucheur, et al. Expires April 30, 2009 [Page 3]
Internet-Draft ANCP Multicast Extensions October 2008
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].
Le Faucheur, et al. Expires April 30, 2009 [Page 4]
Internet-Draft ANCP Multicast Extensions October 2008
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.
On receipt of the Provisioning message, the AN MUST:
o ignore the Result field
Le Faucheur, et al. Expires April 30, 2009 [Page 5]
Internet-Draft ANCP Multicast Extensions October 2008
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.4 in the Port Management message.
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 or 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 or a Status
message (as discussed in 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 three
TLVs:
Le Faucheur, et al. Expires April 30, 2009 [Page 6]
Internet-Draft ANCP Multicast Extensions October 2008
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.5) 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
instances are ignored.
* a Request-Source-MAC sub-TLV (as defined in Section 4.6) 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
Le Faucheur, et al. Expires April 30, 2009 [Page 7]
Internet-Draft ANCP Multicast Extensions October 2008
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
The [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 instructs 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.
This section specifies another use of the Multicast Replication
Control Message in order to support the Multicast Admission Control
use cases defined in [I-D.ietf-ancp-framework]. To support that use
case, the Multicast Replication Control message can also used by the
NAS in response to a Multicast Admission Control 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
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
Le Faucheur, et al. Expires April 30, 2009 [Page 8]
Internet-Draft ANCP Multicast Extensions October 2008
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 MUST generate a Multicast Status Message in
response to the Multicast Admission Control Message. The 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.
* MUST contain a Status TLV with a Result Code set to "Admission
Control reject" or "Conditional Access reject" or "Admission
Control and Conditional Access reject" (see Section 4.7).
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 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.
* 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.
This section specifies other uses of the Multicast Status Message in
order to support the Multicast Admission Control use cases defined in
[I-D.ietf-ancp-framework].
First, the Multicast Status message is used by the NAS in some
situations as specified in Section 3.4 in response to a Multicast
Admission Control message from the AN.
Le Faucheur, et al. Expires April 30, 2009 [Page 9]
Internet-Draft ANCP Multicast Extensions October 2008
Secondly, 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
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 Status Message with a Result set to Failure and a
Status TLV indicating the reason of the failure (e.g. 0x09 - Target
port down).
Le Faucheur, et al. Expires April 30, 2009 [Page 10]
Internet-Draft ANCP Multicast Extensions October 2008
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Mcast Service Profile | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Service-Profile-Name Sub-TLV |
| Sub-TLV tag = 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| White-List Sub-TLV |
| Sub-TLV tag = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Grey-List Sub-TLV |
| Sub-TLV tag = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Black-List Sub-TLV |
| Sub-TLV tag = 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each of the four sub-TLVs begins with a 32-bit header consisting of a
16-bit sub-TLV tag followed by a 16-bit length field giving the
amount of data following this sub-TLV header in octets. The tag
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. 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. Those sub-TLVs present MUST be ordered
by increasing tag value.
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
target within a Port Management message (see Section 3.2).
Le Faucheur, et al. Expires April 30, 2009 [Page 11]
Internet-Draft ANCP Multicast Extensions October 2008
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 as described below.
[***Will the addresses in a given profile either be all IPv4 or all
IPv6, or can they be mixed? If they're all the same, we should have
an address-type sub-TLV following the profile name.***]
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 non-zero mask values. Multicast flow fields MUST be
placed consecutively within the sub-TLV without intervening padding.
A multicast flow field consists of a three octet header followed by
one (in case of ASM) or two (in case of SSM) address values as shown
below:
+-+-+-+-+-+-+-+-+
| IP ver |
+-+-+-+-+-+-+-+-+
| Group Mask |
+-+-+-+-+-+-+-+-+
| Source Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (multicast) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (unicast, SSM only) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The header defines the IP version of the group and source addresses,
the number of unspecified low-order bits of the group address, and
the number of unspecified low-order bits of the source address. The
IP version octet MUST have value 0x00 for IPv4 addresses, 0x01 for
IPv6 addresses. A value of 0xFF for either the Group Mask or the
Source Mask indicates that any value of the corresponding address
will match (wild card). If the value 0xFF is provided for a
particular mask, the corresponding address MUST be omitted from the
field contents. In particular, a value of 0xFF for the Source Mask
indicates an ASM multicast entry, and the Source Address will be
absent.
The total length of a multicast address field has the following
possible values:
Le Faucheur, et al. Expires April 30, 2009 [Page 12]
Internet-Draft ANCP Multicast Extensions October 2008
o 3 octets (the header only) for a totally wildcarded entry;
o 7 octets for an IPv4 ASM entry or an IPv4 SSM entry with
wildcarded group address;
o 11 octets for an IPv4 SSM entry with no wildcarding;
o 19 octets for an IPv6 ASM entry or an IPv6 SSM entry with
wildcarded group address;
o 35 octets for an IPv6 SSM entry with no wildcarding.
When a given multicast service profile has been activated on a given
AN port (using the Port Management message as defined in
Section 3.2):
o On receipt of a join message on an Access Port whose multicast
flow matches the White List, the AN autonomously starts
replicating multicast traffic. On receipt of a leave message on
an Access Port whose multicast flow matches the White List, the AN
autonomously stops replicating multicast traffic.
o On receipt of a join message on an Access Port whose multicast
flow matches the Grey List, the AN uses ANCP to query the NAS,
that in turn will respond to the AN indicating whether the join is
to be honored (and hence replication performed by the AN) or
denied (and hence replication not performed by the AN.) On
receipt of a leave message on an Access Port whose multicast flow
matches the Grey List, the AN autonomously stops replicating
multicast traffic and the AN notifies the NAS.
o On receipt of a join message on an Access Port whose multicast
flow matches the Black List, the AN autonomously discards the join
message.
If the requested multicast flow matches multiple lists associated
with the Access Port, then the most specific match will be considered
by the AN. If the most specific match occurs in multiple lists, the
Black list entry takes precedence over the Grey list, which takes
precedence over the White list. In this context, the most specific
match is defined as:
o first, most specific match on the multicast flow address (i.e. on
G of <S,G>)
o then, most specific match on the multicast source address (i.e. on
S of <S,G>)
Le Faucheur, et al. Expires April 30, 2009 [Page 13]
Internet-Draft ANCP Multicast Extensions October 2008
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.
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = Band-Del-Control | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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::
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
Le Faucheur, et al. Expires April 30, 2009 [Page 14]
Internet-Draft ANCP Multicast Extensions October 2008
to admission control according to the Bandwidth Delegation
procedures defined in [I-D.ietf-ancp-framework].
4.4. 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-
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.5. 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:
Le Faucheur, et al. Expires April 30, 2009 [Page 15]
Internet-Draft ANCP Multicast Extensions October 2008
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:
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.6. 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:
Le Faucheur, et al. Expires April 30, 2009 [Page 16]
Internet-Draft ANCP Multicast Extensions October 2008
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.7. Status-Info TLV and Error Codes
[I-D.ietf-ancp-protocol] defines the Status-Info TLV that can be used
in a Multicast Status Message. The Status-Info TLV contains an Error
Code field and a number of values are already defined for this field.
The present document specifies the following new additional values
for the Error Code of the Status-Info TLV:
0x11 - Admission Control reject
0x12 - Conditional Access reject
0x13 - Admission Control and Conditional Access reject
Le Faucheur, et al. Expires April 30, 2009 [Page 17]
Internet-Draft ANCP Multicast Extensions October 2008
5. New Capabilities
[I-D.ietf-ancp-protocol] defines a capability negotiation mechanism
as well as a number of capabilities. This document defines two new
capabilities for support of the Multicast Admission Control use case:
o Capability Type : Multicast Admission Control without Bandwidth
Delegation = 0x05 (TBC)
Length (in bytes) : 0
Capability Data : NULL
o Capability Type : Multicast Admission Control without and with
Bandwidth Delegation = 0x06 (TBC)
Length (in bytes) : 0
Capability Data : NULL
A NAS or AN supporting the "Multicast Admission Control without
Bandwidth Delegation" capability MUST support the Multicast Admission
Control Message, the Multicast Replication Message and the Multicast
Status Message.
A NAS or AN supporting the "Multicast Admission Control without and
with Bandwidth Delegation" capability MUST support the Multicast
Admission Control Message, the Multicast Replication Message, the
Multicast Status Message as well as the (to be defined) additional
messages that are required to support the "Multicast Admission
Control with Bandwidth Delegation" use case.
Le Faucheur, et al. Expires April 30, 2009 [Page 18]
Internet-Draft ANCP Multicast Extensions October 2008
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 1.
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | |(M1) Provisioning |
| | | (Mcast S Prof name, |
| | | White List, |
| | | Grey List, |
| | | Black List, |
| | | Bw Del Deactivated) |
| | |<--------------------|
Figure 1: 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 April 30, 2009 [Page 19]
Internet-Draft ANCP Multicast Extensions October 2008
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 Back-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0xFF | 0xFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 2.
Le Faucheur, et al. Expires April 30, 2009 [Page 20]
Internet-Draft ANCP Multicast Extensions October 2008
+----------+ +---------+ +-----+ +-----+
|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 2: Associating Profile ID to AN Port
6.1.3. Successful Join/Leave Operations
The message flows in Figure 3 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 April 30, 2009 [Page 21]
Internet-Draft ANCP Multicast Extensions October 2008
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(Grey-Fl) | Admission |
|-----------+---------->| Control (M1) |
| | |------------------>|
| | | |
| | | Multicast |
| | | Replication (*)
| | | Control (M2) |
| Mcast Grey Flow |<------------------|
|<======================+ |
| | | |
~ ~ ~ ~
| | | |
| 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 3: Multicast Conditional Access
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 April 30, 2009 [Page 22]
Internet-Draft ANCP Multicast Extensions October 2008
* 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 April 30, 2009 [Page 23]
Internet-Draft ANCP Multicast Extensions October 2008
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)
The Multicast Admission Control Message M2 is illustrated below:
Le Faucheur, et al. Expires April 30, 2009 [Page 24]
Internet-Draft ANCP Multicast Extensions October 2008
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
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:
* a Command Code = Delete
* R = 0
Le Faucheur, et al. Expires April 30, 2009 [Page 25]
Internet-Draft ANCP Multicast Extensions October 2008
* O = 0
* the multicast flow for which the IGMP leave was received by AN=
(192.0.2.1, 233.252.2.2)
* a Request-Source-IP sub-TLV containing the IGMP join source IP
(192.0.2.100).
The Multicast Admission Control Message M3 is illustrated below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=92 | 0x00 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0002 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xTBD (Command) TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x02 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
|Type = 0xTBD (Request-S.) TLV | Request-S.-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = (Request-S-IP) sub-TLV | Request-S-IP sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Source : 192.0.2.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
Le Faucheur, et al. Expires April 30, 2009 [Page 26]
Internet-Draft ANCP Multicast Extensions October 2008
6.1.4. Admission Control Reject
The message flow in Figure 4 illustrates the ANCP message flow in
case of a join that is rejected by the NAS because of admission
control.
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(Grey-Fl) | Admission |
|-----------+---------->| Control (M1) |
| | |------------------>|
| | | |
| | | Multicast (*)
| | | Status (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 4: Multicast Conditional Access
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
Le Faucheur, et al. Expires April 30, 2009 [Page 27]
Internet-Draft ANCP Multicast Extensions October 2008
* O = 0
* the multicast flow for which the IGMP join was received by AN=
(192.0.2.1, 233.252.2.3).
* 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
The Multicast Status Message M2 contains:
o an ANCP Header with:
Le Faucheur, et al. Expires April 30, 2009 [Page 28]
Internet-Draft ANCP Multicast Extensions October 2008
* Message-Type = 91 - Status
* Result= Failure
* Transaction-ID = Transaction-ID contained in the Multicast
Admission Control message that triggered this Multicast Satus
message
o a Status-Info TLV containing:
* Result Code = Admission Control reject
o a Target TLV identifying the AN Port
The Multicast Status Message M2 is illustrated below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=91 | 0x03 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Status-Info | Status-Info TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|adm cont reject| 0x00 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1000 (Target) | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Faucheur, et al. Expires April 30, 2009 [Page 29]
Internet-Draft ANCP Multicast Extensions October 2008
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 April 30, 2009 [Page 30]
Internet-Draft ANCP Multicast Extensions October 2008
8. IANA Considerations
This document defines new ANCP messages, TLVs, sub-TLVs and error
codes. The corresponding IANA considerations will be defined if/when
the proposed extenesions are folded in the ANCP protocol document.
Le Faucheur, et al. Expires April 30, 2009 [Page 31]
Internet-Draft ANCP Multicast Extensions October 2008
9. Acknowledgements
The authors would like to acknowledge Wojciech Dec for providing
useful input to this document.
Le Faucheur, et al. Expires April 30, 2009 [Page 32]
Internet-Draft ANCP Multicast Extensions October 2008
10. References
10.1. Normative References
[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.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-06 (work in progress), May 2008.
[I-D.ietf-ancp-protocol]
Moisand, J., Subramanian, S., Haag, T., Voigt, N., and S.
Wadhwa, "Protocol for Access Node Control Mechanism in
Broadband Networks", draft-ietf-ancp-protocol-03 (work in
progress), July 2008.
[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-06 (work in progress),
October 2008.
[IANAAEA] "http://www.iana.org/assignments/address-family-numbers",
2005.
Le Faucheur, et al. Expires April 30, 2009 [Page 33]
Internet-Draft ANCP Multicast Extensions October 2008
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 April 30, 2009 [Page 34]
Internet-Draft ANCP Multicast Extensions October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Le Faucheur, et al. Expires April 30, 2009 [Page 35]
| PAFTECH AB 2003-2026 | 2026-04-23 04:17:33 |