RFC 7256
Multicast Control Extensions for the Access Node Control Protocol (ANCP)
Multicast Control Extensions for the Access Node Control Protocol (ANCP) 💖
okay so this is RFC 7256 🎀, published by the IETF in July 2014. It's a Standards Track document, which means it's an actual Internet standard and not just a suggestion 💅. The ISSN is 2070-1721.
- Authors: F. Le Faucheur and R. Maglione from Cisco, and T. Taylor from Huawei 🫶
- Updates: RFC 6320 🦋
- Obsoletes: the title block doesn't list anything it obsoletes 🌸
Abstract ✨
bestie, here's the vibe: this doc adds multicast features to the Access Node Control Protocol (ANCP) from RFC 6320 🧚. It covers the multicast use cases from the ANCP framework doc (RFC 5851) plus one extra use case that only shows up in this one 💜. All of them are sorted into these ANCP capabilities:
- multicast replication kicked off by the Network Access Server (NAS) 🔥;
- conditional access and admission control using white and black lists 🍓;
- conditional access and admission control using grey lists 🩶;
- bandwidth delegation 🌈; and
- committed bandwidth reporting 👑.
These capabilities can be mixed and matched following the rules in this spec, so you can stack them up if you want that combo 💅✨.
This doc also updates RFC 6320 in two ways 🙈. First, it gives capability type 3 to one of the capabilities defined here. Second, it moves the starting point for IANA's IETF Consensus result codes from 0x100 to 0x64. Ngl, that's a lot of numbers for one paragraph 💀.
Status of This Memo ✨
This is an Internet Standards Track document 🎀.
It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community 🫶. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more info on Internet Standards, check Section 2 of RFC 5741 🌸. For the current status, any errata, and how to send feedback, go to 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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled from this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come 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 .................951. Introduction 🧚
Part 2 is coming next, bestie, so get ready for the actual protocol tea ☕💖
1. Introduction ✨
Okay bestie, so [RFC5851] sets up 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. The goal is QoS-related, service-related, and subscriber-related operations 💅. Then [RFC6320] comes in and specifies an actual protocol for Access Node Control in broadband networks that follows that framework 🎀.
[RFC6320] supports three use cases from [RFC5851] specifically for DSL access: the Topology Discovery use case, the Line Configuration use case, and the Remote Connectivity Test use case. But it does NOT cover the multicast use cases from [RFC5851] 😭. This document fills that gap by specifying the Access Node Control Protocol extensions needed for those multicast use cases. It also supports the Committed Bandwidth Reporting use case, which we'll get into below 🦋. In ANCP terms, all of this is organized into five capabilities:
- NAS-initiated multicast replication;
- conditional access and admission control with white and black lists;
- conditional access and admission control with grey lists;
- bandwidth delegation; and
- committed bandwidth reporting.
NAS-initiated multicast replication assumes that multicast join and leave requests end up terminated on the NAS, or that the NAS gets requests to set up multicast sessions some other way (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 briefly described 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 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 get accepted or ignored based on the direction given by white and black lists, respectively 🍓. The white and black lists are provisioned per port at startup time and can be modified after that. The NAS may combine conditional access with admission control of white-listed flows through appropriate provisioning.
Conditional access and admission control with grey lists is similar to the white list version, except that before accepting any request matching a grey list entry, the AN sends a request to the NAS asking 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 this 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 for each of these capabilities, singly and in combination, is in Section 6 🫶.
On top of the multicast service processing behavior I just sketched, the definition of each capability also includes support for the multicast accounting and reporting services described in Section 3.4.3 of [RFC5851]. Because this content is shared and because the capabilities overlap in other protocol ways too, the protocol descriptions for the multicast extensions in this document are merged into one non-redundant narrative 🎀. The tables in Section 6 then show which sub-sections of the protocol description 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 📺. The use case descriptions rest on two basic assumptions:
- that the Home Gateway operates in bridged mode, and
- 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 🙈. That has a very minor effect on the capabilities described below, but it prevents applying per-device policies at the NAS. Changing the second assumption would mean that, in applications where the AN is responsible for snooping IGMP and MLD, it also has to monitor for PIM signaling. The capabilities in this document don't 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 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 these multicast operations and identifies the matching ANCP requirements 🦋. This section describes a subset of those use cases as background, to make this document easier to read, but you should check [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 so they can get 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 is a subscriber using some form of application-level signaling that gets 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. So 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 it 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 this 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 Control
3.2. Conditional Access and Admission Control Use Case
3.2.1. Goals ✨
okay so the first option for handling multicast is letting the access/aggregation nodes join the IGMP/MLD party too (think IGMP/MLD snooping) 🫶 when the AN spots a join or leave from an end user for a multicast flow on the grey list, it uses ANCP to ask the NAS for a conditional access and admission control decision. then, once the NAS has done its checks, it uses ANCP to tell the AN how to change its replication states. it's giving teamwork 💅
3.2.2. Message Flow 🦋
for the conditional access and admission control use case, when the AN detects an IGMP/MLD join, it sends a Multicast Admission Control message to the NAS asking for a conditional access and admission control check. if it passes ✅, the NAS sends a Multicast Replication Control message back to the AN telling it to replicate the flow to that user. same energy for leaves: when the AN detects an IGMP/MLD leave, it sends a Multicast Admission Control message so the NAS always knows when someone has dipped out of the flow 👀 here's the whole flow 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
the (*) bit is the plot twist 👀: the NAS may optionally check with an external Authorization/Policy Server before it lets the flow in 💖
3.3. Multicast Flow Reporting Use Case 📸
3.3.1. Goals 🌸
the multicast flow reporting use case lets the NAS ask the AN, whenever it feels like it (asynchronously 💅), for an instant status report on the multicast flows the AN is currently replicating 🔥
3.3.2. Message Flow ✨
the NAS sends a Multicast Flow Query Request message to the AN to ask stuff like which multicast flows are active on a given AN port, or which ports are replicating a given multicast flow 🧚 the AN answers in a Multicast Flow Query Response message. here's the vibe 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 keeps the NAS in the loop on how much multicast bandwidth the AN has committed to a given access line 🫶 that way the NAS can tweak its forwarding scheduler so the QoS stays on point ✨ ngl this is more detailed than bandwidth delegation, because delegated bandwidth is just an upper limit, not the actual number 🙈 and to keep the messaging from getting out of hand, the AN can buffer its reports so one message covers changes for multiple access lines 📦
3.4.2. Message Flow 🍓
the message flow for this use case is in Figure 4. the figure assumes a non-zero buffering interval was already 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 Reporting4. ANCP Messages 💌
this section defines new ANCP messages, plus new ways of using existing ones, along with the procedures that go with them 🎀
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. 🙅♀️ that's a big one, bestie!
4.1. Provisioning Message 🧁
Section 4.1 of [RFC6320] defines the Provisioning message that the NAS sends to the AN to provision information on the AN side 💅
this document says the Provisioning message MAY be used by the NAS to provision multicast-related information (for example, multicast service profiles) 🌸 the ANCP Provisioning message payload MAY contain:
- one or more instances of the Multicast-Service-Profile TLV. The Multicast-Service-Profile TLV is defined in this document in Section 5.1. Each instance has a multicast service profile name and one or more list actions. A list action is made of an action (add, delete, replace), a list type (white, black, or grey), and list content (multicast source and group addresses) 🗂️
- an instance of the White-List-CAC TLV. The White-List-CAC TLV is defined in Section 5.6. If it's there, it means the AN is required to do admission control before replicating white-listed flows 🛡️
- an instance of the MRepCtl-CAC TLV. The MRepCtl-CAC TLV is defined in Section 5.7. If it's there, it means the AN is required to do admission control before replicating flows specified in Multicast Replication Control messages 🔐
- an instance of the Report-Buffering-Time TLV. The Report-Buffering-Time TLV is defined in Section 5.13. If it's there, it means Committed Bandwidth Report messages should be buffered for the amount of time the TLV gives before they get sent to the NAS ⏳
see Section 6 for info on which multicast capabilities need these TLVs in the Provisioning message 📚
4.1.1. Sender Behavior 💫
when the Policy Server or a management action says so, the NAS sends the Provisioning message to set up or update the white, black, and/or grey multicast channel lists tied to a set of named multicast service profiles, or to tell the AN to run admission control for specific classes of flows 🎯
to provision or update a multicast service profile, the NAS MUST include one or more instances of the Multicast-Service-Profile TLV in the message, with the content being provisioned or updated 📝 the NAS MUST NOT include any list type (white, black, or grey) that isn't supported by the set of multicast capabilities negotiated between the NAS and the AN 🚫 and the NAS MUST NOT use the Provisioning message to send Multicast-Service-Profile TLV instances to the AN unless that TLV is supported by the negotiated set of multicast capabilities 🙅♀️
to make the AN do admission control 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 make the AN do admission control on grey-listed flows or 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 make Committed Bandwidth Report messages get buffered so reports for multiple access lines can ride in the same message, the NAS MUST include a copy of the Report-Buffering-Time TLV with a non-zero time value in a Provisioning message sent to the AN ⏱️ and the Report-Buffering-Time TLV MUST NOT be provided unless the negotiated set of capabilities includes committed bandwidth reporting 💖
4.1.2. Receiver Behavior 👂
okay so the AN is the one doing the actual listening here 🎧 it takes the Multicast-Service-Profile TLV instances in the message and updates the white, black, and/or grey lists tied to those profile names, using whatever the matching List-Action TLVs say. the AN MUST process the List-Action TLVs in the exact order they show up in the message 📋 and, following the general rule from Section 4, it MUST ignore any List-Action TLV for a list type (white, black, or grey) that isn't supported by the multicast capabilities the NAS and AN agreed on. not supported = not my problem, bestie 💅
when a brand new profile shows up in a Multicast-Service-Profile TLV, every list tied to it starts out empty 🫙 under the negotiated capabilities, and it stays that way until a Multicast-Service-Profile TLV changes it. clean slate energy ✨
if a Provisioning message updates a profile that already exists (after startup), the AN has to recheck the active flows on every port that profile is assigned to 🔍 that's the glow-up check, and the details are in Section 6. 🎀
now the admission control stuff 🚦 if the White-List-CAC and/or MRepCtl-CAC TLV is in the Provisioning message and the matching capabilities were negotiated, the AN starts (or keeps on) doing admission control for the flow class(es) those TLVs name. but if one or both were in an earlier Provisioning message and are missing from the latest one, the AN stops doing admission control for those classes. gone, just like that 👋
the Report-Buffering-Time TLV's buffering time doesn't kick in until the current batch of Committed Bandwidth Report messages finishes accumulating ⏳ no mid-batch plot twists allowed 🙈
as [RFC6320] says, the AN MUST NOT reply to a Provisioning message it processed successfully 🤫 silence is golden here. if something goes wrong and stops the content from being processed properly, the AN MUST return a Generic Response message (as defined in [RFC6320]) with a Status-Info TLV that describes the error with the right details 🚨 and fun fact: a list type inside a Multicast-Service-Profile TLV that got ignored because the negotiated capabilities don't support it is NOT counted as an error. totally fine, no drama 💖
4.2. Port Management Message 🔌
as [RFC6320] lays out, the NAS can send DSL line configuration info to the AN (that's the ANCP-based DSL line configuration use case) using ANCP Port Management messages 📡 check out Section 7.3 of [RFC6320] for the format of the Port Management message in that setup.
this document says the Port Management message MAY be used to carry either or both of these TLVs:
Multicast-Service-Profile-NameTLV (defined in Section 5.2). This one ties a Multicast Service Profile to the access line named in the extension block. For white and black lists, it also hands conditional access over to the AN for that access line and its channels 🎟️Bandwidth-AllocationTLV (defined in Section 5.5). This one sets the total multicast bandwidth the AN gets to use for admission control on the access line 💸
when the Port Management message is being used this way:
- the
Functionfield in the Port Management message MUST be set to8, "Configure Connection Service Data" 🧁 - the message MUST include TLV(s) that identify the access line in question. 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 right alternative line-identifying TLV(s) MUST be present 🪪 other line configuration data (besides the two TLVs listed above) MAY be there too, no pressure 🌸
4.2.1. Sender Behavior 📤
the NAS sends the Port Management message at startup to set up the parameters for the access line in the message and for the multicast capabilities the NAS and AN negotiated 🚀 the NAS MAY send more Port Management messages after startup to update these parameters or, if it's a Bandwidth-Allocation TLV, to reset them 🔄 if the NAS puts a Multicast-Service-Profile-Name TLV in the Port Management message, the name MUST match a profile name that was given in a Multicast-Service-Profile TLV in an earlier Provisioning message 🎯 and the NAS MUST NOT include a TLV unless the negotiated multicast capabilities support it. for more info, see Section 6 💕
4.2.2. Receiver Behavior 📥
if the Port Management message has a Multicast-Service-Profile-Name TLV, the AN links the named profile to the specified access line 🔗 and this link replaces any previous one. so a given access line is tied to at most one multicast service profile, one and only one, no sharing 👑 swapping one profile for another makes the AN recheck every active flow on the target port, and the details are in Section 6 🔍
if the Port Management message has a Bandwidth-Allocation TLV, the AN takes that value as its new total multicast bandwidth limit for the target port 💪 if the AN has already committed more multicast bandwidth than the Bandwidth-Allocation TLV allows, the AN SHOULD NOT shut down any multicast streams just to get back under the new limit, unless local policy says it has to 🛑 but the AN MUST NOT admit new multicast streams that are subject to admission control until it's back within the limit set by the Bandwidth-Allocation TLV 🚫 no new guests until the room is under capacity 🙅♀️
if the Port Management request can't be processed because of an 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, as long as that adds useful info beyond what the Result Code in the response header already says 💡 specifically, if the name in the Multicast-Service-Profile-Name TLV doesn't match a profile name from an earlier Provisioning message, the AN SHOULD send back a reply where the Result Code field in the header is 0x55, "Invalid TLV contents" 🙅 the Error Message field in the Status-Info TLV should say "Multicast profile name not provisioned" 📝 and the Status-Info TLV should contain a copy of the Multicast-Service-Profile-Name TLV 🪞 that's the whole receipt, bestie 🧾✨
4.3. Multicast Replication Control Message ✨
okay bestie, this section introduces the Multicast Replication Control message 🎀 The NAS sends it to the AN with one or more directives to add (join) or delete (leave) a multicast flow on a target object that's named in the message content 🦋
The Message Type for this one is 144 💜
The ANCP Multicast Replication Control message payload has these TLVs:
- Target TLV: The Target TLV is defined in Section 4.3 of [RFC6320]. It MUST appear once and only once. It is encoded as specified in [RFC6320] or extensions and identifies the AN port subject to the request for admission or release.
- Command TLV: The Command TLV is defined in Section 4.4 of [RFC6320]. It MUST be present. It MAY appear multiple times.
As [RFC6320] points out, the contents of the Command Info field inside the Command TLV depend on which message the TLV shows up in. For the Multicast Replication Control message, those contents are:
- a Command Code field;
- an Accounting field; and
- an instance of the Multicast-Flow TLV.
Figure 5 shows the whole Command TLV with the contents that are specific to the Multicast Replication Control message 👑
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | Command TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Command Code | Accounting | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Flow TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other embedded TLV Type | Other embedded TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Other embedded TLV data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Contents of the Command TLV in the Multicast Replication
Control Message- Command Code: One of the following command directives:
1 "Add"
2 "Delete"
3 "Delete All"
4 "Admission Control Reject"
5 "Conditional Access Reject"
6 "Admission Control and Conditional Access Reject"Directives 4 through 6 are used as described in Section 4.4.2.
- Accounting: Meaningful only when the Command Code is "Add" (1). In that case, 0 indicates flow accounting is disabled, and 1 indicates that octet accounting for the flow is requested. The sender MUST set the Accounting field to 0, and the receiver MUST ignore the Accounting field for other Command Code values.
- Reserved: Reserved for future use. MUST be set to zeroes by the sender and ignored by the receiver.
- Multicast-Flow TLV: An instance of the Multicast-Flow TLV (Section 5.12) specifying the flow to be added or deleted. The Multicast-Flow TLV is omitted if the Command Code has value "Delete All" (3).
- Other embedded TLV data: No other embedded TLVs are currently specified within the Multicast Replication Control message and Command TLV. However, see the description of the Multicast Admission Control message (Section 4.4). Unrecognized embedded TLVs SHOULD be silently discarded.
The figure below is an example of a Multicast Replication Control message that would result in a swap from multicast Source-Specific Multicast (SSM) flows 2001:DB8::1, FF34::2 to 2001:DB8::2, FF34::3 on the target identified by the Access Loop Circuit ID 🧚
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | MsgType=144 | Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | Command TLV Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 2 | Acctg = 0 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | TLV Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | AddrFam = 2 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Multicast Group Address ~
| = FF34::2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Source Address ~
| = 2001:DB8::1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | Command-TLV Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | TLV Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | AddrFam = 2 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Multicast Group Address ~
| = FF34::3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Source Address ~
| = 2001:DB8::2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example Change of Source Flow Using Multicast Replication
Control Message4.3.1. Sender Behavior
The NAS MAY issue a Multicast Replication Control message to the AN to convey one or more directives to add (join) or delete (leave) one or more multicast flows 🌸
The NAS MAY send this message on its own initiative to support the NAS-initiated multicast control use case presented in [RFC5851] and summarized in Section 3.1. In that case, the NAS MUST set the Result field to AckAll (0x2) or Nack (0x1) according to its requirements.
The NAS MAY also send this message in response to a Multicast Admission Control message (defined in Section 4.4) received from the AN to support the conditional access and admission control use case presented in [RFC5851] and summarized in Section 3.2. In that case, the NAS MUST set the Result field to Nack (0x1).
In either case, the sender MUST populate the Result Code field with the value 0 and the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320] 💅
Each Multicast Replication Control message MUST contain one or more commands, each encapsulated in its own Command TLV. The sender MUST use a separate Command TLV for each distinct multicast flow.
When the order of processing of two commands does not matter, the commands MUST be transmitted in separate Multicast Replication Control messages 🫶
4.3.2. Receiver Behavior ✨
Okay so when a bunch of commands come in (same message or different ones) for the same target and multicast flow, every feature that gets controlled or affected by the attributes in a Multicast Replication Control message SHALL be set to whatever the last command or message for that target and flow said, as long as it included that controlling attribute. 💅 For example, if two add commands for the same port and flow differ only in the Accounting field, the accounting feature ends up matching the final one, but everything else is unaffected by the second message. 🦋
If there's more than one Command TLV in a Multicast Replication Control message, the AN MUST act on them in the order they show up in the message. 🔥 The AN SHALL also give each command in a given message a sequence number, starting from 1 for the first one. 🎀
If a Command TLV adds one or more flows and the AN is doing admission control for Multicast Replication Control messages, the AN MUST do admission control before replicating the flows. If that check fails, the AN MUST treat it as an error (more on that below), and the Result Code for it is 0x13 "Out of resources". 😭
If the AN processes the whole message successfully and the Result field was set to AckAll (0x2), the AN MUST respond with a Generic Response message. In that response, the Result field is Success (0x3), the Result Code field is 0, and the Transaction Identifier field is copied from the Multicast Replication Control message. The body of the response MAY be empty, or MAY be copied from the Multicast Replication Control message. 🌸
If the AN processes the whole message successfully and the Result field was set to Nack (0x1), the AN MUST NOT respond to the message. 🙈
Multiple commands in one Multicast Replication Control message MUST be interrupted at the first error, and the remaining commands in that message discarded. 💀 Same vibe for Single-Source Multicast (SSM) flows: if a given command specifies multiple SSM flows and an error happens, processing MUST be interrupted right there, and the rest of that Command TLV gets thrown out. 🧚
If the AN detects an error in a received Multicast Replication Control message and the Result field was set to Nack (0x1) or AckAll (0x2), the AN MUST generate a Generic Response message giving error information to the NAS. This spec adds the following new Result Code values on top of the ones in [RFC6320]. They MAY be used in a Generic Response sent in reply to a Multicast Replication Control message: 👑
0x64Command error.- Where detected: ANCP agent at the AN.
- Further description: an invalid command code has been received.
- Required additional information in the message: see below.
- Target: ANCP agent at the NAS.
- Action RECOMMENDED for the receiving ANCP agent: Report the error to the control application with an indication of the erroneous information associated with the invalid TLV(s).
0x65Invalid flow address.- Where detected: ANCP agent at the AN.
- Further description: either inconsistent flow address information has been provided or the address family is unsupported.
- Required additional information in the message: see below.
- Target: ANCP agent at the NAS.
- Action RECOMMENDED for the receiving ANCP agent: Report the error to the control application with an indication of the erroneous information associated with the invalid TLV(s).
0x66Multicast flow does not exist.- Where detected: control application at the AN.
- Further description: the NAS has attempted to delete a flow that is not active on the given access line.
- Required additional information in the message: see below.
- Target: control application at the NAS.
- Action RECOMMENDED for the receiving ANCP agent: report the error to the control application with an indication of the erroneous information associated with the invalid TLV(s).
A Generic Response message that answers a Multicast Replication Control message and contains one of the above Result Code values MUST include a Status-Info TLV. That Status-Info TLV holds one or two embedded TLVs, like so: 🫶
- a Sequence-Number TLV as described in Section 5.4, giving the sequence number of the failed command, MUST be included; and
- the failed Command TLV itself SHOULD be included.
Note: The Error Message field of the Status-Info TLV MAY be used to report more details than the Result Code value in the message header implies. For example, the Result Code value could be 0x65, and the Error Message field could contain the text: "Source address present for ASM flow". 🍓
4.4. Multicast Admission Control Message
This section introduces a brand new message called the Multicast Admission Control message. 🌈 The AN sends it to the NAS to request admission of a multicast flow, or to tell the NAS that a multicast flow has been removed, for a given target.
The Message Type for the Multicast Admission Control message is 145. 💜
The ANCP Multicast Admission Control message payload has two TLVs:
- Target TLV: The Target TLV is defined in [RFC6320]. It MUST appear once and only once in the Multicast Admission Control message. It is encoded as specified in [RFC6320] or its extensions, and it identifies the AN port subject to the request for admission or release.
- Command TLV: The Command TLV is defined in [RFC6320]. It MUST be present. If it shows up more than once, only the first instance is considered meaningful in this version of the spec, and the other instances are ignored. ✨
Note: Down the road, the Multicast Admission Control message might be extended to carry more than one directive (for example, a leave from one group and a join to another group for the same target). It's expected that this would support the same strict sequenced processing already defined for multiple directives in the Multicast Replication Control message, where every directive after the first one that can't be executed also doesn't get executed. When strict sequenced processing isn't required, the directives get spread across separate messages. 🧠
The Command TLV has the same contents described above for the Multicast Replication Control message, plus these additions:
- A
Request-Source-IPTLV MAY be appended to the Command TLV as an additional embedded TLV. - Similarly, a
Request-Source-MACTLV MAY be appended to the Command TLV as an additional embedded TLV. - Finally and preferably, a
Request-Source-Device-IdTLV MAY be appended to the Command TLV as an additional embedded TLV.
Heads up: the Command TLV length includes the length of any embedded TLVs, including their headers. 📏
4.4.1. Sender Behavior 🦋
The AN sending the Multicast Admission Control message MUST set the Result field to Ignore (0x0).
The AN MUST fill in the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320]. 🔑
The AN MUST encode the Command TLV as specified in Section 4.3, with these extra rules:
- The
Accountingfield MUST be set to0. - The
Command Codefield MUST be set to "Add" (1) when the message conveys a join request, to "Delete" (2) when it conveys a leave, and to "Delete All" (3) when it conveys a leave of all channels (on the target). - The
Multicast-FlowTLV within the Command TLV identifies the multicast flow subject to the request for admission or release. When theCommand Codeis3, theMulticast-FlowTLV is omitted. 💅
The AN MAY include the Request-Source-IP embedded TLV to convey the IP address of the sender of the join/leave message (e.g., IGMP/MLD join/leave) that triggered the AN to include the corresponding Command TLV in the Multicast Admission Control message. If it shows up more than once, only the first instance is considered meaningful, and the other instances are ignored.
The AN MAY include the Request-Source-MAC embedded TLV to convey the Media Access Control (MAC) address of the sender of the join/leave message (e.g., IGMP/MLD join/leave) that triggered the AN to include the corresponding Command TLV in the Multicast Admission Control message. If it shows up more than once, only the first instance is considered meaningful, and the other instances are ignored.
As a third option, the AN MAY include the Request-Source-Device-Id embedded TLV to convey a local identifier of the sender of the join/leave message (e.g., IGMP/MLD join/leave) that triggered the AN to include the corresponding Command TLV in the Multicast Admission Control message. If it shows up more than once, only the first instance is considered meaningful, and the other instances are ignored.
Including Request-Source-IP or Request-Source-MAC in the Multicast Admission Control message is usually done so policies can be applied to specific devices in the customer's network. 🕵️ But sending either of these beyond the AN is a potential privacy issue. So instead of transmitting either identifier, it is RECOMMENDED that the AN map the required identifier to a local value known to the AN and Authentication, Authorization, and Accounting (AAA) but not to the NAS, as discussed in Section 8. The local identifier then gets sent using the Request-Source-Device-Id TLV. 🔒
4.4.2. Receiver Behavior 💜
okay so when a NAS gets a Multicast Admission Control message, here's how it reacts 🎀
- The NAS MUST ignore the Result field. 🙈
- If the directive is "Delete" (2) or "Delete All" (3) and the NAS processes it correctly, the NAS MUST NOT generate any ANCP message in response. No reply needed, just vibes ✨
- If the directive is "Add" (1) and the NAS accepts it, the NAS MUST generate a Multicast Replication Control message in response. That reply:
- MUST contain a Result set to Nack (
0x1); - MUST contain a Transaction ID with a unique value, as described in Section 3.6.1.6 of [RFC6320]; and
- MUST contain the directive as accepted by the NAS. The NAS MAY modify the Accounting field if flow accounting is required. 💅
- MUST contain a Result set to Nack (
- If the directive is "Add" (1) and the NAS processes it correctly but doesn't accept it (aka it fails the conditional access and admission control check), the NAS MAY generate a Multicast Replication Control message in response. This one is optional, and the AN can use it to keep stats on admission control rejections 📊 If the NAS does send it, the message:
- MUST contain a Result set to
0x0; - MUST contain a Transaction ID with a unique value, as described in Section 3.6.1.6 of [RFC6320]; and
- MUST contain the directive the NAS rejected (so the Target TLV and Command TLV), but with a Command Code set to "Admission Control Reject" (4), "Conditional Access Reject" (5), or "Admission Control and Conditional Access Reject" (6), whichever fits. 🥀
- MUST contain a Result set to
- If the Multicast Admission Control message can't be processed correctly by the NAS (like the message is malformed, the multicast flow doesn't exist, etc.), the NAS MUST generate a Generic Response message (defined in Section 4.2 of [RFC6320]) with appropriate content explaining the failure. 🚨
4.5. Bandwidth Reallocation Request Message 🦋
okay this one is giving bandwidth negotiation energy 🫶 The Bandwidth Reallocation Request message is used when the bandwidth delegation capability is in the negotiated set. It MAY be sent by either the NAS or the AN to ask for a change in how much delegated bandwidth there is. Usually the NAS sends it to take back some multicast bandwidth from the AN so it can make room for new flows. The AN sends it when it needs more bandwidth to add a multicast channel. Either way, the requestor has a minimum it really needs, and it MAY ask for extra on top of that (for example, to cover requests it expects later) 🌸
The Bandwidth Reallocation Request message has two TLVs:
- the Target TLV (Section 4.3 of [RFC6320] or an extension), which names a single access line; and
- the Bandwidth-Request TLV (Section 5.8), which lists the required and preferred amounts of delegated bandwidth.
The Message Type for the Bandwidth Reallocation Request message is 146. 🍓
4.5.1. Sender Behavior 💅
The Result field in the header of the Bandwidth Reallocation Request message isn't used, so the sender MUST set it to Ignore (0x0).
The bandwidth values in the Bandwidth-Request TLV are totals of the multicast bandwidth allocated to the AN, not increments.
Note: Choosing "total bandwidth" over "incremental bandwidth" was intentional, because it's easier for the AN and NAS to keep their views of the current delegated bandwidth in sync. 🧚
Since the values are totals rather than increments or decrements, the relationship between the required and preferred amounts depends on who's sending the request:
- If the NAS is making the request, the preferred amount MUST be less than or equal to the required amount. The required amount MUST be less than the current amount of delegated bandwidth.
- If the AN is making the request, the preferred amount MUST be greater than or equal to the required amount. The required amount MUST be greater than the current amount of delegated bandwidth.
4.5.2. Receiver Behavior 🫶
When the peer gets a valid Bandwidth Reallocation Request message, it SHOULD check whether it can cover the request from its unused video bandwidth. If it can give bandwidth back to the peer, it MAY return any amount between the required and preferred amounts from the request.
The peer MUST send a Bandwidth Transfer message (Section 4.6) saying what it decided. If the request is met, the Result field of the Bandwidth Transfer message MUST be set to Success (0x3), the Result Code field MUST be set to 0x000, and the Bandwidth-Allocation TLV (Section 5.5) MUST contain the new total multicast bandwidth. That new value MUST lie between the required and preferred values from the request, inclusive. If the request is not met, the Result field MUST be set to Failure (0x4), the Result Code field MUST be set to 0, and the Bandwidth-Allocation TLV MUST contain the amount of delegated bandwidth currently allocated, as the responder sees it. 💖
The following cases mean the sender and receiver have different views of the delegated bandwidth amount:
- The NAS gets a request where the required amount is less than its view of the current delegated bandwidth.
- The AN gets a request where the required amount is greater than its view of the current delegated bandwidth.
If one of these happens, the receiver, with one exception, MUST send a Bandwidth Transfer message indicating Success.
- If the NAS received the request, the allocated amount in the NAS's response MUST be at least equal to the NAS's view of the current delegated bandwidth.
- If the AN received the request, the allocated amount in the AN's response MUST be no greater than the AN's view of the current delegated bandwidth.
The exception is when the NAS gets a request while it has its own request outstanding. That case is covered below.
Note: These cases are technically an error condition, but the success response gives a graceful recovery. Lowkey iconic 👑
To avoid deadlock from race conditions, these rules MUST be applied:
a. If the NAS receives a Bandwidth Reallocation Request message while it has its own Bandwidth Reallocation Request message outstanding for the same access line, the NAS MUST send an immediate failure response to the AN's request, with a Result Code value of 0x68 "Inconsistent views of delegated bandwidth amount" or 0x69 "Bandwidth request conflict," whichever applies. (More info below.)
b. If the AN receives a Bandwidth Reallocation Request message while it has its own Bandwidth Reallocation Request message outstanding for the same access line, the AN MUST release any bandwidth it already committed to an outstanding join request while it waits for the NAS to respond. It MUST decide on and send its response to the NAS with that released bandwidth taken into account. 🌈
If the receiver can't process the Bandwidth Reallocation Request message because of an error, the receiver MUST return a Bandwidth Transfer message where:
- the Result field is set to Failure (
0x4), - the Result Code field is set to the value that matches the type of error detected,
- the Bandwidth-Allocation TLV contains the current amount of delegated bandwidth as the responder sees it, and
- a Status-Info TLV MAY follow the Bandwidth-Allocation TLV with more detail about the error. 🚨
This specification adds three new Result Code values that only apply to the contents of the Bandwidth-Request TLV. By their nature, these Result Code values MUST only be used when reporting an error in a Bandwidth Transfer message, not in a Generic Response message. 🙅♀️
0x67 Invalid preferred bandwidth amount.
Where detected: control application at the receiver of the Bandwidth Reallocation Request message.
Further description: the preferred and required amounts in the TLV don't have the numerical relationship described above.
Required additional information in the message: as described above.
Target: control application at the sender of the Bandwidth Reallocation Request message.
Action RECOMMENDED for the receiving ANCP agent: report the error to the control application with the returned value of the Bandwidth-Allocation TLV. See also Section 4.6.2.2.
0x68 Inconsistent views of delegated bandwidth amount.
Where detected: control application at the NAS.
Further description: the NAS has an outstanding Bandwidth Reallocation Request, so it's rejecting a similar request from the AN. In the AN's request, the required amount was less than the NAS's view of the current delegated bandwidth.
Required additional information in the message: as described above.
Target: control application at the AN.
Action RECOMMENDED for the receiving ANCP agent: report the error to the AN control application with the returned value of the Bandwidth-Allocation TLV. See also Section 4.6.2.2.
0x69 Bandwidth request conflict.
Where detected: control application at the NAS.
Further description: the NAS has an outstanding Bandwidth Reallocation Request, so it's rejecting a similar, valid request from the AN.
Required additional information in the message: as described above.
Target: control application at the AN.
Action RECOMMENDED for the receiving ANCP agent: report the error to the AN control application with the returned value of the Bandwidth-Allocation TLV. See also Section 4.6.2.2. 💀
4.6. Bandwidth Transfer Message 💸
okay so the Bandwidth Transfer message is how you move video bandwidth from the sender over to the peer for one specific access line 🦋 This message MAY be sent either from the AN or from the NAS. Like we just covered, it's the required response to a valid Bandwidth Reallocation Request message ✨
The Bandwidth Transfer message MAY also be used to transfer bandwidth autonomously from one peer to another 🌸 One example is releasing bandwidth you borrowed earlier with the Bandwidth Reallocation Request message. When it's used this way, the Result field MUST be set to Ignore (0x0) 💅
Note: This allows the receiver to distinguish between an autonomous transfer and a response to a previous Bandwidth Reallocation Request message, for purposes of validation.
The Message Type for the Bandwidth Transfer message is 147. It carries these TLVs:
- the
Target TLV, designating the access line concerned; - an instance of the
Bandwidth-Allocation TLV(Section 5.5). The bandwidth value in theBandwidth-Allocation TLVis the new amount of delegated bandwidth allocated to the target.
4.6.1. Sender Behavior
When you send a Bandwidth Transfer message where the Result value is Ignore (0x0) or Success (0x3), these relationships MUST hold 🫶
- If the NAS is the one sending it, the bandwidth value in the
Bandwidth-Allocation TLVMUST be greater than or equal to the sender's view of the current amount of delegated bandwidth for the access line concerned. - If the AN is the one sending it, the bandwidth value in the
Bandwidth-Allocation TLVMUST be less than or equal to the sender's view of the current amount of delegated bandwidth for the access line concerned.
Further sender behavior is specified above, in Section 4.5.2 🎀
4.6.2. Receiver Behavior
4.6.2.1. Behavior of the NAS
If the amount of delegated bandwidth in the Bandwidth-Allocation TLV is not greater than the NAS's view of the current amount of delegated bandwidth, the NAS MUST update its view to the amount indicated in the Bandwidth Transfer message 🔥 This is required regardless of whether the Result field of that message indicates Success or Failure.
If the amount in the Bandwidth-Allocation TLV is greater than the NAS's view, the NAS MAY accept the given value as its new value of delegated bandwidth 🦋 Or, the NAS MAY force the AN to fix its view to match what the NAS holds. It does this by sending a Port Management message for the target access line concerned, containing a Bandwidth-Allocation TLV with a value equal to the amount of delegated bandwidth the NAS wants to enforce 👑
4.6.2.2. Behavior of the AN
If the amount of delegated bandwidth in the Bandwidth-Allocation TLV of the Bandwidth Transfer message differs from the AN's view, the AN MUST update its view to the amount indicated in the Bandwidth Transfer message 💖 This is required, with one exception: a Bandwidth Transfer message with a Result field equal to Failure (0x4) and a Result Code field equal to 0x68 "Inconsistent views of delegated bandwidth amount" or 0x69 "Bandwidth request conflict".
If Result Code value 0x68 is received, the AN MUST issue a Delegated Bandwidth Query Request message to find out the NAS's current view of the amount of delegated bandwidth. The AN MUST update its own view based on the value returned in the Delegated Bandwidth Query Response message 🧚
If Result Code value 0x69 is received, the AN SHOULD carry out this procedure, unless it can account for the discrepancy as a result of a transfer of bandwidth to the NAS that happened just before the incoming Bandwidth Transfer message was processed 🤔
Note: The two Result Code values point to a race condition where the AN may have just finished a transfer of bandwidth to the NAS. So the value in the Bandwidth Transfer message may be outdated, and the AN needs to ask the NAS for its latest view. This procedure assumes ordering is preserved between the Bandwidth Transfer message sent by the AN in response to the NAS's request and the subsequent Delegated Bandwidth Query Request message.
If the AN has already committed multicast bandwidth above the amount in the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any multicast streams just to bring bandwidth down to the new limit, unless local policy says it has to 🙈 However, the AN MUST NOT admit new multicast streams that are subject to admission control until it can do so within the limit set by the Bandwidth-Allocation TLV. As specified in Section 6.2.5.2, the AN MAY try to fix the situation by sending a request to the NAS for an increased allocation of delegated bandwidth, using the Bandwidth Reallocation Request message 💅
4.7. Delegated Bandwidth Query Request Message 🔍
The Message Type for the Delegated Bandwidth Query Request (and Response) messages is 148 ✨
The Delegated Bandwidth Query Request message MAY be sent by either the NAS or the AN to retrieve the peer's view of the amount of delegated bandwidth. The request contains one TLV:
- a
Target TLVdesignating the access line for which the information is requested.
4.7.1. Sender Behavior
The sender MUST set the Result field in the header of the Delegated Bandwidth Query Request message to AckAll (0x2). The Result Code value MUST be set to 0. The sender MUST also populate the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320] 🫶
4.7.2. Receiver Behavior
If the AN or NAS receives a valid Delegated Bandwidth Query Request message, it MUST respond with a Delegated Bandwidth Query Response message 🌈 The Result field in the header of the response MUST be set to Success (0x3). The Result Code field MUST be set to 0. The Transaction Identifier field MUST be copied from the request message. The body of the response MUST contain the Target TLV, copied from the request message. Finally, the body of the response MUST contain a Bandwidth-Allocation TLV, holding the current amount of delegated bandwidth from the point of view of the receiver of the request 💜
If the contents of the Delegated Bandwidth Query Request message are in error, the receiver MUST return a Delegated Bandwidth Query Response message with the Result field in the header set to Failure (0x3) 😭 The Result Code field MUST be set to the value that shows the nature of the error (e.g., 0x500 "One or more of the specified ports do not exist"). The Transaction Identifier field MUST be copied from the request. The body of the response MUST contain the Target TLV copied from the request. This MAY be followed by a Status-Info TLV giving further information about the error.
4.8. Delegated Bandwidth Query Response Message 📨
The Delegated Bandwidth Query Response message is sent in reply to a Delegated Bandwidth Query Request message. A response to a valid request contains two TLVs:
- the
Target TLV, copied from the request; and - a
Bandwidth-Allocation TLV, giving the responder's view of the current amount of multicast bandwidth delegated to the AN.
The Message Type for the Delegated Bandwidth Query Response message is 148 🦋
4.8.1. Sender Behavior
Sender behavior for the Delegated Bandwidth Query Response message is specified in Section 4.7.2 🌸
4.8.2. Receiver Behavior
If the Delegated Bandwidth Query Response message indicates Success (0x3), the actions described in Sections 4.8.2.1 and 4.8.2.2 apply ✨
4.8.2.1. Behavior at the NAS
If the amount of delegated bandwidth in the Bandwidth-Allocation TLV is less than the NAS's view of the current amount of delegated bandwidth, the NAS MUST update its view to the amount indicated in the Delegated Bandwidth Query Response message 🔥
If the amount in the Bandwidth-Allocation TLV is greater than the NAS's view, the NAS MAY accept the given value as its new value of delegated bandwidth 🦋 Or, the NAS MAY force the AN to fix its view to match what the NAS holds, by sending a Port Management message for the target access line concerned. That message contains a Bandwidth-Allocation TLV with a value equal to the amount of delegated bandwidth the NAS wants to enforce 👑
4.8.2.2. Behavior at the AN
The AN SHOULD accept the value returned in the Bandwidth-Allocation TLV of the Delegated Bandwidth Query Response message as the correct current amount of delegated bandwidth 🫶 If the AN has already committed multicast bandwidth above the amount in the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any multicast streams just to bring bandwidth down to the new limit, unless local policy requires it 🙈 However, the AN MUST NOT admit new multicast streams that are subject to admission control until it can do so within the limit set by the Bandwidth-Allocation TLV. As specified in Section 6.2.5.2, the AN MAY try to fix the situation by sending a request to the NAS for an increased allocation of delegated bandwidth, using the Bandwidth Reallocation Request message 💅
Note: A race condition is possible where the AN sends a query, the NAS requests more bandwidth, then receives and responds to the query, and then receives the Bandwidth Transfer message responding to its request. It is up to the AN to take appropriate action in this case. The best action appears to be not to act on the result of the first query, but to repeat the query after sending the Bandwidth Transfer message. Similar considerations apply to a race between queries from both sides.
4.9. Multicast Flow Query Request and Response Messages 🌊
This section defines two new messages, called the Multicast Flow Query Request and Multicast Flow Query Response 💖 The Multicast Flow Query Request message is sent by the NAS to ask for information about the multicast flows that are active on the AN. The Multicast Flow Query Response message is sent in reply by the AN to give the NAS the information it asked for 🧚
The Message Type for the Multicast Flow Query Request and Multicast Flow Query Response messages is 149 ✨
The contents of the Multicast Flow Query Request and Multicast Flow Query Response messages depend on the nature of the query, as described below 👑
4.9.1. Sender Behavior
okay so the sender of a Multicast Flow Query Request message MUST set the Result field to AckAll (0x2) 💅 and the Result Code field MUST be set to 0x000. The sender MUST also fill in the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320] 🎀
The Multicast Flow Query Request message MAY be used by the NAS to grab any of these:
- the AN's view of which multicast flows are currently active on a specified set of access ports; or
- the AN's view of the access ports on which a specified set of multicast flows are currently active; or
- the AN's view of all the multicast flows currently active on each access port of the AN.
bestie, to check which multicast flows are active on one port of the AN, the NAS MUST include a Target TLV in the Multicast Flow Query Request payload that identifies that port. The Target TLV is encoded as specified in [RFC6320] 🦋
To check which ports are currently receiving one multicast flow, the NAS MUST include a Multicast-Flow TLV in the payload that identifies that flow. The Multicast-Flow TLV is encoded as specified in Section 5.12 🌸
The NAS MAY include multiple Target TLVs or multiple Multicast-Flow TLVs in the Multicast Flow Query Request message, but it MUST NOT include both Target and Multicast-Flow TLVs in the same message. Not allowed, no exceptions 🙅♀️💜
And if you want the AN's view of every multicast flow on every port, the NAS MUST send a Multicast Flow Query Request message that has no Target TLV and no Multicast-Flow TLV at all. Full picture energy ✨
4.9.2. Receiver Behavior
the AN MUST answer any Multicast Flow Query Request message that has a valid format and valid content with a Multicast Flow Query Response message. In that response, the Result field MUST be set to Success (0x3), the Result Code field MUST be set to 0, and the Transaction Identifier field MUST be copied from the request 🍓
If the request has one (or more) Target TLVs, the AN MUST include the following set of TLVs for each of those Target TLVs 🧚
- Target TLV. This MUST be identical to the Target TLV in the received Multicast Flow Query Request message.
- Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once per multicast flow that is currently active on the AN port identified in the preceding Target TLV.
The Target TLVs MUST show up in the AN's response in the same order they were in the NAS's query. Order matters, babe 💖
If the request has one (or more) Multicast-Flow TLVs, the AN MUST include the following set of TLVs for each of those Multicast-Flow TLVs 🌈
- Multicast-Flow TLV. This MUST be identical to the Multicast-Flow TLV in the received Multicast Flow Query Request message.
- Target TLV(s). The Target TLV MUST appear once per AN port on which the multicast flow identified in the preceding Multicast-Flow TLV is active.
The Multicast-Flow TLVs MUST show up in the AN's response in the same order as in the NAS's query. Same vibe as before, periodt 💅
If the request has no Target TLV and no Multicast-Flow TLV, the AN MUST include the following set of TLVs for each AN port that is currently receiving multicast flow(s) 🌸
- Target TLV. This MUST identify one AN port.
- Multicast-Flow TLV(s). The Multicast-Flow TLV MUST appear once per Multicast Flow that is currently active on the AN port identified in the preceding Target TLV.
If the contents of the request are in error, the AN MUST reply with a Multicast Flow Query Response message. TheResultfield MUST be set toFailure (0x4)and theResult Codefield MUST be set to indicate the nature of the error. If the request had multiple Target TLVs or Multicast-Flow TLVs and one of them is in error, the response MUST contain the results for the instances before it, as if there had been no error. Those successful results MUST be followed by the TLV in error, copied from the request. The AN MUST NOT do any further processing of the request. The AN MAY add a Status-Info TLV to give more info about what went wrong. 😭
4.10. Committed Bandwidth Report Message
this section is all about the Committed Bandwidth Report message 🦋 It gets sent from the AN to the NAS to report the most recent amount of multicast bandwidth usage committed to one or more access lines. Iconic reporting behavior, honestly 👑
The Message Type for the Committed Bandwidth Report message is 150 🔥
The Committed Bandwidth Report message contains one or more instances of the Committed-Bandwidth TLV, as described in Section 5.14 🎀
4.10.1. Sender Behavior
the sender of a Committed Bandwidth Report message MUST set the Result field to Ignore (0x0) and the Result Code field MUST be set to 0x000. The sender MUST fill in the ANCP Transaction Identifier field with a unique value, as described in Section 3.6.1.6 of [RFC6320] 💜
Each Committed-Bandwidth TLV in the message MUST identify an access line whose committed multicast bandwidth has changed since the previous Committed Bandwidth Report message was sent, and it MUST report the latest amount committed to that line. There MUST be only one Committed-Bandwidth TLV in the message for any given access line. The message MUST include a Committed-Bandwidth TLV for every access line whose committed multicast bandwidth has changed since the previous Committed Bandwidth Report message was sent. Every line, every time, no skipping 🫶
Further behavior at the AN is specified in Section 6.2.2 ✨
4.10.2. Receiver Behavior
what the NAS does with the contents of a Committed Bandwidth Report message is implementation-dependent 🌈 One example: the NAS can use the multicast bandwidth commitment reports to adjust its forwarding scheduler so it delivers the intended level of QoS. Very main character behavior 💅
The NAS MUST NOT reply to a valid Committed Bandwidth Report message. The NAS MAY send a Generic Response message to flag any errors it found in a Committed Bandwidth Report message it received. 🙈
5. ANCP TLVs For Multicast ✨
this section defines the new ANCP TLVs for controlling multicast flows. Let's get into it 🧚
5.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 4.1 💖
The Multicast-Service-Profile TLV is drawn out in Figure 7. It's a TLV header wrapping a single Multicast-Service-Profile-Name TLV and one or more List-Action TLVs 🦋
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Service-Profile 0x0013 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Service-Profile-Name TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List-Action TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Multicast-Service-Profile TLVThe Multicast-Service-Profile TLV has these fields:
- TLV Type:
0x0013 - TLV Length: determined by the contents following the TLV header.
- Multicast-Service-Profile-Name TLV: described in Section 5.2. The Multicast-Service-Profile-Name TLV MUST contain an identifier that is unique over all profiles provisioned to the same AN partition. This identifier will be used to refer to the profile when activating it for a given target within a Port Management message (see Section 4.2). Name it right or don't name it at all 🌸
- List-Action TLV: described in Section 5.3. The List-Action TLV(s) either provide the content of a newly defined multicast service profile or modify the existing content. If more than one List-Action TLV is present, the order of the TLVs may be significant, since List-Action TLVs are processed in the order in which they appear. 👑
5.2. Multicast-Service-Profile-Name TLV
the Multicast-Service-Profile-Name TLV carries the identifier of a multicast service profile provisioned on the AN 🧚 It's drawn out in Figure 8.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Svc-Profile-Name 0x0018 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Multicast-Service-Profile-Name TLVThe Multicast-Service-Profile-Name TLV has these fields:
- TLV Type:
0x0018 - TLV Length: up to 255 octets.
- Multicast service profile identifier: an opaque sequence of octets identifying a specific multicast service profile.
Note: The identifier could have the form of human-readable text or an arbitrary binary value, depending on the operator's practices. 🦋
5.3. List-Action TLV ✨
okay so the List-Action TLV is how you add multicast flows to a white, black, or grey list, or take them back off 💅 It only makes sense next to a Multicast-Service-Profile-Name TLV that says which profile we're talking about 🎀 You can pair them by putting both TLVs in the same base message payload, or by nesting them inside another TLV like the Multicast-Service-Profile TLV 🧚 Here's the whole layout 👇
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation | List Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Number of flow fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast flow fields |
......
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: List-Action TLV
Here's what each field does 🦋
- TLV Type:
0x0021 - TLV Length: length of the subsequent contents.
- Operation: operation to be performed upon the white, black, or grey list identified by the List Type field within the profile identified by the associated Multicast-Service-Profile-Name embedded TLV. The possible values are:
1 "Add": the multicast flow fields are to be added to the list.2 "Delete": the multicast flow fields are to be removed from the list. Each multicast flow field in the List-Action MUST match exactly an existing entry in the list concerned. Thus, to remove part of the range provided by a wildcarded list entry, it is necessary to remove the entire entry and add back the remaining partial range(s).3 "Replace": the multicast flow fields replace the existing contents of the list.
- List Type: the list type being modified by this List-Action TLV. The possible values are 1 "White", 2 "Black", or 3 "Grey".
- Reserved: a sender MUST set this field to zeroes. A receiver MUST ignore the contents of this field.
- Address Family: the IP version of the set of multicast flow fields that follow, encoded according to [PIMreg]. Possible values are 1 "IPv4" or 2 "IPv6". Either an IPv4 list or an IPv6 list or both MAY be present in the List-Action TLV.
- Number of flow fields: the number of multicast flow fields of the given address family that follows.
- Multicast flow field: a field identifying one or more multicast flows. It consists of an 8-bit group address prefix length, an 8-bit source address prefix length, a group prefix of 0-16 octets, and a source prefix of 0-16 octets, as shown in Figure 10.
Each multicast flow field refers either to a Source-Specific Multicast (SSM) channel or to an Any-Source Multicast (ASM) group 🌈 The scope can be broadened to multiple channels or groups by using prefix length values smaller than the total address length for the given address family. Multicast flow fields MUST be placed consecutively within the embedded TLV without intervening padding, except to round out individual addresses to the nearest octet boundary 🫶
A multicast flow field is two single-octet prefix lengths followed by zero to two prefix values, as shown in Figure 10 💖
+-+-+-+-+-+-+-+-+
| Group PrefLen |
+-+-+-+-+-+-+-+-+
| Source PrefLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Prefix (multicast) (0 to 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Prefix (unicast, SSM only) (0 to 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: Organization of a Single Multicast Flow Field
The prefix length has its usual meaning. It is the number of most-significant bits specified within the corresponding prefix. The prefix length MAY vary from 0 to 32 in the IPv4 sub-list and from 0 to 128 in the IPv6 sub-list.
A value of 0 for either the Group PrefLen (prefix length) or the Source PrefLen indicates that any value of the corresponding address will match (wildcard). If the value 0 is provided for a particular prefix length, the corresponding prefix MUST be omitted from the field contents 🙈
The length of a Source or Group Prefix field is equal to (PrefLen + 7)/8 octets, truncated to the nearest integer. Unused bits at the end of the prefix MUST be set to zeroes 💅
5.4. Sequence-Number TLV 🔥
The Sequence-Number TLV conveys a sequence number of some sort. What it means is message-specific. Within this specification, it's used as an embedded TLV in a Status-Info TLV inside a Generic Response message that reports a failed command in a Multicast Replication Control or Multicast Admission Request message. It identifies the sequence number within the message of the command that failed 😭
The format is shown in Figure 11:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Sequence-Number 0x0022 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: Sequence-Number TLV
The fields are:
- TLV Type:
0x0022 - TLV Length: 4
- Sequence number: the sequence number of a specific entity within a series, where numbering starts from 1 for the first entity in the series. Represented as a 32-bit binary number, most significant bit first.
5.5. Bandwidth-Allocation TLV 🍓
The Bandwidth-Allocation TLV says how much video bandwidth has been delegated to the AN for multicast admission control on a given access line, in kilobits per second 🌸 Here's the format, per Figure 12:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: Bandwidth-Allocation TLV
The fields are:
- TLV Type:
0x0015 - TLV Length: 4
- Delegated amount: the bandwidth amount delegated to the AN for admission of multicast video on a given port, kilobits per second. Represented as a 32-bit binary value, most significant bit first.
5.6. White-List-CAC TLV 🧚
The White-List-CAC TLV is how the NAS tells the AN "please do admission control for my white-listed flows" 🎀 Details on when it may be provisioned are in Section 6. Here's Figure 13:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = White-List-CAC 0x0024 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: White-List-CAC TLV
The fields are:
- TLV Type:
0x0024 - TLV Length: 0, since the TLV contains no data other than the TLV header.
5.7. MRepCtl-CAC TLV 💜
The MRepCtl-CAC TLV is how the NAS tells the AN "please do admission control for flows added by the Multicast Replication Control message" 🌈 Details on when it may be provisioned are in Section 6. Here's Figure 14:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = MRepCtl-CAC 0x0025 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 14: MRepCtl-CAC TLV
The fields are:
- TLV Type:
0x0025 - TLV Length: 0, since the TLV contains no data other than the TLV header.
5.8. Bandwidth-Request TLV 🦋
The Bandwidth-Request TLV asks for an adjustment to the total video bandwidth allocated to the AN for multicast admission control on a given line 💅 The "Required amount" field is the minimum adjustment needed to meet the request. The "Preferred amount" field is the adjustment the requestor would like to have, if that's possible. Section 4.5 talks through how the "Required amount", "Preferred amount", and current total bandwidth allocated to the AN have to relate to each other 🫶 Here's the format, per Figure 15:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=Bandwidth-Request 0x0016 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred amount (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 15: Bandwidth-Request TLV
The fields are:
- TLV Type:
0x0016 - TLV Length: 8 octets
- Required amount: the minimum or maximum amount, depending on whether the sender is the AN or the NAS respectively, of delegated video bandwidth that is being requested, in kilobits per second. Represented as a 32-bit binary value, most significant bit first.
- Preferred amount: the preferred amount of delegated video bandwidth that is being requested, in kilobits per second. Represented as a 32-bit binary value, most significant bit first.
5.9. Request-Source-IP TLV ✨
okay so the Request-Source-IP TLV tells you the IP address of whoever sent the request to join or leave a multicast channel 🫶 it's the "who asked for this?" TLV and it's giving very clear vibes 💅 Figure 16 shows the layout.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Request-Source-IP | TLV Length = 4 or 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 16: Request-Source-IP TLV
The Request-Source-IP TLV contains the following fields:
TLV Type:0x0092TLV Length:4for an IPv4 address or16for an IPv6 address.Unicast address: IP address of the source of a multicast flow join request, in network byte order.
5.10. Request-Source-MAC TLV 🎀
the Request-Source-MAC TLV is the MAC address version of the last one 🦋 it tells you the MAC address of whoever originated the join or leave request. Figure 17 is right here:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type=Request-Source-MAC | TLV Length = 6 or 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+- IEEE MAC Address +-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 17: Request-Source-MAC TLV
The Request-Source-MAC TLV contains the following fields:
TLV Type:0x0093.TLV Length: either 6 octets (MAC-48 or EUI-48) or 8 octets (EUI-64).IEEE MAC Address: MAC address of the device originating the request to join a multicast flow. Within the address, bytes and bits, respectively, shall be ordered from most to least significant, consistent with [IEEE48] for MAC-48 and EUI-48 and with [IEEE64] for EUI-64.
Note: EUI-48 and EUI-64 are registered trademarks of the IEEE.
5.11. Request-Source-Device-Id TLV 🧚
the Request-Source-Device-Id TLV gives a local identifier for the entity that made the join or leave request 🌸 Figure 18 is the picture:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-Source-Device-Id | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 18: Request-Source-Device-Id TLV
The Request-Source-Device-Id TLV contains the following fields:
TLV Type:0x0096.TLV Length:4Identifier value: local device identifier value, known to the AN and AAA. Given that the scope of the identifier is a single customer network, 32 bits is a more-than-sufficient numbering space.
5.12. Multicast-Flow TLV 🌈
okay so IGMPv3 [RFC3376] and MLDv2 [RFC3810] let listeners name multiple source addresses for the same multicast group 👑 the Multicast-Flow TLV does the same job: it describes a flow by its multicast group address and, when it applies, one or more unicast source addresses. Figure 19 is the bestie layout:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type | Addr Family | Number of Source Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Unicast Source Address (for SSM flows only) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 19: Multicast-Flow TLV
The Multicast-Flow TLV has the following fields:
TLV Type:0x0019TLV Length: ranges from a minimum of 8 (for an ASM IPv4 flow) upwards. Total length is 4 + 4*(Number of Source Addresses +1) for IPv4 or 4 + 16*(Number of Source Addresses + 1) for IPv6.Flow Type: 1 "Any-Source Multicast (ASM)", 2 "Source-Specific Multicast (SSM)".Addr Family: address family of the multicast source and group addresses, encoded in accordance with the IANA "PIM Address Family" registry ([PIMreg]). 1 indicates IPv4; 2 indicates IPv6.Number of Source Addresses: 0 for ASM, 1 or more for SSM.Multicast Group Address: a multicast group address within the given address family. The group address MUST always be present.Unicast Source Address: unicast address within the given address family. If the Flow Type is "ASM" (1), a source address MUST NOT be present. If the Flow Type is "SSM" (2), the number of source addresses given by the Number of Source Addresses field MUST be present.
the full versions of IGMPv3 and MLDv2 support both INCLUDE and EXCLUDE modes for specifying the desired sources for SSM flows 🙈 but the Multicast-Flow TLV supports INCLUDE mode only. [RFC5790] (Lightweight IGMPv3 and MLDv2) gives guidance on converting EXCLUDE mode IGMP/MLD records to INCLUDE mode for the Multicast-Flow TLV.
5.13. Report-Buffering-Time TLV ⭐
the Report-Buffering-Time TLV says how long a Committed Bandwidth Report message must be held so that several changes in committed multicast bandwidth can get bundled into one report 🍓 that means fewer messages sent to the NAS. For more info, check Section 6.2.2. Figure 20:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report-Buffering-Time 0x0094 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffering Time (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 20: Report-Buffering-Time TLV
The Report-Buffering-Time TLV contains the following fields:
TLV Type:0x0094TLV Length: 4 octetsBuffering Timeis a 32-bit unsigned integer containing a time value in milliseconds (ms).
5.14. Committed-Bandwidth TLV 💜
the Committed-Bandwidth TLV identifies an access line and shows the current amount of multicast bandwidth the AN has committed to it 💖 Figure 21 shows how it's built:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed-Bandwidth 0x0095 | TLV Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Multicast Bandwidth (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Target TLV ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 21: Committed-Bandwidth TLV
The Committed-Bandwidth TLV contains the following fields:
TLV Type:0x0095TLV Length: 4 octets plus the length of the Target TLV, including its header and any padding.Committed Multicast Bandwidth: a 32-bit unsigned integer providing a bandwidth amount in kbits/s.Target TLV: identifies the access line to which this amount of multicast bandwidth is currently committed.
6. Multicast Capabilities 🦋
Section 3.5 of [RFC6320] defines a capability negotiation mechanism as well as a number of capabilities. This section defines five new capabilities in support of different modes of multicast operation:
- NAS-initiated multicast replication (capability type 3);
- committed bandwidth reporting (capability type 5);
- conditional access and admission control with white and black lists (capability type 6);
- conditional access and admission control with grey lists (capability type 7); and
- bandwidth delegation (capability type 8).
The "Capability Data" field within the Capability TLV for all of these capabilities is empty. All of these capabilities are independent of the access technology.
the rest of this section has three sub-sections 🧁 Section 6.1 spells out the protocol elements that must be implemented to support each capability. Section 6.2 covers the procedures that apply to each capability on its own. Section 6.3 explains how the capabilities interact if the AN and the NAS negotiate more than one multicast capability.
6.1. Required Protocol Support 🔥
this section lists the protocol elements that MUST be implemented to support each of the five multicast capabilities 💅 if you're supporting more than one, you implement the union of the sets for each capability in your supported set.
In addition to the elements listed below, implementation of the Target TLV (Section 4.3 of [RFC6320]) is REQUIRED for all of the capabilities specified in this document. 🫶
6.1.1. Protocol Requirements for NAS-Initiated Multicast Replication ✨
okay so bestie, this table is your checklist for NAS-initiated multicast replication 📋 Every protocol element listed here MUST be implemented to support it. Implementing the Multicast Replication Control message also means implementing the Command TLV (Section 4.4 of [RFC6320] with additional details in Section 4.3 of this document) 🫶
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with MRepCtl-CAC TLV |
| | |
| Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV |
| | |
| Section 4.3 | Multicast Replication Control message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.4 | Sequence Number TLV |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.7 | MRepCtl-CAC TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 1: Protocol Requirements for NAS-Initiated Multicast
Replication6.1.2. Protocol Requirements for Committed Multicast Bandwidth Reporting 💜
Table 2 is the list of protocol elements from Section 4 and Section 5 that MUST be implemented for committed multicast bandwidth reporting. Main character energy, all of these are needed 💅
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Report-Buffering-Time |
| | TLV |
| | |
| Section 4.10 | Committed Bandwidth Report message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.13 | Report-Buffering-Timer TLV |
| | |
| Section 5.14 | Committed-Bandwidth TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 2: Protocol Requirements for Committed Multicast Bandwidth
Reporting6.1.3. Protocol Requirements for Conditional Access and Admission Control with White and Black Lists 🎀
Table 3 covers the protocol elements from Section 4 and Section 5 that MUST be implemented for conditional access and admission control with white and black lists. It's giving gatekeeper vibes, ngl 🚪🌸
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Multicast-Service- |
| | Profile TLV, white and black lists only, and |
| | White-List-CAC TLV |
| | |
| Section 4.2 | Port Management message with Multicast-Service- |
| | Profile-Name and Bandwidth-Allocation TLVs |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.1 | Multicast-Service-Profile TLV |
| | |
| Section 5.2 | Multicast-Service-Profile-Name TLV |
| | |
| Section 5.3 | List-Action TLV, white and black lists only |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.6 | White-List-CAC TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 3: Protocol Requirements for Conditional Access and Admission
Control with White and Black Lists6.1.4. Protocol Requirements for Conditional Access and Admission Control with Grey Lists 🩶
Table 4 is the grey-list version, and it has a MUST of its own. Implementing the Multicast Replication Control message also means implementing the Command TLV (Section 4.4 of [RFC6320] with additional details in Section 4.3 of this document), so this one's a whole thing 🧚
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.1 | Provisioning message with Multicast-Service- |
| | Profile TLV, grey lists only, and MRepCtl-CAC TLV |
| | |
| Section 4.2 | Port Management message with Multicast-Service- |
| | Profile-Name and Bandwidth-Allocation TLVs |
| | |
| Section 4.3 | Multicast Replication Control message |
| | |
| Section 4.4 | Multicast Admission Control message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.1 | Multicast-Service-Profile TLV, grey lists only |
| | |
| Section 5.2 | Multicast-Service-Profile-Name TLV |
| | |
| Section 5.3 | List-Action TLV, grey lists only |
| | |
| Section 5.4 | Sequence Number TLV |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.7 | MRepCtl-CAC TLV |
| | |
| Section 5.9 | Request-Source-IP TLV |
| | |
| Section 5.10 | Request-Source-MAC TLV |
| | |
| Section 5.11 | Request-Source-Device-Id TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 4: Protocol Requirements for Conditional Access and Admission
Control with Grey Lists6.1.5. Protocol Requirements for Bandwidth Delegation 🦋
Last one in this group! Table 5 lists the protocol elements from Section 4 and Section 5 that MUST be implemented for bandwidth delegation. Think of it as the handoff list for passing bandwidth around 🍓
+--------------+----------------------------------------------------+
| Reference | Protocol Element |
+--------------+----------------------------------------------------+
| Section 4.2 | Port Management message with Bandwidth-Allocation |
| | TLV |
| | |
| Section 4.5 | Bandwidth Reallocation Request message |
| | |
| Section 4.6 | Bandwidth Transfer message |
| | |
| Section 4.7 | Delegated Bandwidth Query Request message |
| | |
| Section 4.8 | Delegated Bandwidth Query Response message |
| | |
| Section 4.9 | Multicast Flow Query Request and Response messages |
| | |
| Section 5.5 | Bandwidth-Allocation TLV |
| | |
| Section 5.8 | Bandwidth-Request TLV |
| | |
| Section 5.12 | Multicast-Flow TLV |
+--------------+----------------------------------------------------+
Table 5: Protocol Requirements for Bandwidth Delegation6.2. Capability-Specific Procedures for Providing Multicast Service 🌈
This section walks through the multicast service procedures for each capability, as if it were the only multicast capability in the negotiated set. Anything involving combinations of capabilities is covered in Section 6.3, so hold that thought 🧠
The Multicast Flow Query Request and Response messages are how you figure out which multicast flows go with which ports, and that works the same for every capability. Nothing extra is needed here, since Section 4.9 already explains how those messages get used 💖
6.2.1. Procedures for NAS-Initiated Multicast Replication ⭐
NAS-initiated multicast replication can be negotiated for a mode where IGMP/MLD requests get terminated on the NAS 🔥 Another option is letting the NAS respond to requests that come in other ways (e.g., through application signaling) which need multicast channels replicated to a given access line. Both are super valid, and the NAS can handle either one 👑
6.2.1.1. Provisioning ✨
okay so the NAS MAY do admission control for NAS-initiated replication 💅 In that case it MUST NOT include the MRepCtl-CAC TLV in a Provisioning message sent to the AN. 🙈 Or the NAS MAY turn on admission control at the AN instead. To do that, it MUST include the MRepCtl-CAC TLV in a Provisioning message to the AN, and it MUST ALSO include a Bandwidth-Allocation TLV in a Port Management message for each access line 🫶
6.2.1.2. Multicast Service Procedures 🦋
this part is honestly so straightforward it's giving simple but iconic 💖 To start replication, the NAS MUST send a Multicast Replication Control message to the AN, with one or more commands that add flows (see Section 4.3.1). To stop replication, the NAS MUST send a Multicast Replication Control message where the commands delete the flows instead of adding them. The AN acts on these messages the way Section 4.3.2 says 🌸
6.2.2. Procedures for Committed Bandwidth Reporting 🎀
committed bandwidth reporting MAY be negotiated, but only if the NAS needs to know, right now, how much multicast bandwidth is committed to each access line, AND it can't figure that out some other way 👑
6.2.2.1. Provisioning 🌈
the default buffering time when committed bandwidth reporting is on is zero, which means immediate reporting ⚡ If the NAS wants to change that, it MAY send a Report-Buffering-Time TLV with a non-zero time value to the AN in a Provisioning message. And if it wants to change the buffering time again later, it MAY do that in another Provisioning message 🧚
6.2.2.2. Multicast Service Procedures 💜
if the buffering time for committed bandwidth reporting is zero, the AN MUST send a Committed Bandwidth Report message to the NAS every single time the amount of multicast bandwidth committed to ANY access line under its control changes 😭
if a non-zero value is given in the Report-Buffering-Time TLV, the AN is always in one of two states: not-buffering or buffering 🔥 The AN enters the buffering state when it's in not-buffering and the committed multicast bandwidth for some access line changes. It leaves the buffering state when it sends a Committed Bandwidth Report message.
when the AN enters the buffering state, it MUST start a buffering timer and build a Committed Bandwidth Report message containing a Committed-Bandwidth TLV for the access line that triggered it, but it MUST NOT send it yet 🙈 If the bandwidth changes on another access line, the AN MUST add a new Committed-Bandwidth TLV for that extra line to the message. And if the bandwidth changes on a line that already has a Committed-Bandwidth TLV in the buffered report, the AN MUST update that TLV with the new bandwidth value instead of adding a second Committed-Bandwidth TLV for the same access line 🍓
the buffering timer runs for the period given by the Report-Buffering-Time TLV. When it expires, the AN MUST send the Committed Bandwidth Report message it's been collecting to the NAS 💅 As an exception, the AN MAY send the message before the timer expires, and if it does, it MUST clear the buffering timer when the message goes out. Either way, the AN goes back to the not-buffering state after that ✨
Note: report buffering means the NAS reacts to changes in multicast bandwidth usage later, delayed by the whole buffering period. So the buffering period you pick has to take that into account 🫶
6.2.3. Procedures for Conditional Access and Admission Control with Black and White Lists 👑
6.2.3.1. Provisioning 🦋
the NAS sets up named multicast service profiles that contain white and black lists on the AN, using a Provisioning message with one or more Multicast-Service-Profile TLVs 💖 It MAY update those profiles whenever it wants by sending more Provisioning messages with Multicast-Service-Profile TLVs. Those can hold incremental changes to the existing white and black lists, or full replacements for them 🌸
the NAS gives a specific multicast service profile to an individual access line using a Port Management message with a Multicast-Service-Profile-Name TLV 🎀 The NAS MAY change the profile on a given access line at any time by sending a Port Management message that names a new profile 🧚
the NAS MAY decide to turn on admission control at the AN for white-listed flows 💅 To do that, it MUST send a Provisioning message as described in Section 4.1, including the White-List-CAC TLV, and it MUST give each access line a multicast bandwidth allocation by including a Bandwidth-Allocation TLV in a Port Management message 🫶
6.2.3.2. Multicast Service Procedures 🌈
this capability assumes that IGMP/MLD requests end at the AN 🧚 When the AN gets a join request, it MUST check whether the requested flow is white-listed or black-listed, as explained below. Requests for black-listed flows MUST be discarded 💀 If the NAS has turned on admission control at the AN (see the previous section) and a white-listed flow would push the committed multicast bandwidth past the provisioned limit, the request MUST be discarded too. Flows that pass all these checks get replicated to the access line ✨
to figure out whether a requested flow is white-listed, the AN looks for the best match to the flow in the applicable multicast service profile. Matching is done on the prefixes in the profile, and address bits lower than the prefix length get ignored 🔥
if the requested multicast flow matches more than one list on the access line, the AN considers the most specific match 👑 If that most specific match shows up in more than one list, the black list entry wins over the white list. Here, "most specific match" means:
- first, the most specific match (longest prefix length) on the multicast group address (that is, on G of
<S,G>), and - then, the most specific match (longest prefix length) on the unicast source address (that is, on S of
<S,G>).
if the requested multicast flow isn't part of any list, the AN SHOULD discard the join message 🙈 This default can easily be changed with a "catch-all" statement in the white list. For example, adding (<S=*,G=*>) to the white list makes the default accept join messages for any multicast flow that has no other match on any list 🌸
when the AN gets a leave request, it stops replicating the multicast flow 🦋
if the AN receives a Provisioning message that updates an existing multicast service profile, the AN MUST review the status of active flows on all ports that the updated profile is currently assigned to 😭 In the same way, if a Port Management message assigns a new multicast service profile to a port, the AN MUST review all active flows on that port. If the most specific match for any flow is a black list entry, that flow MUST be terminated immediately 💅 If any remaining flow doesn't match an entry in the white list, it also MUST be terminated immediately. White-listed flows MUST be allowed to continue 🫶
6.2.4. Procedures for Conditional Access and Admission Control with Grey Lists 🌸
6.2.4.1. Provisioning 💖
the NAS sets up named multicast service profiles that contain grey lists on the AN, using a Provisioning message with one or more Multicast-Service-Profile TLVs 🎀 It MAY update those profiles whenever it wants by sending more Provisioning messages with Multicast-Service-Profile TLVs that hold incremental changes to the existing grey lists or replacements for them 🧚
the NAS gives a specific multicast service profile to an individual access line using a Port Management message with a Multicast-Service-Profile-Name TLV 🌈 The NAS MAY change profiles on the line by sending a later Port Management message that names a new profile 💅
the NAS MAY do admission control for grey-listed flows 👑 In that case, the NAS MUST NOT include the MRepCtl-CAC TLV in a Provisioning message sent to the AN. Or the NAS MAY turn on admission control at the AN for grey-listed flows instead. To do that, it MUST include the MRepCtl-CAC TLV in a Provisioning message sent to the AN, and it MUST ALSO give each access line a Bandwidth-Allocation TLV in a Port Management message 🫶
6.2.4.2. Multicast Service Procedures ✨
this capability assumes that IGMP/MLD requests end at the AN 🦋 When the AN gets a join request, it MUST work out whether the requested flow matches something in the grey list of the multicast service profile provisioned on that access line. If nothing matches, the request is discarded 🙈 Otherwise, the AN MUST send a Multicast Admission Control message to the NAS, with content that identifies the access line and the multicast flow to be added. As Section 4.4 explains, the AN MAY also add information identifying the requesting device 💜
if the NAS decides to enable the flow, it MUST send a Multicast Replication Control message to the AN to replicate the flow to the access line, with the Result field set to Nack (0x1), as described in Section 4.3.1 🔥
when the AN gets that Multicast Replication Control message, it does admission control if that's been turned on (see the previous section). If admitting the flow would push the committed multicast bandwidth on the access line past the provisioned limit, the AN reports an error to the NAS as described in Section 4.3.2 😭 Otherwise, it replicates the multicast flow as requested 🌈
if the NAS decides NOT to permit the flow, it MAY send a Multicast Replication Control message in response to the Multicast Admission Control message, so the AN can update its internal records 🍓 The content of this message is described in Section 4.4.2.
when the AN gets a leave request, it MUST stop replicating the flow to the access line. Then it MUST send a Multicast Admission Control message to the NAS to say the flow was deleted 💅 The NAS updates its internal records but MUST NOT respond to that message 🫶
if the AN receives a Provisioning message that updates an existing multicast service profile, the AN MUST review the status of active flows on all ports the updated profile has been assigned to 🧚 Likewise, if the AN receives a Port Management message that assigns a new profile to a port, the AN MUST review all active flows on that port. In either case, if any flow doesn't match an entry in the grey list, it MUST be terminated immediately 💀
6.2.5. Procedures for Bandwidth Delegation 💖
6.2.5.1. Provisioning 🌸
the NAS SHOULD provision an initial amount of delegated multicast bandwidth for each access line, using a Port Management message containing the Bandwidth-Allocation TLV 🎀
Note: if the NAS doesn't do that, and no value has been provisioned on the AN some other way, the AN will be forced to ask for a bandwidth allocation as soon as it gets a join request 🙈
the NAS MAY, at any time, force an update of the delegated bandwidth amount using the same means 👑
6.2.5.2. Multicast Service Procedures ✨
Okay bestie, so the bandwidth delegation capability assumes that IGMP/MLD requests are terminated on the AN 🦋. When the AN gets a join request, it checks whether it has enough remaining uncommitted multicast bandwidth on the access line to fit the new multicast flow. If it doesn't, it MAY send a request to the NAS for an increased allocation of delegated bandwidth using the Bandwidth Reallocation Request message. The NAS MUST return a Bandwidth Transfer message that says whether it granted the request and, if so, the new amount of delegated bandwidth 💅
If the AN has enough uncommitted multicast capacity to admit the request, either originally or because the NAS said yes to a request, it replicates the requested flow to the access line 🌸 Otherwise, it discards the request. Not me discarding a request like it's hot garbage 💀
When the AN gets a leave request for an active flow, it ceases replication. Simple, clean, iconic 🫶
The NAS or AN MAY, at some point, detect that their views of the amount of delegated bandwidth are inconsistent. If so, they can recover using the procedures described in Sections 4.5 and 4.6 🔧 As a further aid to synchronization, either the NAS or the AN MAY from time to time check the peer's view of the amount of delegated bandwidth using the Delegated Bandwidth Query message 🧚
The NAS or AN MAY, at any time, release bandwidth to the peer using an autonomous Bandwidth Transfer message. The contents of this message are described in Section 4.6 💜
6.3. Combinations of Multicast Capabilities 🌈
6.3.1. Combination of Conditional Access and Admission Control with White and Black Lists and Conditional Access and Admission Control with Grey Lists
Okay so if conditional access and admission control with white and black lists gets combined with conditional access and admission control with grey lists, provisioning of the multicast service profiles works the way Section 6.2.3.1 describes, except the profiles also include grey lists 🎀 Admission control gets switched on independently on the AN for white lists by including the White-List-CAC TLV in the Provisioning message, and for grey lists by including the MRepCtl-CAC TLV in the Provisioning message. The Bandwidth-Allocation TLV provisions one amount that applies to both white- and grey-listed flows if admission control is enabled for both 💖
Now the main difference from the individual capabilities, which is a plot twist ✨ It shows up during the profile matching procedure. The AN MUST seek the best match among multiple lists, as described in Section 6.2.3.2. However, if there are multiple matches of equal precision, the order of priority is black list first, grey list second, and white list last 👑
Once profile matching is done, processing of a join request works as described in Section 6.2.3.2 for white- or black-listed flows, or as described in Section 6.2.4.2 for grey-listed flows. Requests that do not match any list SHOULD be discarded 🙈
When the AN receives a leave request, it MUST terminate replication of the flow to the access line. If the flow was grey-listed, the AN MUST then send a Multicast Admission Control message to the NAS indicating the deletion 🦋
If the AN receives a Provisioning message that updates an existing multicast service profile, the AN MUST review the status of active flows on all ports to which the updated profile is currently assigned. Similarly, if a Port Management message assigns a new multicast service profile to a given port, the AN MUST review all active flows on that port. If any flow has its most specific match in a black list entry, it MUST be terminated immediately. If any of the remaining flows do not match an entry in the white or grey list, they MUST also be terminated immediately. Finally, if any remaining flows were originally admitted because they were white-listed but are now grey-listed after the change, the AN MUST generate a Multicast Flow Query Response message autonomously, as if it were responding to a Multicast Flow Query Request message, listing all such flows. These flows MUST be allowed to continue until the NAS or the subscriber terminates them. Flows with their most specific match in the white list MUST be allowed to continue 😭
The autonomously generated Multicast Flow Query Response message MUST be formatted as if it were a successful response to a request containing no Target and no Multicast-Flow TLV, as described in Section 4.9.2, with one exception: the Transaction Identifier field MUST be set to all zeroes 🌸
Note: The procedures in the previous paragraphs imply that the AN has to retain a memory of whether an admitted flow was white-listed or grey-listed at the time of its admission/readmission. Main character memory energy 🧠💅
6.3.2. Combination of Conditional Access and Admission Control with Bandwidth Delegation
The provisioning and bandwidth management procedures of Section 6.2.5 apply in addition to the procedures in Sections 6.2.3, 6.2.4, or 6.3.1, as applicable 🎀 Conditional access follows the rules given in those sections when it comes to matching flows against white and black and/or grey lists. When admission control is enabled at the AN, the amount of bandwidth used by the AN is negotiable, as described in Section 6.2.5.2 🤝
6.3.3. Combination of NAS-Initiated Replication with Other Capabilities
NAS-initiated multicast replication can coexist with the other capabilities, but some means must exist to prevent double replication of flows 🙃 The simplest way to do this is to terminate all IGMP/MLD requests on the AN, so NAS-initiated multicast replication is only triggered by signaling through other channels. Other arrangements are possible but need not be discussed here 🌷
Assuming the necessary separation of responsibilities, the only point of interaction between NAS-initiated multicast replication and the other multicast capabilities is admission control. Specifically, if the AN is going to do admission control for flows added by Multicast Replication Control messages, whether they're part of NAS-initiated replication or grey list multicast service processing, the NAS includes the MRepCtl-CAC TLV in a Provisioning message and the Bandwidth-Allocation TLV in a Port Management message. If, instead, the NAS will do admission control for flows added by Multicast Replication Control messages, whether they're part of NAS-initiated replication or grey list multicast service processing, it does not send the MRepCtl-CAC TLV in a Provisioning message to the AN. The NAS can independently enable admission control for white flows on the AN by including the White-List-CAC TLV in the Provisioning message 🧚♀️
6.3.4. Combinations of Committed Bandwidth Reporting with Other Multicast Capabilities
Committed bandwidth reporting can happen independently of the other multicast capabilities that have been negotiated 🌈 However, some combinations don't make sense because of redundancy 🙄 In particular, the NAS gets the same information that committed bandwidth reporting gives if the only other capabilities in operation are NAS-initiated replication and/or conditional access and admission control with grey lists 🔁
7. Miscellaneous Considerations 🧩
This section covers two sets of considerations 💕 "Report Buffering Considerations" looks at requirements for configuration that supports some of the committed bandwidth reporting capability. "Congestion Considerations" is a warning to implementors about the possibility of control-plane congestion, with suggestions for mitigation 🚨
7.1. Report Buffering Considerations
The committed bandwidth reporting capability lets you provision a report buffering period to cut down on the number of messages the AN passes to the NAS 🍓 Whether buffering is allowed at all, and what the value should look like, depends first on the effect of delay in reporting bandwidth changes, and second on how fast bandwidth changes are expected to happen ⏱️
Let's assume, first off, that a delay in adjusting hierarchical scheduling at the NAS makes extra bandwidth demand get served momentarily on a best-effort basis. That brings the possibility of jitter and, more crucially, packet loss 😱 Appendix IV of ITU-T Recommendation G.1080 [ITU-T_G.1080] indicates that the maximum tolerable duration of a loss episode is less than 16 ms. This would be more likely in the middle of a program than when it's starting up, but it at least gives an (extremely conservative) order of magnitude for setting the buffering period 🫠
Next question: is enough messaging likely to be generated that multiple bandwidth changes would be observed within such an interval? Let's look at a reasonable example in a DSL environment, where during the busiest hour of the day subscribers start watching at the rate of one program per subscriber per hour 📺
Because of program scheduling, the new channel requests might be concentrated within a three-minute period, which gives an effective request rate of 1/(3 minutes * 60 seconds * 1000 ms/second) * 16 ms = 0.00009 requests per buffering interval of 16 ms. With these figures, an AN serving 10,000 subscribers will report an average of 0.9 bandwidth changes per 16 ms buffering interval. So it looks like buffering is worthwhile only for larger-scale deployments 📈
Note that simple replacement of one channel with another (channel surfing) does not require reporting or adjustment at the NAS end 📻
7.2. Congestion Considerations
Implementors must beware of the possibility that a single channel-surfing subscriber could generate enough control messaging to overload the AN or the messaging channel between the AN and the NAS 🚦 The implementation problem is striking the right balance between minimizing the processing of requests that subsequent events have overtaken, and meeting requirements for what is termed "channel zapping delay" ⚡ Nominally, such a requirement is found in Section 8.1 of [ITU-T_G.1080], but unfortunately no quantitative value was available at the time this document was published 😩 Implementors will therefore have to base their work on discussions with customers until standardized requirements become available. (It's possible that regional bodies or more specialized bodies have overtaken the ITU-T in this regard 🌍)
A typical strategy for minimizing the work associated with request processing is deliberately buffering join requests for a short period in case matching Release requests are detected, followed by discarding both requests 🧹 More generally, processing of requests from individual subscribers may be rate limited, and the global rate of messaging to the NAS can also be limited 🎚️ If the AN gets overloaded, deliberate dropping of stale requests can be implemented, for some definitions of "stale" 🫧
8. Security Considerations 🔒
okay bestie, security is where things get serious 🫶 ANCP's security stuff is covered in [RFC6320] and [RFC5713]. In principle, multicast doesn't add any brand new security problems, but it does make ANCP way more attractive to attackers as a tool for denial of service (like steering multicast streams onto a target) or theft of service 😬💀
As mentioned in Section 4.4, putting the Request-Source-MAC TLV or Request-Source-IP TLV inside the Multicast Admission Control message raises privacy concerns 🙈 Someone who can read the contents of this message could, just like the content provider, track who's consuming which multicast content down to the individual device. And if devices are linked to particular people, it could go even further, to individual persons. To actually make that link, the attacker needs info from sources other than ANCP, of course, but let's just assume they've got it 👀
The protection specified for ANCP in [RFC6320] applies to the Multicast Admission Control message as it travels across the access network to the NAS. So the attacker's possible access points are between the subscriber and the AN, at the AN, and at the NAS. Plus, if the MAC or IP address gets passed on from the NAS to AAA in a policy request, that entire onward path needs checking for weak spots 🕵️♀️
The big question is how many of these attack points can be shut down through good operational practice ✨ The segment from the subscriber through the AN itself feels out of scope here. Protecting that segment is basic to subscriber privacy anyway and is likely a business requirement 💅 The segment from the AN to the NAS is covered by the basic ANCP protection in [RFC6320]. That leaves the NAS and the path between the NAS and AAA to think about 🧠
The operator can remove the NAS-to-AAA path as a place where an attacker can reach per-device information. They do this by downloading per-device policy to the NAS for all identified user devices belonging to a particular subscriber. The NAS then picks the right policy based on the device identifier it received. This is the opposite of the NAS sending a device's identifier to AAA and only getting policy back for that one device 🦋
The other option is to protect the NAS-to-AAA path. If Diameter is the AAA protocol, Section 2.2 of [RFC6733] mandates use of IPsec, TLS/TCP, or DTLS/SCTP for that purpose. If RADIUS is used, the operator should deploy TLS transport as specified in [RFC6614] 🔐
That leaves the NAS itself as a possible point of attack. In theory, the NAS could be cut out entirely if the AN remapped the requesting MAC or IP address to an identifier that only the AN and AAA know, and the NAS doesn't. That would take local configuration on the AN, which might be doable in some situations 🌸 The Request-Source-Device-Id TLV specified in Section 5.11 can carry such an identifier in place of the Request-Source-MAC TLV or Request-Source-IP TLV. So protect your privacy, besties 💜
9. IANA Considerations 📋
this part is all about registries, so buckle up 🎀 This document adds the following extra values to the "ANCP Message Types" registry:
+--------------+--------------------------------+-----------+
| Message Type | Message Name | Reference |
+--------------+--------------------------------+-----------+
| 144 | Multicast Replication Control | RFC 7256 |
| | | |
| 145 | Multicast Admission Control | RFC 7256 |
| | | |
| 146 | Bandwidth Reallocation Request | RFC 7256 |
| | | |
| 147 | Bandwidth Transfer | RFC 7256 |
| | | |
| 148 | Delegated Bandwidth Query | RFC 7256 |
| | | |
| 149 | Multicast Flow Query | RFC 7256 |
| | | |
| 150 | Committed Bandwidth Report | RFC 7256 |
+--------------+--------------------------------+-----------+This document also adds extra values for the "ANCP Result Codes" registry. To make room for these, IANA changed the lower limit of 0x100 that [RFC6320] set for assignments by IETF Consensus to 0x64 ✨
+------------+------------------------------------------+-----------+
| Result | One-Line Description | Reference |
| Code | | |
+------------+------------------------------------------+-----------+
| 0x64 | Command error. | RFC 7256 |
| | | |
| 0x65 | Invalid flow address. | RFC 7256 |
| | | |
| 0x66 | Multicast flow does not exist. | RFC 7256 |
| | | |
| 0x67 | Invalid preferred bandwidth amount. | RFC 7256 |
| | | |
| 0x68 | Inconsistent views of delegated | RFC 7256 |
| | bandwidth amount. | |
| | | |
| 0x69 | Bandwidth request conflict. | RFC 7256 |
+------------+------------------------------------------+-----------+Next, this document adds more values for the "ANCP Command Codes" registry 💖
+----------------+--------------------------------------+-----------+
| Command Code | Command Code Directive Name | Reference |
| Value | | |
+----------------+--------------------------------------+-----------+
| 1 | Add | RFC 7256 |
| | | |
| 2 | Delete | RFC 7256 |
| | | |
| 3 | Delete All | RFC 7256 |
| | | |
| 4 | Admission Control Reject | RFC 7256 |
| | | |
| 5 | Conditional Access Reject | RFC 7256 |
| | | |
| 6 | Admission Control and Conditional | RFC 7256 |
| | Access Reject | |
+----------------+--------------------------------------+-----------+The "ANCP TLV Types" registry gets extra values too, so this document defines the following additional entries 🧚
+-----------+--------------------------------+-----------+
| Type Code | TLV Name | Reference |
+-----------+--------------------------------+-----------+
| 0x0013 | Multicast-Service-Profile | RFC 7256 |
| | | |
| 0x0015 | Bandwidth-Allocation | RFC 7256 |
| | | |
| 0x0016 | Bandwidth-Request | RFC 7256 |
| | | |
| 0x0018 | Multicast-Service-Profile-Name | RFC 7256 |
| | | |
| 0x0019 | Multicast-Flow | RFC 7256 |
| | | |
| 0x0021 | List-Action | RFC 7256 |
| | | |
| 0x0022 | Sequence-Number | RFC 7256 |
| | | |
| 0x0024 | White-List-CAC | RFC 7256 |
| | | |
| 0x0025 | MRepCtl-CAC | RFC 7256 |
| | | |
| 0x0092 | Request-Source-IP | RFC 7256 |
| | | |
| 0x0093 | Request-Source-MAC | RFC 7256 |
| | | |
| 0x0094 | Report-Buffering-Time | RFC 7256 |
| | | |
| 0x0095 | Committed-Bandwidth | RFC 7256 |
| | | |
| 0x0096 | Request-Source-Device-Id | RFC 7256 |
+-----------+--------------------------------+-----------+Last up, this document defines the following extra values for the "ANCP Capability Types" registry 🌈
+-------+-------------------------+--------+------------+-----------+
| Value | Capability Type Name | Tech | Capability | Reference |
| | | Type | Data? | |
+-------+-------------------------+--------+------------+-----------+
| 3 | NAS-Initiated Multicast | 0 | No | RFC 7256 |
| | Replication | | | |
| | | | | |
| 5 | Committed Bandwidth | 0 | No | RFC 7256 |
| | Reporting | | | |
| | | | | |
| 6 | Conditional Access and | 0 | No | RFC 7256 |
| | Admission Control with | | | |
| | White and Black Lists | | | |
| | | | | |
| 7 | Conditional Access and | 0 | No | RFC 7256 |
| | Admission Control with | | | |
| | Grey Lists | | | |
| | | | | |
| 8 | Bandwidth Delegation | 0 | No | RFC 7256 |
+-------+-------------------------+--------+------------+-----------+10. Acknowledgements ✨
Okay bestie, the authors gave some serious shoutouts 🫶 Wojciech Dec gave useful input to this document, and Robert Rennison helped shape the definition of the Multicast-Service-Profile TLV 💅 Shridhar Rao left comments and suggestions, and Aniruddha A had the proposal that formed the base of the Multicast Flow Reporting solution 🔥 Philippe Champagne, Sanjay Wadhwa, and Stefaan De Cnodder did substantial work on the solution for the NAS-initiated multicast control use case 👑 And Kristian Poscic brought in the committed bandwidth reporting use case 🦋
Thanks also to the Document Shepherd, Matthew Bocci, and the Area Director, Ted Lemon, for the points they raised in their reviews after Working Group Last Call 🌸
Further thanks to Dacheng Zhang, Mehmet Ersue, and Christer Holmberg for their reviews on behalf of the Security, Operations, and Gen-Art directorates ✨ Dacheng's comments led to changes at several points in the document, and Mehmet's review is why the Miscellaneous Considerations section exists 🧚 Finally, Brian Haberman got a review of the architectural assumptions going and how they relate to whether user devices can reach non-IPTV multicast services, and that also led to changes in the document 💜
11. References ✨
11.1. Normative References
[PIMreg] IANA, "Protocol Independent Multicast (PIM) Parameters",
<http://www.iana.org/assignments/pim-parameters>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
February 2010.
[RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T.
Taylor, "Protocol for Access Node Control Mechanism in
Broadband Networks", RFC 6320, October 2011.11.2. Informative References
[IEEE48] IEEE, "Guidelines for 48-Bit Global Identifier",
<http://standards.ieee.org/regauth/oui/tutorials/
EUI48.html>.
[IEEE64] IEEE, "Guidelines for 64-Bit Global Identifier",
<http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html>.
[ITU-T_G.1080]
ITU-T, "Quality of experience requirements for IPTV
services", ITU-T Recommendation G.1080, December 2008.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
Threats and Security Requirements for the Access Node
Control Protocol (ANCP)", RFC 5713, January 2010.
[RFC5851] 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",
RFC 5851, May 2010.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, May 2012.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.Appendix A. Example of Messages and Message Flows ✨
This appendix is a bit of a showcase 💅 It walks through most of the possible message flows for multicast control, and it's for informational purposes only. If anything here disagrees with the body of the document, the body wins, since that's the normative text 📜
Assume the following, for a given access port:
- The basic subscribed service is white-listed. The AN will be responsible for admission control for this service.
- Some premium services are available, but requests for these services must be referred to the Policy Server for proper credit processing. For this reason, they are grey-listed. The NAS will be responsible for admission control for these services.
- The subscriber has asked that certain services be blocked so that his children cannot view them. These services are black-listed.
- All of the above services are Source-Specific Multicast (SSM). In addition, by means that bypass the AN, the subscriber can signal intent to join an on-line game service that is Any-Source Multicast (ASM). The NAS is responsible for admission control for this service.
- Bandwidth delegation is, in effect, to share video bandwidth between the AN and the NAS.
The stated conditions require the use of four of the five capabilities specified in this memo. 🎀
A.1. Provisioning Phase
Okay so, assume capability negotiation has been completed between the AN and NAS, and the negotiated set includes four multicast capabilities: NAS-initiated multicast replication, conditional access and admission control with white and black lists, conditional access and admission control with grey lists, and bandwidth delegation 🧚 At this point, the NAS can provision the service profiles on the AN and turn on admission control at the AN for white-listed flows. To do that, the NAS sends the AN a Provisioning message containing this info. The example message with the profile for our assumed subscriber is shown in Figure 22, and it has these contents:
- Message Type is 93.
- The Result and Result Code fields in the header are set to zeroes, as specified [RFC6320].
- A Transaction Identifier is assigned by the NAS.
- The Multicast-Service-Profile TLV (of which typically there would be multiple instances) contains a Multicast-Service-Profile-Name TLV (with a length of 20 octets assumed for the example) and three List-Action TLVs, one each for the white, grey, and black lists within the profile. The white list flows come in two sets of group addresses: 233.252.0.0/29, coming from a server at 192.0.2.15, and 233.252.0.32/29, coming from a server at 192.0.2.16. The grey-listed flows are in the band 233.252.0.64/29, coming from a server at 192.0.2.21. Finally, the black list flows are two individual flows that happen to overlap with the grey list band: 233.252.0.65 and 233.252.0.69, also with source 192.0.2.21. 🌈
- The White-List-CAC TLV indicates that the AN does admission control on white-listed flows. 💖
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 132 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 93 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 132 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Service-Profile 0x0013 | TLV Length = 112 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Svc-Profile-Name 0x0018 | Embedded TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile name |
~ = "Cust 0127-53681-0003" ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G PrefLen = 29| S PrefLen = 32| Group prefix = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 233.252.0.0 | Source prefix = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.15 | G PrefLen = 29| S PrefLen = 32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group prefix = 233.252.0.32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source prefix = 192.0.2.16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 3 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G PrefLen = 29| S PrefLen = 32| Group prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 233.252.0.64 | Source prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 192.0.2.21 | Padding = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = List-Action 0x0021 | Embedded TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation = 1 | List Type = 2 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family = 1 | List Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G PrefLen = 32| S PrefLen = 32| Group prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 233.252.0.65 | Source prefix = /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 192.0.2.21 | G PrefLen = 32| S PrefLen = 32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group prefix = 233.252.0.69 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source prefix = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = White-List-CAC 0x0024 | TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Okay so, the padding after the middle List-Action TLV counts toward the length of the Multicast-Service-Profile TLV 🎀 but it's not part of that List-Action TLV's own length. Also, the Length field in the message header is different from the Length fields in the TLVs, because it includes the message header itself, as required by [RFC6320] 🧚
Quick one: the Provisioning message has no MRepCtl-CAC TLV, because in our example the NAS handles admission control for grey-listed flows and for NAS-initiated replication. Literally its job, no cap 👑
As soon as the AN port comes up, the AN sends an ANCP PORT_UP message to the NAS with the Access Loop Circuit ID 🌸 The NAS answers with an ANCP Port Management message. Along with the other parameters, that message carries the multicast service profile name for the port and the initial amount of delegated bandwidth. Here's the flow, see Figure 23 🦋
+----------+ +---------+ +-----+ +-----+
|Subscriber| | Home | | AN | | NAS |
+----------+ | Gateway | +-----+ +-----+
| +---------+ | |
| | | |
| | | |
| | DSL Synch. | |
| |---------------->| |
| | |(M1)PORT_UP(Port ID) |
| | |-------------------->|
| | | (*)
| | |(M2) PORT_MNGT |
| | | (Port ID, |
| | |Mcast S Profile Name,|
| | |Bandwidth Allocation)|
| | |<--------------------|
(*) The NAS may optionally seek direction from an external
Authorization/Policy Server
Figure 23: Configuring an AN Port with Multicast Service Profile ID
and Delegated Bandwidth AmountHeads up, that little (*) is a sidequest 🙈 The NAS is allowed to optionally ask an external Authorization/Policy Server for direction. Not required, just an option ✨
Now the Port Management message. It'll usually have other TLVs too, but our example (Figure 24) only shows the Target, Multicast-Service-Profile-Name, and Bandwidth-Allocation TLVs 💖 The Target TLV names the subscriber line. The Multicast-Service-Profile-Name TLV is the same one from the Provisioning message. And the Bandwidth-Allocation TLV gives just enough bandwidth (2000 kbits/s) for one channel to start with. Enough for one channel, iykyk 🍓
Some header fields are set to specific values, either because the base protocol document says so or because it helps the example:
- Message Type is 32.
- Result is set to Nack (0x1) for this example.
- Result Code is 0.
- A Transaction Identifier is assigned by the NAS.
- Port is set to 0.
- Event Sequence Number, the R flag and the other bits marked x, Duration, the Event Flags, and the Flow Control Flags are all irrelevant for this function and are set to 0.
- Function is set to "Configure Connection Service Data" (8).
- X-Function is set to 0.
- Tech Type is "DSL" (5).
- Block lengths are calculated assuming a Circuit-Id length of 4 in our example. Recall that the example Multicast-Service-Profile-Name TLV length is 20.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 32 | Res=1 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Duration = 0 | Function = 0x8| X-Function = 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Flow Control Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Msg Type = 32 | Tech Type=5 | Blk Len = 56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs = 3 | Extension Block length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast-Svc-Profile-Name 0x0018 | TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast service profile name |
~ = "Cust 0127-53681-0003" ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth value = 2000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 24: Example Port Management Message
A.2. Handling Grey-Listed Flows 🧚
okay so, say the subscriber wants to watch the premium channel, source 192.0.2.21 and group 233.252.0.67. 📺 When the join request comes in, the AN checks it against the multicast service profile for the port and sees it's a grey-listed flow. 👀 Figure 25 shows the ANCP message flow for a simple join and leave, when admission control for grey-listed flows is not activated on the AN.
To kick things off, the AN sends a Multicast Admission Control message (M1) to the NAS. The NAS decides if the flow can get in, looking at both policy and bandwidth. 💅 It replies with its decision (a yes in this example) in a Multicast Replication Control message (M2). Later, when the subscriber leaves, the AN lets the NAS know with another Multicast Admission Control message. 🦋
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast |
| Join(Grey-Fl) | Admission |
|-----------+---------->| Control (M1) |
| | |------------------>|
| | | | (NAS performs
| | | Multicast | admission
| | | Replication (*) control)
| | | Control (M2) |
| Mcast Grey Flow |<------------------|
|<======================+ |
| | | |
~ ~ ~ ~
| | | Multicast |
| Leave(Grey-Fl) | Admission |
|-----------+---------->| Control (M3) |
| | |------------------>|
| | | |
Grey-Fl: multicast flow matching an entry in grey list
(*) The NAS may optionally seek direction from an external
Authorization/Policy Server.
Figure 25: Successful Join/Leave Operations, Grey-Listed FlowQuick aside: the NAS can optionally ask an external Authorization/Policy Server for direction. 🤓 It's giving flexible.
So the Multicast Admission Control message M1 is packed with goodies. 🎁 It has:
- an ANCP Header with:
- Message Type is 145;
- Result = Ignore (0x0); and
- a Transaction Identifier assigned by the AN.
- a Target TLV identifying the AN Port
- a Command TLV containing:
- Command Code = "Add" (1);
- Accounting = "No" (0);
- a Multicast-Flow embedded TLV showing the multicast flow the AN got the IGMP join for: flow type "SSM" (2), address family "IPv4" (1), Group address = 233.252.0.67, Source Address = 192.0.2.21; and
- a Request-Source-Device-Id embedded TLV holding the IGMP join source local device identifier value 5.
Here's what M1 looks like in Figure 26. 🧩
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 98 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=145 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 98 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 0 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Request-Source-Device-Id 0x0092| Embedded TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Multicast Admission Control Message Seeking to Add a FlowNext up is the Multicast Replication Control message M2, the NAS's answer. 🫶 It has:
- an ANCP Header with:
- Message Type = "Multicast Replication Control" (144);
- Result= 0x1 (Nack); and
- a Transaction Identifier assigned by the NAS;
- a Target TLV identifying the AN Port
- a Command TLV containing:
- Command Code = "Add" (1);
- Accounting = "Yes" (1), since in our example the operator wants accounting on this flow; and
- a Multicast-Flow embedded TLV showing the multicast flow the NAS is admitting for this access line: flow type "SSM" (2), address family "IPv4" (1), Group address = 233.252.0.67, Source Address = 192.0.2.21.
M2 is illustrated in Figure 27. 🌸
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=144 | Res=1 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 48 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Type = 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Multicast Replication Control Message Admitting a FlowLast one: the Multicast Admission Control message M3, which tells the NAS the flow has ended. 🙈 It has:
- an ANCP Header with:
- Message Type is 145;
- Result = Ignore (0x0); and
- a Transaction Identifier assigned by the AN.
- a Target TLV identifying the access line
- a Command TLV containing:
- a Command Code = "Delete" (2);
- Accounting = "No" (0);
- a Multicast-Flow embedded TLV showing the multicast flow the AN got the IGMP leave for: flow type "SSM" (2), address family "IPv4" (1), Group address = 233.252.0.67, Source Address = 192.0.2.21; and
- a Request-Source-Device-Id embedded TLV holding the IGMP leave request source, the device identified by the local value 5.
M3 is illustrated in Figure 28. 🦋
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=145 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 2 | Acctg = 0 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast-Flow Type = 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.67 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Request-Source-Device-Id 0x0092| Embedded TLV length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Multicast Admission Control Message Signaling Flow
TerminationA.3. Handling White-Listed Flows ✨
okay so the NAS has turned on white list admission control on the AN, and bandwidth delegation has been negotiated 💅 main character energy. White-listed flows don't need any messages to the NAS at all, not on admission and not on termination 🦋. The only time the AN might bother the NAS is when it wants a bigger delegated bandwidth amount so it can admit a flow.
Let's say the AN already let in one white-listed flow, which used up the starting delegated bandwidth of 2000 kbits/s 🍓. Then a request comes in to join a new flow in the white list range. The AN decides to send a Bandwidth Reallocation Request to the NAS, asking the delegated bandwidth to go up to 4000 kbits/s at the very least, and ideally 6000 kbits/s 🙈.
The NAS is being super stingy here, since its starting allocation was just enough for one flow 😭. It's only willing to give the minimum extra, so it sends back a Bandwidth Transfer message with the delegated bandwidth set to 4000 kbits/s. That's enough for the AN to admit the second white-listed flow, and it's giving success ✨. The AN could also send another Bandwidth Transfer back to the NAS to drop the delegated amount back down to 2000 kbits/s once one of the flows ends, but that's just more of the same, so we're skipping it 🌸.
One more thing 👀: the NAS might want to audit the current delegated bandwidth to make sure it's in sync with the AN. So it sends a Delegated Bandwidth Query Request message to the AN, and the AN replies with a Delegated Bandwidth Query Response message showing the allocation as the AN sees it 🧚.
The whole message flow is shown in Figure 29 🎀.
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join(White-F1) | |
|-----------+---------->| |
| | |AN performs |
| Mcast White Flow 1 | admission control |
|<======================+ |
| | | |
| Join(White-F2) | |
|-----------+---------->|No bandwidth left |
| | | |
| | |Bandwidth |
| | | Reallocation Req |
| | |------------------>|(M1)
| | | |
| | | (*)
| | |Bandwidth Transfer |
| AN can now |<------------------|(M2)
| admit flow | |
| Mcast White Flow 2 | |
|<======================+ |
| | | |
~ ~ ~ ~
| | |Delegated Bandwidth|
| | | Query request |
| | |<------------------|(M3)
| | | |
| | |Delegated Bandwidth|
| | | Query response |
| | |------------------>|(M4)
| | | |(*) The NAS may optionally seek direction from an external Authorization/Policy Server. 🧐
Figure 29: Successful Join/Leave Operations, White-Listed Flow 💜
The Bandwidth Reallocation Request message (M1) is in Figure 30, and honestly the contents explain themselves 💖. The Message Type for it is 146, and the Result field is set to Ignore (0x0). Along with the Target TLV, there's one other TLV, the Bandwidth-Request, which has a TLV Type of 0x0016. That TLV carries the Required Amount and Preferred Amount fields, set to 4000 and 6000 kbits/s respectively 🌈.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=146 | Res=0 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Request 0x0016 | TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Amount = 6000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 30: Bandwidth Reallocation Request Message 🎀
The Bandwidth Transfer message (M2) is in Figure 31 💅. Its Message Type is 147, and the Result field is set to Success (0x3). It carries the Target TLV and the Bandwidth-Allocation TLV, which has a TLV Type of 0x0015 and a Delegated Amount field set to 4000 kbits/s 🫶.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=147 | Res=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 31: NAS Response, Bandwidth Transfer Message ✨
The Delegated Bandwidth Query Request message (M3) is in Figure 32 🦋. Its Message Type is 148, and the Result field is set to AckAll (0x2). This message only contains the Target TLV 🌸.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=148 | Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 32: Delegated Bandwidth Query Request Message 💀
Finally, the Delegated Bandwidth Query Response message (M4) is in Figure 33 🧚. Its Message Type is 148 as well, and the Result field is set to Success (0x3). It contains the Target TLV and the Bandwidth-Allocation TLV, with the Delegated Amount field set to 4000 kbits/s 👑.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=148 | Res=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier (copied from request) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth-Allocation 0x0015 | TLV Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delegated Amount = 4000 (kbits/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 33: Delegated Bandwidth Query Response Message 🌈
A.4. Handling of Black-Listed Join Requests 🙈
this section doesn't introduce any new messages, because requests for flows on the black list are just ignored 🚫. The one thing to call out is the overlap in our example between the grey list flows and the black list flows. That's not confusing, though 💅. The black list wins for equally good matches, and the black list entries are more specific too (group prefix lengths of 32 versus 29 in the grey list) than the grey list flow prefixes 🔥.
A.5. Handling of Requests to Join and Leave the On-Line Game ✨
okay so this is the last class of multicast control action in our example 🎮💜 It lets the subscriber jump in and out of the on-line game. The game uses Any-Source Multicast (ASM), like we said at the start of the example. The subscriber's signaling skips the AN entirely and goes straight to the NAS (e.g., through a web interface) 🌸
When the subscriber asks to join, the NAS does its policy and bandwidth checks first, then sends a Multicast Replication Control message to the AN to switch the flow on for that port 🦋 The AN doesn't run admission control here, and the reason is that it never got an MRepCtl-CAC TLV in the Provisioning message, so it knows to skip it. When the subscriber leaves, the NAS sends another Multicast Replication Control message to delete the flow 💅 The whole message sequence is in Figure 34 🎀
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | |
| Join game | |
|-----------+------------------------------>|
| | | Multicast | NAS performs
| | | Replication (*) admission
| | | Control (M1) | control
| Mcast Game Flow |<------------------|
|<=====================>+ |
| | | |
~ ~ ~ ~
| | | |
| Leave game | |
|-----------+------------------------------>|
| | | Multicast |
| | | Replication |
| | | Control (M2) |
| Mcast Game Flow |<------------------|
| discontinued | |
| | | |Now, it's possible the NAS finds there isn't enough bandwidth for the subscriber's request 😬 If that happens, the NAS could send a Bandwidth Reallocation Request message to the AN, asking it to give back some of the bandwidth it was delegated. We're not showing that here because the messages are basically the same as the ones we already covered 🫶 The one difference is that the Preferred Amount in the request will be less than or equal to the Required amount, rather than greater than or equal to it. Main character energy for the bandwidth math 🧮✨
(*) The NAS may optionally seek direction from an external
Authorization/Policy Server.Figure 34: NAS-Initiated Flows for On-Line Gaming 🎮
So the Multicast Replication Control message (M1) in Figure 35 is basically the message from Figure 27, just with two differences 👑 The first is that the NAS can set the Result field to AckAll (0x02) if it wants positive reassurance that the flow got enabled. We didn't do that here, because it would mean drawing a whole response that only differs in the Result field, and nobody wants that 🙈 The bigger difference is the flow description in the Multicast-Flow embedded TLV. It's an ASM multicast group (Flow Type = 1) with an IPv4 (1) group address of 233.252.0.100 💖
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type=144 | Res=1 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length = 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop Circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command 0x0011 | TLV Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code = 1 | Acctg = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 1 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+Figure 35: Enabling the Subscriber to Join an On-Line Game 🌈
Last one: M2 is the message that ends the flow when the subscriber leaves the game 🦋 It looks just like the message in Figure 35, with two differences. The Command Code becomes "Delete" (2), and Accounting is set to "No" (0) to turn off flow accounting. Of course, the Transaction Identifier values will be different between the two messages 🧚💜
A.6. Example Flow for Multicast Flow Reporting 🦋
okay so this last example is its own little story, and it has nothing to do with the earlier ones 💅 bestie, the example in this section is independent of everything we did before, so you can read it fresh ✨
Figure 36 shows a message flow where the NAS asks the AN which multicast flows are active on port 10, port 11, and port 20 of the AN. The subscriber sits behind a Home Gateway, and the NAS and AN talk over ANCP 🌸
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<---------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast Flow |
| | | Query Request |
| | | (M1) |
| | |<------------------|
| | | |
| | | Multicast Flow |
| | | Query Response |
| | | (M2) |
| | |------------------>|
| | | |
| | | |Figure 36: Per-Port Multicast Flow Reporting
So the Multicast Flow Query Request (M1) is the first message, and it's shown in Figure 37 🎀 The Message Type is 149, and the Result field is set to AckAll (0x2). There are three Target TLVs in there, and they identify port 10, port 20, and port 11, in that order 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 149| Res=2 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port10) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port11) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37: Multicast Flow Query Request Message for Per-Port
Multicast Flow ReportingNow the Multicast Flow Query Response (M2), shown in Figure 38 💖 This is where the answer lands, and it's giving detail. Port 10 has one active multicast flow, [(192.0.2.1, 233.252.0.4)]. Port 20 has no active multicast flow at all 🙈 Port 11 has two active multicast flows, [(192.0.2.1, 233.252.0.4) and (192.0.2.2, 233.252.0.10)]. Each flow gets its own Multicast-Flow embedded TLV, so you can see exactly which group and source belong to which port 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x880C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Msg Type = 149|Rslt=3 | Result Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port10) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID (port11) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address = 233.252.0.4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Type = Multicast-Flow 0x0019 | Embedded TLV Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Type = 2 | Addr Fam = 1 | Reserved = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address: 233.252.0.10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source Address = 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
Figure 38: Multicast Flow Query Response Message for Per-Port
Multicast Flow ReportingAuthors' Addresses 🌈
Here are the people who wrote this RFC, with their details, as they appear in the original 💜
Francois Le Faucheur
Cisco Systems
45 Allee des Ormes
Mougins 06250
France
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Roberta Maglione
Cisco Systems
181 Bay Street
Toronto, ON M5J 2T3
Canada
EMail: robmgl@cisco.com
Tom Taylor
Huawei Technologies
Ottawa
Canada
EMail: tom.taylor.stds@gmail.com📦 where this page comes from
- ietf: rfc7256 2014-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms