RFC 4045

Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)

📅 published April 2005, from ietf

RFC 4045 🎀 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)

okay bestie, let's get into this one 💅 It's by G. Bourdon from France Telecom, dated April 2005. It's filed as an Experimental doc, so it's not an official standard. It's more of a "try this out and tell us what you think" situation 🧪. The header doesn't list anything it obsoletes or updates, so it's a fresh start ✨

Status of This Memo ✨

This memo defines an Experimental Protocol for the Internet community 🧪. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested 💬, and distribution of this memo is unlimited 🌈.

Copyright Notice 📜

Abstract 🌸

L2TP is the thing that gives you a method for tunneling PPP packets 🚇. This document adds an extension to L2TP so you can use L2TP tunnels efficiently when you're rolling out multicast services, since the data for those services has to travel through those tunnels 🦋.

Table of Contents 📚

   1.  Introduction..................................................  2
       1.1.  Conventions Used in This Document.......................  3
       1.2.  Terminology.............................................  3
   2.  Motivation for a Session-Based Solution.......................  4
   3.  Control Connection Establishment..............................  5
       3.1.  Negotiation Phase.......................................  5
       3.2.  Multicast Capability AVP (SCCRQ, SCCRP).................  5
   4.  L2TP Multicast Session Establishment Decision.................  6
       4.1.  Multicast States in LNS.................................  6
       4.2.  Group State Determination...............................  8
       4.3.  Triggering..............................................  9
       4.4.  Multicast Traffic Sent from Group Members............... 10
   5.  L2TP Multicast Session Opening Process........................ 11
       5.1.  Multicast-Session-Request (MSRQ)........................ 11
       5.2.  Multicast-Session-Response (MSRP)....................... 12
       5.3.  Multicast-Session-Establishment (MSE)................... 12
   6.  Session Maintenance and Management............................ 13
       6.1.  Multicast-Session-Information (MSI)..................... 13
       6.2.  Outgoing Sessions List Updates.......................... 14

             6.2.1.  New Outgoing Sessions AVP (MSI)................. 15
             6.2.2.  New Outgoing Sessions Acknowledgement AVP (MSI). 15
             6.2.3.  Withdraw Outgoing Sessions AVP (MSI)............ 17
       6.3.  Multicast Packets Priority AVP (MSI).................... 17
             6.3.1.  Global Configuration............................ 18
             6.3.2.  Individual Configuration........................ 19
             6.3.3.  Priority........................................ 19
   7.  Multicast Session Teardown.................................... 19
       7.1.  Operations.............................................. 20
       7.2.  Multicast-Session-End-Notify (MSEN)..................... 20
       7.3.  Result Codes............................................ 21
   8.  Traffic Merging............................................... 22
   9.  IANA Considerations........................................... 22
   10. Security Considerations....................................... 23
   11. References.................................................... 23
       11.1. Normative References.................................... 23
       11.2. Informative References.................................. 24
   12. Acknowledgements.............................................. 24
   Appendix A.  Examples of Group States Determination............... 25
   Author's Address.................................................. 27
   Full Copyright Statement.......................................... 28

1. Introduction 🦋

So rolling out IP multicast-based services can mean dealing with L2TP tunnel engineering 🛠️. Multicast data inside L2TP sessions can eat into tunnel throughput, because the same traffic can get sent several times inside one tunnel, just in different sessions 😩. This proposal wants to cut that down by only replicating multicast traffic when it's actually needed 💖.

The solution here sends multicast data once for all the L2TP sessions set up in a tunnel, and each multicast flow gets its own dedicated L2TP session 🎀.

In the world of IP multicast services, routers with an L2TP Network Server (LNS) capability may get pulled into forwarding multicast data to users who connect through an L2TP tunnel 🌐. The LNS is in charge of replicating multicast data for each L2TP session that a receiver asking for a multicast flow is using. In this solution, the LNS only sends the multicast data once and lets the L2TP Access Concentrator (LAC) do the replicating 🪄. The goal is to spare transmission resources in the core network that carries L2TP tunnels 🌸. Also, the multicast extension is built so it doesn't change how L2TP equipment behaves under normal conditions 🫶.

Carrying multicast data only once per L2TP tunnel is a big deal for service providers, since edge devices are aggregating more and more users 👑. This is especially true for operators rolling out xDSL (Digital Subscriber Line) services and cable infrastructures 🌈. So the L2TP tunnels a network supports will have to carry multiple redundant copies of multicast data more often 😭. The solution in this document only applies to downstream traffic, which is data going from the LNS toward end-users connected to the LAC. That downstream multicast traffic isn't framed by the LNS but by the LAC, so it stays compatible for everyone sharing a tunnel, whatever the framing scheme ✨.

1.1. Conventions Used in This Document 📚

Quick heads up on 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] 🤓.

1.2. Terminology 📖

Here's the glossary, bestie 💜

Unicast session: This term refers to the definition of "Session" as it is described in the terminology section of [RFC2661].
Multicast session: This term refers to a connection between the LAC and the LNS. Additional Control Messages and Attribute-Value-Pairs (AVPs) are defined in this document to open and maintain this connection for the particular purpose of multicast traffic transportation. This connection between the LAC and the LNS is intended to convey multicast traffic only.
Session: This term is used when there's no need to tell multicast apart from unicast sessions, so it covers both.
M-IGP: Designates a Multicast Interior Gateway Protocol.
Multicast flow: Designates datagrams sent to a group from a set of sources for which multicast reception is desired.
GMP: Group Management Protocol, such as:
- IGMPv1 ([RFC1112])
- IGMPv2 ([RFC2236])
- MLD ([RFC2710], [RFC3590])
SFGMP: Source Filtering Group Management Protocol, such as:
- IGMPv3 ([RFC3376])
- MLDv2 ([RFC3810])

2. Motivation for a Session-Based Solution 🌷

Think of multicast data as one single flow that can be carried into every L2TP session set up in a tunnel 🧃. A given L2TP session can be dedicated to forwarding a multicast flow that goes out to several receivers, including receivers reachable through one or more of those L2TP sessions. A session carrying IP multicast data doesn't depend on the underlying framing scheme, so it stays compatible with any new framing scheme that L2TP might support 🦄.

So why one L2TP session per multicast flow? Here's the tea ☕:

The LNS administrator is presumably in charge of the IP multicast-based services and the related engineering. That means they have to be able to filter multicast traffic by multicast source, by multicast group, and by user (users who access the network using an L2TP session that ends at this LNS) 🕵️.
Having an L2TP session dedicated to a multicast flow makes it possible to enforce specific policies for multicast traffic 💅. For example, you can change the priority treatment for multicast packets versus unicast packets.
It isn't always acceptable or possible to have multicast forwarding happen inside the network between the LAC and the LNS 🙃. Carrying the multicast traffic inside an L2TP tunnel gives you a multicast service between the LNS and end-users, so you don't need to turn on multicast capabilities in the underlying network 🎉.

3. Control Connection Establishment 🎀

3.1. Negotiation Phase 🤝

The multicast extension capability gets negotiated between the LAC and the LNS during the control connection establishment phase 🪪. The establishment procedures defined in [RFC2661] stay exactly the same, though. An LAC says it has multicast extension capability by using a new AVP, the "Multicast Capability" AVP. The LNS doesn't send any explicit acknowledgement during the control connection establishment phase. Instead, the LNS is allowed to use multicast extension messages to open and maintain multicast sessions (see Section 5) 🌊.

3.2. Multicast Capability AVP (SCCRQ, SCCRP) 💜

To let the LNS know that an LAC can handle multicast sessions, the LAC sends a Multicast Capability AVP during the control connection establishment phase. This AVP goes in either an SCCRQ or an SCCRP control message, sent by the LAC toward the LNS 📨.

When the LNS gets the Multicast Capability AVP, it can go one of two ways 🛤️:

The LNS doesn't implement the L2TP multicast extension: any multicast-related information (including the Multicast Capability AVP) will be silently ignored by the LNS 🙈.
The LNS implements L2TP multicast extensions and therefore supports the Multicast Capability AVP: the LNS is allowed to send L2TP specific commands for conveying multicast traffic toward the LAC 🚀.

The multicast capability only refers to the tunnel the AVP was received on during the control connection establishment phase 🔒. It SHOULD be possible for an LNS administrator to shut down L2TP multicast extension features toward one or a set of LAC(s). In that case, the LNS behaves similarly to option 1) above 🧯.

The AVP has the following format:

      Vendor ID = 0
      Attribute = 80 (16 bits)

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|H|0|0|0|0|      Length       |          Vendor ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              80               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Heads up on the bits: the M-bit MUST be set to 0, and the AVP MAY be hidden (H-bit set to 0 or 1) 🙈.

This AVP is 6 octets long 📏.

4. L2TP Multicast Session Establishment Decision ✨

4.1. Multicast States in LNS 🧚

Okay so the router that embeds the LNS feature MUST support at least one Group Management Protocol (GMP) 💅, like:

IGMPv1
IGMPv2
MLD

or a Source Filtering Group Management Protocol (SFGMP) 🎀, like:

IGMPv3
MLDv2

The LAC is giving layer-2 equipment energy 🦋. It does zero GMP or SFGMP activity, because GMP or SFGMP processing is handled by the LNS. In this context the LAC is not supposed to track GMP or SFGMP messages between the receivers and the LNS. The LNS MUST always be at the origin of creating a multicast L2TP session dedicated to forwarding IP multicast datagrams destined to a multicast group 👑. The LNS also acts as a GMP or SFGMP Querier for every logical interface associated with an L2TP session.

As a multicast router, the equipment with the LNS function keeps state per group per attached network, which means per L2TP session 💜. An LNS-capable box that turns on multicast extensions for L2TP has to classify and analyze GMP and SFGMP states so it can create L2TP multicast sessions inside the right L2TP tunnels. Honestly this part is so iconic, and it happens in three steps ✨:

The LNS computes group states for each L2TP tunnel, using the group states recorded for each L2TP session in that tunnel. Group state determination for L2TP tunnels is discussed in Section 4.2. For each L2TP tunnel, this computation gives a list of states in the form (group, filter-mode, source-list):
- group: Denotes the multicast group.
- filter-mode: Either INCLUDE or EXCLUDE, as defined in [RFC3376].
- source-list: List of IP unicast addresses that multicast reception is desired from or not desired from, depending on the filter-mode.
Based on each group state, the LNS creates one or multiple replication contexts. This depends on the filter-mode for that group and the local policy configured in the LNS 🔥.

For groups in INCLUDE mode, the LNS SHOULD implement two different policies:

One session per (source, group) pair: the LNS creates one replication context per (source, group) pair.

One session per group: the LNS creates one replication context per (source-list, group) pair.

For groups in EXCLUDE mode, the LNS creates one replication context per (list of sources excluded by all the receivers, group). The list of sources is the intersection of the sets, not the union 🙈.

For each replication context, the LNS creates one L2TP multicast session (if threshold conditions are met; see Section 4.3) along with its associated Outgoing Session List (OSL) 🌸. The OSL lists the L2TP sessions that requested the multicast flow for that group and its associated source-filtering properties. There is one OSL per replication context, meaning one OSL per L2TP multicast session.

So a group member running an SFGMP can end up receiving multicast traffic from sources it explicitly excluded in its SFGMP membership report 😭. That happens if other group members in the same L2TP tunnel want packets from those sources. This is comparable to group members connected to the same multi-access network. When a group is in EXCLUDE mode, or in INCLUDE mode with a policy allowing one session per (group, source-list), sharing the same L2TP tunnel is equivalent to being on the same multi-access network for the multicast traffic received. For groups in INCLUDE mode with a policy allowing one L2TP multicast session per (source, group), it's slightly improved, because group members stop receiving traffic from non-requested sources 🧁. The catch is that this policy can increase the number of L2TP multicast sessions to establish and maintain. Examples are in Appendix A.

For the LAC to forward multicast traffic received through the L2TP multicast session to group members, the LNS sends the OSL to the LAC for the related multicast session (see Section 6) 🫶.

4.2. Group State Determination 🌈

Source Filtering Group Management Protocols require querier routers to keep a filter-mode per group per attached network. The goal is to condense the total desired reception state of a group into a minimum set, so every system's membership is satisfied ✨.

In the L2TP world, each L2TP session has to be treated as an attached network by GMP and SFGMP protocols. When the L2TP multicast extension is activated, each L2TP Control Connection also has to be treated as a pseudo attached network. This lets the router condense group membership reports for every L2TP session in the tunnel 💖.

So a list of group states is maintained for each L2TP Control Connection, and the membership information of each of its L2TP sessions gets merged into it. This list is a set of membership records of the form (group, filter-mode, source-list) 🎀.

Each group state is the result of a merging process applied to subscriptions on the L2TP sessions of a Control Connection, for a given group. The merging process has three steps 💅:

Convert any GMP subscription into an SFGMP subscription (IGMPv1/v2 to IGMPv3, MLDv1 to MLDv2).
Remove subscription timers and, if the filter-mode is EXCLUDE, remove sources with a source timer greater than 0.
Merge the resulting subscriptions using the merging rules described in the SFGMP specifications ([RFC3376], Section 3.2, [RFC3810], Section 4.2).

This process is also described in [PROXY]. Examples of group state determination are in Appendix A 🦋.

4.3. Triggering 🔥

The rules the LNS uses to decide when to open a dedicated L2TP multicast session for a multicast group SHOULD be configurable by the LNS administrator 👑. This typically happens when a threshold of MULTICAST_SESSION_THRESHOLD receivers/sessions referenced in a replication context is reached. That threshold SHOULD be set to 2 by default. It's worth opening a dedicated L2TP multicast session for two group members that share the same desired reception state, which means two L2TP unicast sessions are involved. In this case, the OSL references two distinct L2TP sessions 🌸.

The LNS actually receiving the multicast traffic requested by end-users can also be taken into account when deciding whether the associated L2TP multicast session gets opened 🙌.

Whenever an OSL gets empty, the LNS MUST stop sending multicast traffic over the corresponding L2TP multicast session. After that, the L2TP multicast session MUST be torn down as described in Section 7 💀.

Filter-mode changes for a group can also trigger opening or terminating L2TP multicast sessions, in the following ways:

a) From INCLUDE Mode to EXCLUDE Mode

When a group state's filter-mode switches from INCLUDE to EXCLUDE, only one replication context (and its associated L2TP multicast session) that came from this group state can exist (see Section 4.1). The LNS SHOULD keep one replication context previously created for this group state, and it updates that context with:

a new source-list that has to be excluded from forwarding
a new OSL

The LNS MUST send an OSL update to the LAC to reflect L2TP session list changes (see Section 6.2), whenever appropriate. The unused L2TP multicast sessions that correspond to previously created replication contexts for the group SHOULD be terminated, either actively or passively by emptying their corresponding OSLs 🧚.

The remaining L2TP multicast session MAY also be terminated if the number of receivers drops below a predefined threshold (see Section 7). To limit the duration of temporary packet loss or duplicates to receivers, the LNS has to minimize the delay between OSL update messages sent to the LAC. So one can assume that terminating a multicast session passively gives the smoothest transition ✨.

b) From EXCLUDE Mode to INCLUDE Mode

When a group state's filter-mode switches from EXCLUDE to INCLUDE, multiple replication contexts issued by this group state may be created (see Section 4.1). The LNS SHOULD keep the replication context previously created for this group state, and it updates it accordingly with:

a new list of sources that has to be forwarded. This list has only one record if there is one replication context per (group, source)
a new OSL

The LNS MUST send an OSL update to the LAC to reflect L2TP session list changes, whenever appropriate. If the LNS is configured to create one replication context per (group, source), L2TP multicast sessions get opened in addition to the existing one, depending on the number of sources for the group 🍓.

If new L2TP multicast sessions have to be opened, the LNS SHOULD wait until those multicast sessions are established before updating the OSL of the original multicast session. To limit the duration of temporary packet loss or duplicates to receivers, the LNS has to minimize the delay between OSL update messages sent to the LAC 🫶.

4.4. Multicast Traffic Sent from Group Members 💅

This document proposes a solution that enhances forwarding of downstream multicast traffic, and only downstream. That means data going from the LNS toward end-users connected to the LAC 🦋. But if a group member using an L2TP session is also a multicast source for traffic carried in a multicast session, datagrams may get sent back to the source 🙈. To prevent this, the LNS can use either of two options:

Disable the multicast packets' forwarding capability for multicast datagrams sent by users connected to the network through an L2TP tunnel. Protocols using well-known multicast addresses MUST NOT be impacted.
Exclude from the OSL the L2TP session used by a group member that sends packets matching the replication context of that OSL. The corresponding multicast flow is then sent by the LNS over the user's L2TP unicast session, using standard multicast forwarding rules 💜.

5. L2TP Multicast Session Opening Process 🚀

The LNS initiates opening an L2TP multicast session 🌈. A three-message exchange sets up the session. Here's a typical sequence of events 🎀:

      LAC              LNS
      ---              ---
                       (multicast session
                       triggering)

                       <- MSRQ
      MSRP ->

      (Ready to
       replicate)

      MSE  ->
                       <- ZLB ACK

The ZLB ACK is sent if there are no further messages waiting in the queue for that peer 🫶.

5.1. Multicast-Session-Request (MSRQ) 💖

Okay bestie, MSRQ is the LNS sending a control message to the LAC that basically says "hey, we can make a multicast session now!" ✨ The LNS sends it following the rules in Section 4.3. It's the first of a three-message exchange for setting up a multicast session inside an L2TP tunnel 🦋

A LNS MUST NOT send an MSRQ control message if the remote LAC did not open the L2TP tunnel with the Multicast Capability AVP. 💅 The LAC MUST ignore MSRQ control messages sent in an L2TP tunnel if that tunnel wasn't opened with control messages including a Multicast Capability AVP. Rules are rules, periodt 🙅‍♀️

The following AVPs MUST be present in MSRQ:

Message Type
Assigned Session ID

The following AVPs MAY be present in MSRQ:

Random Vector
Maximum BPS

The Maximum BPS value is set by the LNS administrator. However, this value should be chosen in accordance with the line capabilities of the end-users. The Maximum BPS value SHOULD NOT be higher than the highest speed connection for all end-users within the L2TP tunnel 🍓

The associated Message Type AVP is encoded with the following values:

Vendor ID = 0
Attribute Type = 0
Attribute Value = 23 (16 bits)

The M-bit MUST be set to 0, and the H-bit MUST be set to 0. ✨

5.2. Multicast-Session-Response (MSRP) 🌸

Multicast-Session-Response (MSRP) is the LAC's reply to a received MSRQ, so it's the second message in the three-message exchange. Think of it as the LAC saying "yes, I got you, bestie" 🫶

MSRP tells the LNS that the MSRQ worked out, and that the LAC is going to try to reserve the right resources to do multicast replication for the unicast sessions managed in that control connection. Very organized, very iconic 👑

The following AVPs MUST be present in MSRP:

Message Type
Assigned Session ID

The following AVP MAY be present in MSRP:

Random Vector

The associated Message Type AVP is encoded with the following values:

Vendor ID = 0
Attribute Type = 0
Attribute Value = 24 (16 bits)

The M-bit MUST be set to 0, and the H-bit MUST be set to 0. 🎀

5.3. Multicast-Session-Establishment (MSE) 🧚

Multicast-Session-Establishment (MSE) is sent by the LAC to the LNS to say the LAC is ready to receive the multicast information (Section 6) for the group using the newly created multicast session. It's the third and final message in the three-message sequence 🔥

The following AVP MUST be present in MSE:

Message Type

The following AVP MAY be present in MSE:

Sequencing Required

Sequencing only goes from the LNS to the LAC, since a multicast session is only used to forward multicast traffic downstream. Makes sense, right? 💜

The associated Message Type AVP is encoded with the following values:

Vendor ID = 0
Attribute Type = 0
Attribute Value = 25 (16 bits)

The M-bit MUST be set to 0, and the H-bit MUST be set to 0. 💖

6. Session Maintenance and Management 🦋

Once the multicast session is up, the LAC needs to know which L2TP unicast sessions want the traffic from that new multicast session. It also needs a related optional priority parameter, which is defined in Section 6.3. So a new control message type is born: Multicast-Session-Information (MSI) ✨

6.1. Multicast-Session-Information (MSI) 🌈

Multicast-Session-Information (MSI) control messages carry AVPs that keep the OSL synchronized between the LNS and the LAC. They also set the optional priority parameter for multicast traffic versus unicast traffic. MSI may be extended to update the multicast session with additional parameters, as needed 💅

Each MSI message is specific to one particular multicast session. So the control message MUST use the assigned session ID associated with that multicast session (the one assigned by the LAC), except for the case mentioned in 6.3.2 🫶

The associated Message Type AVP is encoded with the following values:

Vendor ID = 0
Attribute Type = 0
Attribute Value = 26 (16 bits)

The M-bit MUST be set to 0, and the H-bit MUST be set to 0.

The following AVP MUST be present in MSI:

Message Type

The following AVPs MAY be present in MSI:

Random Vector
New Outgoing Sessions
New Outgoing Sessions Acknowledgement
Withdraw Outgoing Sessions
Multicast Packets Priority

New Outgoing Sessions, New Outgoing Sessions Acknowledgement, Withdraw Outgoing Sessions, and Multicast Packets Priority are new AVPs defined in sections 6.2 and 6.3. 🍓

6.2. Outgoing Sessions List Updates 🌸

Whenever the Outgoing Sessions List changes, the LNS MUST inform the LAC of that change. ⭐ The OSL is built from subscription reports recorded by GMP or SFGMP processes running in the LNS (Section 4.1).

The LAC keeps an OSL as a local table that the LNS transmits. Just like the LNS, the LAC has to keep an OSL for each L2TP multicast session within an L2TP tunnel. To update the LAC's OSL, the LNS sends a New Outgoing Sessions AVP for additional sessions, or a Withdraw Outgoing Sessions AVP to remove sessions. All sessions mentioned in these AVPs MUST be added or removed by the LAC from the relevant OSL. The Outgoing Sessions List is identified by the tunnel ID and the multicast session ID that the updating AVP refers to. 🦋 The AVPs used to update the OSL are:

Additional session(s): New Outgoing Sessions AVP
Session(s) removal: Withdraw Outgoing Sessions AVP

These new AVPs MUST be sent in an MSI message. 💜

6.2.1. New Outgoing Sessions AVP (MSI) 🎀

The New Outgoing Sessions AVP can only be carried within an MSI message type. It piggybacks every Session ID that the multicast traffic has to be forwarded to 🧚

The AVP has the following format:

Vendor ID = 0
Attribute = 81 (16 bits)

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|H|0|0|0|0|      Length       |          Vendor ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              81               |         Session ID 0          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              ...              |         Session ID N          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

There can be from 1 to N Session IDs present in the New Outgoing Sessions AVP (considering the maximum value of the Length field). This AVP must be placed in an MSI message and sent after the multicast session is established, to indicate the initial outgoing sessions to the LAC. It must also be sent any time one or more outgoing sessions appear during the multicast session's lifetime. When the LAC receives this AVP, it sends a New Outgoing Sessions Acknowledgment AVP back to the LNS to say it's ready to replicate the multicast traffic toward the indicated sessions 🌟

Usage of this AVP is incremental, so only the new outgoing sessions have to be listed in it 💅

The M-bit MUST be set to 1, and the AVP MAY be hidden (H-bit set to 0 or 1). 🌈

6.2.2. New Outgoing Sessions Acknowledgement AVP (MSI) 🫧

The New Outgoing Sessions Acknowledgement AVP can only be carried within an MSI message type. It tells the LNS that the LAC is ready to replicate traffic for every Session ID listed in the AVP 🥰

The AVP has the following format:

Vendor ID = 0
Attribute = 82 (16 bits)

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|H|0|0|0|0|      Length       |          Vendor ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              82               |         Session ID 0          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              ...              |         Session ID N          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This AVP must be placed in an MSI message and sent by the LAC toward the LNS, to acknowledge receipt of a New Outgoing Sessions list that came in a New Outgoing Sessions AVP from the LNS.

An LNS is allowed to send multicast traffic within the L2TP multicast session as soon as a New Outgoing Sessions Acknowledgement AVP is received for the corresponding L2TP multicast session. ✨

An LNS is allowed to stop sending packets of the corresponding multicast flow within L2TP unicast sessions only if it receives an MSI message with the New Outgoing Session Acknowledgement AVP, and only for the unicast Session IDs mentioned in that AVP. The multicast traffic can then be conveyed in L2TP unicast sessions when the L2TP multicast session goes down. From this standpoint, packets related to this multicast flow SHOULD NOT be conveyed within the L2TP unicast sessions mentioned in the AVP, in order to avoid duplicating multicast packets. 🙈 Duplicates are not it, bestie 💀

There can be from 1 to N Session IDs present in the New Outgoing Sessions Acknowledgement AVP (considering the maximum value of the Length field). Session IDs mentioned in this AVP that have not been listed in a previous New Outgoing Sessions AVP should be ignored. Non-acknowledged Session IDs MAY be listed in forthcoming New Outgoing Sessions AVPs, but multicast traffic MUST be sent to the logical interfaces associated with these Session IDs for as long as they are not acknowledged for replication by the LAC 🦋

The M-bit MUST be set to 1, and the AVP MAY be hidden (H-bit set to 0 or 1). 💜

6.2.3. Withdraw Outgoing Sessions AVP (MSI) 🥀

The Withdraw Outgoing Sessions AVP is sent whenever there is one or more withdrawn subscriptions for the corresponding multicast flow (the one designated by the session ID the MSI is sent on) 🍂

The LAC can stop forwarding packets to the Session IDs mentioned in the AVP for the corresponding multicast flow as soon as it receives the MSI message embedding this Withdraw Target Session AVP. 🌷

The AVP has the following format:

Vendor ID = 0
Attribute = 83 (16 bits)

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|H|0|0|0|0|      Length       |          Vendor ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              83               |         Session ID 0          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              ...              |         Session ID N          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

There can be from 1 to N Session IDs present in the Withdraw Outgoing Sessions AVP (considering the value of the Length field). The M-bit MUST be set to 1, and the AVP MAY be hidden (H-bit set to 0 or 1). ✨

6.3. Multicast Packets Priority AVP (MSI) 🎀

Okay so the Multicast Packets Priority AVP is an optional AVP, and its whole job is telling the LAC how to handle multicast traffic when it's competing with unicast traffic 💅. The LAC behavior is only partly described here, and the tea is that the kind of traffic (layer-2 frames for unicast, pure IP packets for multicast) is not a thing used to enforce a prioritization policy 🙈. Getting a uniformly framed stream to the final user is covered in Section 8 ✨.

There are three behaviors you can pick from:

Best effort: the traffic is forwarded from the LAC to the end-user in the order it arrives from the LNS, no matter what type of traffic it is 🌸.
Unicast traffic priority: traffic coming down the L2TP unicast session gets priority over traffic coming down the L2TP multicast session 💜.
Multicast traffic priority: traffic coming down the L2TP multicast session gets priority over traffic coming down the L2TP unicast session 🔥.

The priority is a 16-bit quantity, and it can be one of these values:

   0: Best effort (default)
   1: Unicast traffic priority
   2: Multicast traffic priority

The AVP is laid out like this:

   Vendor ID = 0
   Attribute = 84 (16 bits)

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|H|0|0|0|0|      Length       |          Vendor ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              84               |        Priority Value         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Heads up, bestie: even with a priority value of 0, the multicast traffic rate can reach up to Maximum BPS (as indicated in MSRQ), and that can be more than what a specific end-user is allowed. So an end-user might get only multicast traffic, and their unicast packets could get dropped because the multicast flow overwhelms the LAC forwarding buffer(s) 😭.

The default Priority Value is 0. The M-bit MUST be set to 0, and the AVP MAY be hidden (H-bit set to 0 or 1) 🦋.

There are two ways to use this AVP: global configuration and individual configuration 🧚.

6.3.1. Global Configuration

The Multicast Priority Packet AVP gets sent for all L2TP unicast sessions tied to a specific multicast flow, which is represented by an L2TP multicast session 🌈. In this case the AVP goes in an L2TP MSI control message for the matching multicast session ID (Session ID = L2TP session for the corresponding multicast group). The priority value applies to every L2TP unicast session that the multicast group designated by the L2TP multicast session is meant for, as soon as this AVP is received ⭐.

6.3.2. Individual Configuration

The Multicast Priority Packet AVP gets sent for one specific L2TP unicast session that SHALL adopt a specific behavior for both unicast and multicast traffics 👑. In this case the AVP goes in an L2TP MSI control message for that L2TP unicast session (Session ID = L2TP session for the concerned user). The priority value only applies to the targeted session and doesn't touch the others. Also, in this case, every multicast packet carried in L2TP multicast sessions is treated the same way by the LAC for the concerned user 🍓.

This is the only case in which an MSI control message can be sent for an L2TP unicast session 💖.

6.3.3. Priority

It's the network administrator's call to decide whether to use global or individual configuration when the AVP gets sent twice (once for a multicast group and once for a specific end-user) 👩‍💻. By default, in that situation, only the individual configurations SHOULD be taken into consideration 💅.

Support for the Multicast Packets Priority AVP is optional, and it SHOULD be configurable by the LAC administrator, if it's relevant to the deployment 🫶.

7. Multicast Session Teardown ✨

An L2TP multicast session should be torn down whenever there are no longer any users interested in receiving the corresponding multicast traffic 🌸. A multicast session becomes useless once the related OSL has fewer than a predefined number of entries, and that number is set by a threshold 😭.

Multicast session flapping can happen when the number of OSL entries bounces around the threshold, if the same value is used to trigger both the creation and the deletion of an L2TP multicast session 🙈. To avoid this, two methods can be used:

The threshold value used to decide whether the L2TP multicast session has to be torn down is lower than the MULTICAST_SESSION_THRESHOLD value.
The MULTICAST_SESSION_THRESHOLD value is used to decide whether the L2TP multicast session has to be torn down. A multicast session SHOULD be killed after a period of MULTICAST_SESSION_HOLDTIME seconds if the corresponding OSL maintains fewer than a MULTICAST_SESSION_THRESHOLD number of entries. The MULTICAST_SESSION_HOLDTIME value is 10 seconds by default and SHOULD be configurable by either the LAC or the LNS administrator 🧚.

A multicast session can be torn down for lots of reasons, including specific criteria that aren't described here (which can be vendor specific) 🌈.

A multicast session teardown can be started by either the LAC or the LNS. However, multicast session teardown MUST be initiated by the LNS if the decision to terminate is based on the number of users interested in the traffic for a multicast flow 👑.

7.1. Operations

The actual termination of a multicast session starts with a new Multicast-Session-End-Notify (MSEN) control message, which can be sent by either the LAC or the LNS 🦋.

Here's an example of a control message exchange that terminates a multicast session:

   LAC or LNS      LAC or LNS
   ----------      ----------
                   (multicast session
                   termination)

                   <- MSEN
                   (Clean up)
   ZLB ACK ->
   (Clean up)

7.2. Multicast-Session-End-Notify (MSEN)

The Multicast-Session-End-Notify (MSEN) is an L2TP control message sent by either the LAC or the LNS to request the termination of a specific multicast session within the tunnel 💜. Its purpose is to give the peer the relevant termination information, including the reason the termination happened. The peer MUST clean up any associated resources, and it does not acknowledge the MSEN message 🫶.

As defined in [RFC2661], terminating a control connection will terminate all sessions managed within it, including multicast sessions if there are any 💅.

The MSEN message carries a Result Code AVP with an optional Error Code 🎀.

The following AVPs MUST be present in an MSEN message:

   Message Type
   Result Code
   Assigned Session ID

The associated Message Type AVP is encoded with these values:

   Vendor ID = 0
   Attribute Type = 0
   Attribute Value = 27 (16 bits)

The M-bit MUST be set to 0, and the H-bit MUST be set to 0 🍓.

7.3. Result Codes

These are the defined result codes for MSEN control messages, and they're giving organized 🌸:

   1 (16 bits) - No multicast traffic for the group
   2 (16 bits) - Session terminated for the reason indicated in
                 the error code
   3 (16 bits) - No more receivers
   4 (16 bits) - No more receivers (filter-mode change)

The code 1 MAY be used when the LAC detects that no traffic is coming down the multicast session, or when the LNS doesn't receive multicast traffic to be conveyed over the L2TP multicast session during a certain period of time 🧚.
The code 2 refers to General Error Codes maintained by the IANA for L2TP 🌈.
The code 3 MAY be used by the LAC or the LNS when the OSL is empty 💖.
The code 4 MAY be used by the LNS when a multicast session is torn down because of a filter-mode change. This result code SHOULD also be used when the OSL becomes empty after a filter-mode change (passive termination when filter-mode changes from INCLUDE to EXCLUDE; see Section 4.3) 👑.

8. Traffic Merging 🌈

Both unicast and multicast traffic have to be merged by the LAC so it can forward properly framed data to the end-user 💅. The LAC frames multicast packets and transmits them toward the right end-user. How this is done isn't described here, since it's an implementation-specific issue 🧚.

Every frame sent from the LAC to the end-users has to follow the framing scheme used for the peer the traffic is headed to (for example, the LAC always knows the PPP [RFC1661] link parameters, as described in [RFC2661], Section 6.14) 🎀. Be aware that using L2TP Multicast Extension features isn't appropriate for end-users who have negotiated a sequenced layer-2 connection with the LNS 😭. When the LAC inserts PPP-encapsulated multicast packets into a session, it cannot modify the PPP sequencing that the LNS performs for each PPP session 🫶.

9. IANA Considerations 🦋

This document defines a bunch of new stuff, and here's the full list for IANA 💖:

   - 5 new Message Type (Attribute Type 0) Values:
        o Multicast-Session-Request (MSRQ)      : 23
        o Multicast-Session-Response (MSRP)     : 24
        o Multicast-Session-Establishment (MSE) : 25
        o Multicast-Session-Information (MSI)   : 26
        o Multicast-Session-End-Notify (MSEN)   : 27

   - 5 new Control Message Attribute Value Pairs:
        o Multicast Capability                  : 80
        o New Outgoing Sessions                 : 81
        o New Outgoing Sessions Acknowledgement : 82
        o Withdraw Outgoing Sessions            : 83
        o Multicast Packets Priority            : 84

   - 4 Result Codes for the MSEN message:
        o No multicast traffic for the group    : 1
        o Session terminated for the reason indicated in the
          error code                            : 2
        o No more receivers                     : 3
        o No more receivers (filter-mode change): 4

10. Security Considerations 🔐✨

okay this section is SO important bestie, so read it carefully 🥺 🫶

It's possible for one receiver to make extra multicast traffic that nobody asked for show up on another receiver's link 😬 This can happen if a single replication context per group is used in INCLUDE mode and the receivers have different source lists, and in EXCLUDE mode if one receiver has a source list that no other receiver shares. It can happen every time receivers are connected to a common multi-access network, so it's giving real-world problem 💀

The extension in this document doesn't add any new security issues when it comes to turning on the L2TP protocol 💅

Now the scary part 🙈 Someone could only inject control packets into the tunnel toward the LAC to change the Outgoing Session List and flood end-users with unwanted multicast traffic if the control connection has been hacked 😱 For any illegitimate L2TP control message that shows up, these things apply:

If the spoofed control message has consistent sequence numbers, the next messages will look out of synch, and that can make the control connection terminate 💔
If the sequence numbers don't match the current control connection states, the spoofed control message gets queued or discarded, as described in [RFC2661], Section 5.8 🗑️

Turning on the L2TP multicast capability on the LAC could make the equipment more sensitive to Denial of Service attacks if the control connection or the related LNS gets hacked 🚨 The LAC might also feel the extra load from the additional replication work 🥵

As mentioned in [RFC2661], Section 9.2, securing L2TP means the underlying transport has to provide encryption, integrity, and authentication services for all L2TP traffic, including L2TP multicast traffic (control and data) 🔒💖

11. References 📚

11.1. Normative References

[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
          RFC 1112, August 1989.

[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
          RFC 1661, July 1994.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
          2", RFC 2236, November 1997.

[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.,
          and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC
          2661, August 1999.

[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.

[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet
          Assigned Numbers Authority (IANA) Considerations Update",
          BCP 68, RFC 3438, December 2002.

[RFC3590] Haberman, B., "Source Address Selection for the Multicast
          Listener Discovery (MLD) Protocol", RFC 3590, September
          2003.

[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
          Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

11.2. Informative References

[PROXY]   Fenner, B., He, H., Haberman, B., Sandick, H., "IGMP/MLD-
          based Multicast Forwarding ("IGMP/MLD Proxying")", Work in
          Progress.

12. Acknowledgements 🫶🌸

big thank-yous 💕 Christian Jacquenet gets a shout-out for all the corrections and his precious advice on this document. Pierre Levis gets one for his contribution about IGMP, Francis Houllier for the PPP considerations, and Xavier Vinet for his input about thresholds. And many thanks to W. Mark Townsley, Isidor Kouvelas, and Brian Haberman for their super valuable input on the protocol definition 👑

Appendix A. Examples of Group States Determination 🧚💜

okay the examples are where it all clicks, so let's go 🤩

Example 1:

All users are managed in the same control connection.

Users {1, 2, 3} subscribe to (Group G1, EXCLUDE {})
Users {3, 4, 5} subscribe to (Group G2, EXCLUDE {})

Group states for this L2TP tunnel will be:

(G1, EXCLUDE, {})
(G2, EXCLUDE, {})

So two replication contexts get created:

-RC1:
(*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC2:
(*, G2) packets, Multicast Session MS2, OSL = 3, 4, 5

Example 2:

All users are managed in the same control connection.

Users {1, 2, 3} subscribe to (Group G1, INCLUDE {S1})
Users {4, 5, 6} subscribe to (Group G1, INCLUDE {S1,S2})
Users {7, 8, 9} subscribe to (Group G1, INCLUDE {S2})

The group state for this L2TP tunnel will be:

(G1, INCLUDE, {S1, S2)})

If the LNS policy allows one replication context per (group, source), two replication contexts get created:

-RC1:
(S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4, 5, 6
-RC2:
(S2, G1) packets, Multicast Session MS2, OSL = 4, 5, 6, 7, 8, 9

If the LNS policy allows one replication context per (group, source-list), just one replication context gets created:

-RC1:
({S1, S2}, G1) packets, Multicast Session MS1, OSL = [1..9]

Example 3:

All users are managed in the same control connection.

Users {1, 2} subscribe to (Group G1, EXCLUDE {S1})
User {3} subscribes to (Group G1, EXCLUDE {S1, S2})

The group state for this L2TP tunnel will be:

(G1, EXCLUDE, {S1})

So one replication context gets created:

-RC1:
(*-{S1}, G1) packets, Multicast Session MS1, OSL = 1, 2, 3

Next, user {4} subscribes to (Group G1, INCLUDE {S1}). The group state for the L2TP tunnel changes to:

(G1, EXCLUDE, {})

And the replication context RC1 changes to:

-RC1: (*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4

Example 4:

All users are managed in the same control connection. The LNS policy allows one replication context per (group, source).

Users {1, 2, 3} subscribe to (Group G1, INCLUDE {S1, S2})

The group state for this L2TP tunnel will be:

(G1, INCLUDE, {S1, S2)})

So two replication contexts get created:

-RC1:
(S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC2:
(S2, G1) packets, Multicast Session MS2, OSL = 1, 2, 3

Next, user {4} subscribes to (Group G1, EXCLUDE {}), which is equivalent to an IGMPv2 membership report. The group state for the L2TP tunnel changes to:

(G1, EXCLUDE, {})

The replication context RC1 changes to:

-RC1: (*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4

The replication context RC2 changes to:

-RC2: no packets to forward, Multicast Session MS2, OSL = {}
(Multicast Session MS2 will be deleted)

When user {4} leaves G1, the group state for the L2TP tunnel goes back to:

(G1, INCLUDE, {S1, S2})

And the replication contexts become:

-RC1:
(S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3
-RC2:
(S2, G1) packets, Multicast Session MS2, OSL = 1, 2, 3
(Multicast Session MS2 is re-established)

Author's Address 📮

Gilles Bourdon
France Telecom
38-40, rue du General Leclerc
92794 Issy les Moulineaux Cedex 9 - FRANCE

Phone: +33 1 4529-4645
EMail: gilles.bourdon@francetelecom.com

This document falls under the rights, licenses and restrictions in BCP 78. Apart from what's set out there, the authors keep all their rights 💅

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔍

The IETF doesn't take a side on whether any Intellectual Property Rights, or other rights that someone might claim over the technology in this document, are valid or how far they reach. It also doesn't say whether any license under those rights might be available. It hasn't made any independent effort to find those rights either 🤷‍♀️ For how rights work with RFC documents, check BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, and any assurances of licenses that will be available, can be found in the IETF online IPR repository at http://www.ietf.org/ipr. The same goes for the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights.

The IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to let them know. Send that information to the IETF at ietf-ipr@ietf.org 📬

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society 🎀

📦 where this page comes from

ietf: rfc4045 2005-04
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms

RFC 4045

RFC 4045 🎀 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)

Status of This Memo ✨

Copyright Notice 📜

Abstract 🌸

Table of Contents 📚

1. Introduction 🦋

1.1. Conventions Used in This Document 📚

1.2. Terminology 📖

2. Motivation for a Session-Based Solution 🌷

3. Control Connection Establishment 🎀

3.1. Negotiation Phase 🤝

3.2. Multicast Capability AVP (SCCRQ, SCCRP) 💜

4. L2TP Multicast Session Establishment Decision ✨

4.1. Multicast States in LNS 🧚

4.2. Group State Determination 🌈

4.3. Triggering 🔥

4.4. Multicast Traffic Sent from Group Members 💅

5. L2TP Multicast Session Opening Process 🚀

5.1. Multicast-Session-Request (MSRQ) 💖

5.2. Multicast-Session-Response (MSRP) 🌸

5.3. Multicast-Session-Establishment (MSE) 🧚

6. Session Maintenance and Management 🦋

6.1. Multicast-Session-Information (MSI) 🌈

6.2. Outgoing Sessions List Updates 🌸

6.2.1. New Outgoing Sessions AVP (MSI) 🎀

6.2.2. New Outgoing Sessions Acknowledgement AVP (MSI) 🫧

6.2.3. Withdraw Outgoing Sessions AVP (MSI) 🥀

6.3. Multicast Packets Priority AVP (MSI) 🎀

6.3.1. Global Configuration

6.3.2. Individual Configuration

6.3.3. Priority

7. Multicast Session Teardown ✨

7.1. Operations

7.2. Multicast-Session-End-Notify (MSEN)

7.3. Result Codes

8. Traffic Merging 🌈

9. IANA Considerations 🦋

10. Security Considerations 🔐✨

11. References 📚

11.1. Normative References

11.2. Informative References

12. Acknowledgements 🫶🌸

Appendix A. Examples of Group States Determination 🧚💜

Author's Address 📮

Full Copyright Statement ©️

Intellectual Property 🔍

Acknowledgement 💖