RFC 7256
Multicast Control Extensions for the Access Node Control Protocol (ANCP)
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 2014 Multicast 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 ....................................................5 1.1. A Note on Scope ............................................7 2. Terminology .....................................................7 3. Multicast Use Cases .............................................7 3.1. NAS-Initiated Multicast Replication Control Use Case .......8 3.1.1. Goals ...............................................8 3.1.2. Message Flow ........................................9 3.2. Conditional Access and Admission Control Use Case ..........9 3.2.1. Goals ...............................................9 3.2.2. Message Flow .......................................10 3.3. Multicast Flow Reporting Use Case .........................11 3.3.1. Goals ..............................................11 3.3.2. Message Flow .......................................11 3.4. Committed Bandwidth Reporting Use Case ....................11 3.4.1. Goals ..............................................11 3.4.2. Message Flow .......................................12 4. ANCP Messages ..................................................13 4.1. Provisioning Message ......................................13
4.1.1. Sender Behavior ....................................14
4.1.2. Receiver Behavior ..................................14
4.2. Port Management Message ...................................15
4.2.1. Sender Behavior ....................................16
4.2.2. Receiver Behavior ..................................16
4.3. Multicast Replication Control Message .....................17
4.3.1. Sender Behavior ....................................21
4.3.2. Receiver Behavior ..................................21
4.4. Multicast Admission Control Message .......................24
4.4.1. Sender Behavior ....................................25
4.4.2. Receiver Behavior ..................................26
4.5. Bandwidth Reallocation Request Message ....................27
4.5.1. Sender Behavior ....................................28
4.5.2. Receiver Behavior ..................................28
4.6. Bandwidth Transfer Message ................................31
4.6.1. Sender Behavior ....................................32
4.6.2. Receiver Behavior ..................................32
4.7. Delegated Bandwidth Query Request Message .................34
4.7.1. Sender Behavior ....................................34
4.7.2. Receiver Behavior ..................................34
4.8. Delegated Bandwidth Query Response Message ................34
4.8.1. Sender Behavior ....................................35
4.8.2. Receiver Behavior ..................................35
4.9. Multicast Flow Query Request and Response Messages ........36
4.9.1. Sender Behavior ....................................36
4.9.2. Receiver Behavior ..................................37
4.10. Committed Bandwidth Report Message .......................38
4.10.1. Sender Behavior ...................................38
4.10.2. Receiver Behavior .................................39
5. ANCP TLVs For Multicast ........................................39
5.1. Multicast-Service-Profile TLV .............................39
5.2. Multicast-Service-Profile-Name TLV ........................41
5.3. List-Action TLV ...........................................41
5.4. Sequence-Number TLV .......................................44
5.5. Bandwidth-Allocation TLV ..................................45
5.6. White-List-CAC TLV ........................................45
5.7. MRepCtl-CAC TLV ...........................................46
5.8. Bandwidth-Request TLV .....................................46
5.9. Request-Source-IP TLV .....................................47
5.10. Request-Source-MAC TLV ...................................48
5.11. Request-Source-Device-Id TLV .............................48
5.12. Multicast-Flow TLV .......................................49
5.13. Report-Buffering-Time TLV ................................50
5.14. Committed-Bandwidth TLV ..................................51
6. Multicast Capabilities .........................................51
6.1. Required Protocol Support .................................52
6.1.1. Protocol Requirements for NAS-Initiated
Multicast Replication ..............................52
6.1.2. Protocol Requirements for Committed
Multicast Bandwidth Reporting ......................54
6.1.3. Protocol Requirements for Conditional
Access and Admission Control with White
and Black Lists ....................................55
6.1.4. Protocol Requirements for Conditional
Access and Admission Control with Grey Lists .......56
6.1.5. Protocol Requirements for Bandwidth Delegation .....57
6.2. Capability-Specific Procedures for Providing
Multicast Service .........................................57
6.2.1. Procedures for NAS-Initiated Multicast
Replication ........................................58
6.2.2. Procedures for Committed Bandwidth Reporting .......58
6.2.3. Procedures for Conditional Access and
Admission Control with Black and White Lists .......59
6.2.4. Procedures for Conditional Access and
Admission Control with Grey Lists ..................61
6.2.5. Procedures for Bandwidth Delegation ................63
6.3. Combinations of Multicast Capabilities ....................64
6.3.1. Combination of Conditional Access and
Admission Control with White and Black Lists
and Conditional Access and Admission Control
with Grey Lists ....................................64
6.3.2. Combination of Conditional Access and
Admission Control with Bandwidth Delegation ........65
6.3.3. Combination of NAS-Initiated Replication
with Other Capabilities ............................65
6.3.4. Combinations of Committed Bandwidth
Reporting with Other Multicast Capabilities ........66
7. Miscellaneous Considerations ...................................66
7.1. Report Buffering Considerations ...........................66
7.2. Congestion Considerations .................................67
8. Security Considerations ........................................67
9. IANA Considerations ............................................69
10. Acknowledgements ..............................................72
11. References ....................................................73
11.1. Normative References .....................................73
11.2. Informative References ...................................73
Appendix A. Example of Messages and Message Flows ................75
A.1. Provisioning Phase ........................................75
A.2. Handling Grey-Listed Flows ................................81
A.3. Handling White-Listed Flows ...............................87
A.4. Handling of Black-Listed Join Requests ....................92
A.5. Handling of Requests to Join and Leave the On-Line Game ...92
A.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.
3.4.2. Message Flow
The message flow associated with this use case is shown in Figure 4. The figure assumes that a non-zero buffering interval was previously provisioned on the AN. +-----+ +-------+ +-----+ ANCP +-----+ |Subs |+ | Home |+ | AN |<---------->| NAS | |1,2 || |GW 1,2 || +-----+ +-----+ +-----+| +-------+| | | +|----+ +|------+ | | | | | | | | | |Join(Subs1, Ch1) | | |----------+--------------->| Start buffering | | | | Multicast flow | timer. Create | |<=========+================| message with | | | | | | initial contents | | | | | | reporting new | | | | | | Subs1 bandwidth. | | | Join(Subs2, Ch2) | | | |----------+------------->| Add report for | | | | Multicast flow | new Subs2 b/w. | | |<=========+==============| | | | | | | | | |Leave(Subs1, Ch1) | | |----------+--------------->| Replace report | | | | | | for Subs1 with | | | Stop replication X new value (which | | | | | | happens to be | | | | | | the same as the | | | | | | starting value). | | | | | | | | | | | >|< TIMER expires | | | | | | | | | | | |Committed | | | | | | Bandwidth Report | | | | | |------------------>| | | | | | (for latest | | | | | | Subs1 and Subs2 | | | | | | bandwidth) | | | | | | | Figure 4: Message Flow for Committed Bandwidth Reporting
4. ANCP Messages
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.
(page 17 continued on part 2)
