Internet Engineering Task Force (IETF) F. Le Faucheur
Request for Comments: 7256 R. Maglione
Updates: 6320 Cisco
Category: Standards Track T. Taylor
ISSN: 2070-1721 Huawei
July 2014Multicast Control Extensions for the Access Node Control Protocol (ANCP)
Abstract
This document specifies the extensions to the Access Node Control
Protocol (ANCP) (RFC 6320) required for support of the multicast use
cases defined in the Access Node Control Protocol framework document
(RFC 5851) and one additional use case described in this document.
These use cases are organized into the following ANCP capabilities:
o multicast replication initiated by the Network Access Server
(NAS);
o conditional access and admission control with white and black
lists;
o conditional access and admission control with grey lists;
o bandwidth delegation; and
o committed bandwidth reporting.
These capabilities may be combined according to the rules given in
this specification.
This document updates RFC 6320 by assigning capability type 3 to a
capability specified in this document and by changing the starting
point for IANA allocation of result codes determined by IETF
Consensus from 0x100 to 0x64.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7256.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................51.1. A Note on Scope ............................................72. Terminology .....................................................73. Multicast Use Cases .............................................73.1. NAS-Initiated Multicast Replication Control Use Case .......83.1.1. Goals ...............................................83.1.2. Message Flow ........................................93.2. Conditional Access and Admission Control Use Case ..........93.2.1. Goals ...............................................93.2.2. Message Flow .......................................103.3. Multicast Flow Reporting Use Case .........................113.3.1. Goals ..............................................113.3.2. Message Flow .......................................113.4. Committed Bandwidth Reporting Use Case ....................113.4.1. Goals ..............................................113.4.2. Message Flow .......................................124. ANCP Messages ..................................................134.1. Provisioning Message ......................................13
6.1.2. Protocol Requirements for Committed
Multicast Bandwidth Reporting ......................546.1.3. Protocol Requirements for Conditional
Access and Admission Control with White
and Black Lists ....................................556.1.4. Protocol Requirements for Conditional
Access and Admission Control with Grey Lists .......566.1.5. Protocol Requirements for Bandwidth Delegation .....576.2. Capability-Specific Procedures for Providing
Multicast Service .........................................576.2.1. Procedures for NAS-Initiated Multicast
Replication ........................................586.2.2. Procedures for Committed Bandwidth Reporting .......586.2.3. Procedures for Conditional Access and
Admission Control with Black and White Lists .......596.2.4. Procedures for Conditional Access and
Admission Control with Grey Lists ..................616.2.5. Procedures for Bandwidth Delegation ................636.3. Combinations of Multicast Capabilities ....................646.3.1. Combination of Conditional Access and
Admission Control with White and Black Lists
and Conditional Access and Admission Control
with Grey Lists ....................................646.3.2. Combination of Conditional Access and
Admission Control with Bandwidth Delegation ........656.3.3. Combination of NAS-Initiated Replication
with Other Capabilities ............................656.3.4. Combinations of Committed Bandwidth
Reporting with Other Multicast Capabilities ........667. Miscellaneous Considerations ...................................667.1. Report Buffering Considerations ...........................667.2. Congestion Considerations .................................678. Security Considerations ........................................679. IANA Considerations ............................................6910. Acknowledgements ..............................................7211. References ....................................................7311.1. Normative References .....................................7311.2. Informative References ...................................73Appendix A. Example of Messages and Message Flows ................75A.1. Provisioning Phase ........................................75A.2. Handling Grey-Listed Flows ................................81A.3. Handling White-Listed Flows ...............................87A.4. Handling of Black-Listed Join Requests ....................92A.5. Handling of Requests to Join and Leave the On-Line Game ...92A.6. Example Flow for Multicast Flow Reporting .................95
1. Introduction
[RFC5851] defines a framework and requirements for an Access Node
(AN) 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. [RFC6320] specifies a protocol for Access Node Control
in broadband networks in line with this framework.
[RFC6320] supports, specifically for DSL access, three use cases
defined in [RFC5851]: the Topology Discovery use case, the Line
Configuration use case, and the Remote Connectivity Test use case.
However, it does not support the multicast use cases defined in
[RFC5851]. The present document specifies the extensions to the
Access Node Control Protocol required for support of these multicast
use cases. In addition, it supports the Committed Bandwidth
Reporting use case, described below. In terms of ANCP, these use
cases are organized into five capabilities:
o NAS-initiated multicast replication;
o conditional access and admission control with white and black
lists;
o conditional access and admission control with grey lists;
o bandwidth delegation; and
o committed bandwidth reporting.
NAS-initiated multicast replication assumes that multicast join and
leave requests are terminated on the NAS or that the NAS receives
requests to establish multicast sessions through other means (e.g.,
application-level signaling). The NAS sends commands to the AN to
start or stop replication of specific multicast flows on specific
subscriber ports. This use case is described briefly in the next-to-
last paragraph of Section 3.4 of [RFC5851].
Conditional access is described in Section 3.4.1 of [RFC5851].
Section 3.4.2.2 of [RFC5851] mentions a way in which conditional
access can be combined with admission control to allow best-effort
multicast flows, and Section 3.4.2.3 points out the necessary
conditions for using both conditional access and admission control.
In the case of "conditional access and admission control with white
and black lists", multicast join and leave requests are terminated at
the AN and accepted or ignored in accordance with the direction
provided by white and black lists, respectively. The white and black
lists are provisioned per port at startup time and may be modified
thereafter. The NAS may combine conditional access with admission
control of white-listed flows by appropriate provisioning.
Conditional access and admission control with grey lists is similar
to conditional access and admission control with white lists, except
that before accepting any request matching a grey list entry, the AN
sends a request to the NAS for permission to replicate the flow.
Again, the NAS can enable admission control of grey-listed flows at
the AN.
Bandwidth delegation is described in Section 3.4.2.1 of [RFC5851].
It allows flexible sharing of total video bandwidth on an access line
between the AN and the NAS. One application of such bandwidth
sharing is where the AN does multicast admission control, while the
NAS or Policy Server does unicast admission control. In that case,
bandwidth delegation allows dynamic sharing of bandwidth between
unicast and multicast video traffic on each access line.
Committed bandwidth reporting is described in Section 3.4. The AN
reports the amount of multicast bandwidth it has granted to a given
access line each time that value changes. These reports may be
buffered for a NAS-provisionable interval so that reports for
multiple access lines can be bundled into the same message.
The formal specification of the behaviors associated with each of
these capabilities, singly and in combination, is given in Section 6.
In addition to the multicast service processing behavior just
sketched, the definition of each capability includes support for the
multicast accounting and reporting services described in
Section 3.4.3 of [RFC5851]. Because of this common content and
because of other protocol overlaps between the different
capabilities, the protocol descriptions for the multicast extensions
specified in this document are merged into a single non-redundant
narrative. Tables in Section 6 then indicate the specific sub-
sections of the protocol description that have to be implemented to
support each capability.
This document updates RFC 6320 by assigning capability type 3 to the
NAS-initiated multicast replication capability and by changing the
starting point for IANA allocation of result codes determined by IETF
Consensus from 0x100 to 0x64.
1.1. A Note on Scope
The requirements in [RFC5851] were formulated with the IPTV
application in mind. Two basic assumptions underlie the use case
descriptions:
o that the Home Gateway operates in bridged mode, and
o that multicast signaling uses IGMP ([RFC2236] [RFC3376]) or
Multicast Listener Discovery (MLD) [RFC3810] rather than PIM
[RFC4601].
Without the first assumption the AN may lose sight of individual
subscriber devices making requests for multicast service. This has a
very minor effect on the capabilities described below but prevents
the application of per-device policies at the NAS. Changing the
second assumption would require that, in applications where the AN is
responsible for snooping IGMP and MLD, it now also monitors for PIM
signaling. The capabilities described in the present document do not
depend explicitly on what type of multicast signaling is used, but
the multiple phases of PIM setup could add complexity to their
implementation.
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].
This document uses the terms "connection admission control" ("CAC" or
simply "admission control") and "conditional access" as they are used
in [RFC5851].
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".
3. Multicast Use Cases
Quoting from [RFC5851]:
... the Access Node, aggregation node(s), and the NAS must all be
involved in the multicast replication process. This prevents
several copies of the same stream from being sent within the
access/aggregation network. In case of an Ethernet-based access/
aggregation network, this may, for example, be achieved by means
of IGMP snooping or IGMP proxy in the Access Node and aggregation
node(s).
By introducing IGMP processing in the access/aggregation nodes,
the multicast replication process is now divided between the NAS,
the aggregation node(s), and Access Nodes. In order to ensure
backward compatibility with the ATM-based model, the NAS,
aggregation node, and Access Node need to behave as a single
logical device. This logical device must have exactly the same
functionality as the NAS in the ATM access/aggregation network.
The Access Node Control Mechanism can be used to make sure that
this logical/functional equivalence is achieved by exchanging the
necessary information between the Access Node and the NAS.
[RFC5851] describes the use cases for ANCP associated with such
multicast operations and identifies the associated ANCP requirements.
This section describes a subset of these use cases as background to
facilitate reading of this document, but the reader is referred to
[RFC5851] for a more exhaustive description of the ANCP multicast use
cases. Detailed example message flows can also be found in
Appendix A.
In the diagrams below, participation of the Home Gateway is optional,
depending on whether it is operating in bridged or routed mode. Note
that devices behind the Home Gateway may require the Home Gateway to
operate in routed mode to ensure that they can obtain access to non-
IPTV multicast services.
3.1. NAS-Initiated Multicast Replication Control Use Case
3.1.1. Goals
One option for multicast handling is for the subscriber to
communicate the join/leave information to the NAS. This can be done,
for instance, by terminating all subscriber IGMP ([RFC3376]) or MLD
([RFC2710] [RFC3810]) signaling on the NAS. Another example could be
a subscriber using some form of application-level signaling, which is
redirected to the NAS. In any case, this option is transparent to
the access and aggregation network. In this scenario, the NAS uses
ANCP to create and remove replication state in the AN for efficient
multicast replication. Thus, the NAS only sends a single copy of the
multicast stream towards the AN, which, in turn, performs replication
to multiple subscribers as instructed by the NAS via ANCP. The NAS
performs conditional access and admission control when processing
multicast join requests and only creates replication state in the AN
if admission succeeds.
3.1.2. Message Flow
With the NAS-initiated use case, a Multicast Replication Control
message is sent by the NAS to the AN with a directive to either join
or leave one (or more) multicast flow(s). In the example message
flow, the AN uses a Generic Response message to convey the outcome of
the directive. Figure 1 illustrates such an ANCP message exchange as
well as the associated AN behavior.
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<-------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | (*)
| | | Multicast-Replication-Ctl |
| | | (Target, add, Flow 1) |
| | |<--------------------------|
| Mcast Flow 1 | |
|<===========+==============+ |
| | | Generic Response |
| | |-------------------------->|
| | | |
| | | |
~ ~ ~ ~
| | | |
| | | Multicast-Replication-Ctl |
| | | (Target,delete, Flow 1) |
| | |<--------------------------|
| | | |
| <Stop Replication of X |
| Mcast Flow 1> | Generic Response |
| | |-------------------------->|
(*) The NAS may optionally seek direction from an external
Authorization/Policy Server before admitting the flow.
Figure 1: NAS-Initiated Multicast Replication Control3.2. Conditional Access and Admission Control Use Case
3.2.1. Goals
One option for multicast handling is for the access/aggregation nodes
to participate in IGMP/MLD processing (e.g., via IGMP/MLD snooping).
In this scenario, on detecting a join/leave request from an end user
for a multicast flow (in the grey list), the AN uses ANCP to request
a conditional access and admission control decision from the NAS. In
turn, after conditional access and admission control checks, the NAS
uses ANCP to instruct the AN to change the replication states
accordingly.
3.2.2. Message Flow
For support of the conditional access and admission control use case,
on detection of an IGMP/MLD join request, the AN sends a Multicast
Admission Control message to the NAS to request a conditional access
and admission control check. In the case of a positive outcome, the
NAS sends a Multicast Replication Control message to the AN with a
directive to replicate the multicast flow to the corresponding user.
Similarly, on detection of an IGMP/MLD leave, a Multicast Admission
Control message is sent by the AN to the NAS to keep the NAS aware of
user departure for the flow. This message flow is illustrated in
Figure 2.
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(Gr-Flow1) | Multicast-Admission-Crl |
|------------+---------->| (Target,add,Gr-Flow1) |
| | |-------------------------->|
| | | (*)
| | | Multicast-Replication-Crl |
| | | (Target,add,Gr-Flow1) |
| | |<--------------------------|
| Mcast Gr-Flow1 | |
|<===========+===========+ |
| | | |
~ ~ ~ ~
| | | |
| Leave(Gr-Flow1) | Multicast-Admission-Crl |
|------------+---------->| (Target,delete,Gr-Flow1) |
| | |-------------------------->|
| <Stop Replication of X |
| Mcast Gr-Flow1> | |
| | | |
Gr-Flow1: a multicast flow matching the grey list for that port
(*) The NAS may optionally seek direction from an external
Authorization/Policy Server before admitting the flow.
Figure 2: Multicast Conditional Access and Admission Control
3.3. Multicast Flow Reporting Use Case
3.3.1. Goals
The multicast flow reporting use case allows the NAS to
asynchronously query the AN to obtain an instantaneous status report
related to multicast flows currently replicated by the AN.
3.3.2. Message Flow
The NAS sends a Multicast Flow Query Request message to the AN in
order to query the AN about information such as which multicast flows
are currently active on a given AN port or which ports are currently
replicating a given multicast flow. The AN conveys the requested
information to the NAS in a Multicast Flow Query Response message.
This message flow is illustrated in Figure 3.
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast Flow |
| | | Query Request |
| | |<------------------|
| | | |
| | | Multicast Flow |
| | | Query Response |
| | |------------------>|
| | | |
| | | |
Figure 3: Multicast Flow Reporting3.4. Committed Bandwidth Reporting Use Case
3.4.1. Goals
The committed bandwidth reporting use case allows the NAS to maintain
current awareness of how much multicast bandwidth the AN has
committed to a given access line, so that the NAS can adjust its
forwarding scheduler to ensure the associated QoS. Note that this
involves a finer level of detail than provided by bandwidth
delegation, since the amount of delegated bandwidth is an upper limit
on the amount of bandwidth committed rather than an actual value. To
reduce the volume of messaging, reports from the AN may be buffered
so that one message reports on changes for multiple access lines.
4. 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.
Unless stated otherwise, receivers MUST ignore message contents that
are not supported by the set of capabilities negotiated between the
NAS and the Access Node.
4.1. Provisioning Message
Section 4.1 of [RFC6320] defines the Provisioning message that is
sent by the NAS to the AN to provision information in the AN.
The present document specifies that the Provisioning message MAY be
used by the NAS to provision multicast-related information (e.g.,
multicast service profiles). The ANCP Provisioning message payload
MAY contain:
o one or more instances of the Multicast-Service-Profile TLV. The
Multicast-Service-Profile TLV is defined in the present document
in Section 5.1. Each instance of the Multicast-Service-Profile
TLV contains a multicast service profile name and one or more list
actions. A list action consists of an action (add, delete,
replace), a list type (white, black, or grey), and list content
(multicast source and group addresses).
o an instance of the White-List-CAC TLV. The White-List-CAC TLV is
defined in Section 5.6. If present, this TLV indicates that the
AN is required to do admission control before replicating white-
listed flows.
o an instance of the MRepCtl-CAC TLV. The MRepCtl-CAC TLV is
defined in Section 5.7. If present, this TLV indicates that the
AN is required to do admission control before replicating flows
specified in Multicast Replication Control messages.
o an instance of the Report-Buffering-Time TLV. The Report-
Buffering-Time TLV is defined in Section 5.13. If present, this
TLV indicates Committed Bandwidth Report messages should be
buffered for the amount of time given by the TLV before being
transmitted to the NAS.
See Section 6 for information on which multicast capabilities require
support of these TLVs in the Provisioning message.
4.1.1. Sender Behavior
When directed by the Policy Server or by management action, the NAS
sends the Provisioning message to initially provision or to update
the white, black, and/or grey multicast channel lists associated with
a set of named multicast service profiles or to direct the AN to
perform admission control for specific classes of flows.
To provision or update a multicast service profile, the NAS MUST
include within the message one or more instances of the Multicast-
Service-Profile TLV specifying the content to be provisioned or
updated. The NAS MUST NOT include any list type (white, black, or
grey) that is not supported by the set of multicast capabilities
negotiated between the NAS and the AN. The NAS MUST NOT use the
Provisioning message to send instances of the Multicast-Service-
Profile TLV to the AN unless the Multicast-Service-Profile TLV is
supported by the set of multicast capabilities negotiated between the
NAS and the AN.
To require admission control to be performed at the AN on white-
listed flows, the NAS MUST include a copy of the White-List-CAC TLV
in the Provisioning message. The White-List-CAC TLV MUST NOT be
provided unless the negotiated set of capabilities includes
conditional access and admission control with white and black lists.
To require admission control to be performed at the AN on grey-listed
flows or on NAS-initiated flows, the NAS MUST include a copy of the
MRepCtl-CAC TLV in the Provisioning message. The MRepCtl-CAC TLV
MUST NOT be provided unless the negotiated set of capabilities
includes NAS-initiated multicast replication or conditional access
and admission control with grey lists.
To require buffering of Committed Bandwidth Report messages so that
reports for multiple access lines can be included in the same
message, the NAS MUST include a copy of the Report-Buffering-Time TLV
containing a non-zero time value in a Provisioning message sent to
the AN. The Report-Buffering-Time TLV MUST NOT be provided unless
the negotiated set of capabilities includes committed bandwidth
reporting.
4.1.2. Receiver Behavior
The receiving AN provisions/updates the white, black, and/or grey
lists associated with the multicast service profile names contained
in the Multicast-Service-Profile TLV instances within the message
according to the contents of the associated List-Action TLVs. The AN
MUST process List-Action TLVs in the order in which they appear
within the message. In keeping with the general rule stated in
Section 4, the AN MUST ignore instances of the List-Action TLV
referring to any list type (white, black, or grey) that is not
supported by the set of multicast capabilities negotiated between the
NAS and the AN.
When a new multicast service profile is identified by a Multicast-
Service-Profile TLV, the initial state of all lists associated with
that profile according to the negotiated set of multicast
capabilities is empty until changed by the contents of Multicast-
Service-Profile TLVs.
The receipt of a Provisioning message containing updates to an
existing multicast service profile subsequent to startup will cause
the AN to review the status of active flows on all ports to which
that profile has been assigned. For further details, see Section 6.
If the White-List-CAC and/or MRepCtl-CAC TLV is present in the
Provisioning message and the respective associated capabilities have
been negotiated, the AN prepares (or continues) to do admission
control on the indicated class(es) of flow. If one or both of these
TLVs was present in an earlier Provisioning message but is absent in
the latest message received, the AN ceases to do admission control on
the indicated class(es) of flow.
The buffering time specified in an instance of the Report-Buffering-
Time TLV will not be applied until the current accumulation process
of Committed Bandwidth Report messages finishes.
As indicated in [RFC6320], the AN MUST NOT reply to the Provisioning
message if it processed it successfully. If an error prevents
successful processing of the message content, the AN MUST return a
Generic Response message as defined in [RFC6320], containing a
Status-Info TLV with the appropriate content describing the error.
For this purpose, the presence of a list type in a Multicast-Service-
Profile TLV, which was ignored because it was not supported by the
negotiated set of capabilities, is not considered to be an error.
4.2. Port Management Message
As specified in [RFC6320], the NAS may send DSL line configuration
information to the AN (ANCP-based DSL line configuration use case)
using ANCP Port Management messages. See Section 7.3 of [RFC6320]
for the format of the Port Management message in that usage.
This document specifies that the Port Management message MAY be used
to convey either or both of the following TLVs:
o Multicast-Service-Profile-Name TLV (defined in Section 5.2). This
TLV associates a Multicast Service Profile with the access line
specified by the extension block and, in the case of white and
black lists, delegates conditional access to the AN for the
specified access line and channels.
o Bandwidth-Allocation TLV (defined in Section 5.5). This TLV
specifies the total multicast bandwidth available to the AN for
admission control at the access line.
When the Port Management message is used for this purpose:
o the Function field in the Port Management message MUST be set to
8, "Configure Connection Service Data".
o the message MUST include TLV(s) to identify the access line
concerned. If the access line is a DSL loop, the line-identifying
TLV(s) MUST be as specified in Section 5.1.2 of [RFC6320]. For
non-DSL access lines, the appropriate alternative line-identifying
TLV(s) MUST be present. Line configuration data other than the
two TLVs listed in the previous paragraph MAY be present.
4.2.1. Sender Behavior
The NAS sends the Port Management message at startup time to
initialize parameters associated with the access line specified in
the message and with the multicast capabilities negotiated between
the NAS and the AN. The NAS MAY send additional Port Management
messages subsequent to startup, to update or, in the case of the
Bandwidth-Allocation TLV, reset these parameters. If the NAS
includes a Multicast-Service-Profile-Name TLV in the Port Management
message, the name MUST match a profile name provided in a Multicast-
Service-Profile TLV in a prior Provisioning message. The NAS MUST
NOT include a TLV unless it is supported by the set of multicast
capabilities negotiated between the NAS and the AN. See Section 6
for further information.
4.2.2. Receiver Behavior
If the Port Management message contains a Multicast-Service-Profile-
Name TLV, the AN associates the named profile with the specified
access line. This association replaces any previous association.
That is, a given access line is associated with at most one multicast
service profile. The replacement of one multicast service profile
with another will cause the AN to review the status of all active
flows on the target port. For further details see Section 6.
If the Port Management message contains a Bandwidth-Allocation TLV,
the AN adopts this as the current value of its total multicast
bandwidth limit for the target port. If the AN has already committed
multicast bandwidth exceeding the amount given in the Bandwidth-
Allocation TLV, the AN SHOULD NOT discontinue any multicast streams
in order to bring bandwidth down to within the new limit, unless such
action is required by local policy. However, the AN MUST NOT admit
new multicast streams that are subject to admission control until it
can do so within the limit specified by the Bandwidth-Allocation TLV.
If the Port Management request cannot be processed due to error and
the Result field of the request is Nack (0x1) or AckAll (0x2), the AN
SHOULD add a Status-Info TLV to the Extension Value field in its
reply if this will provide useful information beyond what is provided
by the Result Code value returned in the response header. In
particular, if the name within the Multicast-Service-Profile-Name TLV
does not match a profile name given in a prior Provisioning message,
the AN SHOULD return a reply where the Result Code field in the
header indicates 0x55, "Invalid TLV contents", the Error Message
field in the Status-Info TLV contains the text "Multicast profile
name not provisioned", and the Status-Info TLV contains a copy of the
Multicast-Service-Profile-Name TLV.