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 a control message sent by the
LAC to the LNS in response to a received MSRQ message. It is the
second in a three-message exchange used for establishing a multicast
session within an L2TP tunnel.
MSRP is used to indicate that the MSRQ was successful and that the
LAC will attempt to reserve appropriate resources to perform
multicast replication for unicast sessions managed in the pertaining
control connection.
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 a control message sent by
the LAC to the LNS to indicate that the LAC is ready to receive
necessary multicast information (Section 6) for the group using the
newly created multicast session. It is the third message in the
three-message sequence used for establishing a multicast session
within an L2TP tunnel.
The following AVP MUST be present in MSE:
Message Type
The following AVP MAY be present in MSE:
Sequencing Required
Sequencing will occur only from the LNS to the LAC, as a multicast
session is only used to forward multicast traffic downstream.
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 established, the LAC has to be informed
of the L2TP unicast sessions interested in receiving the traffic from
the newly created multicast session, and a related optional priority
parameter, defined in Section 6.3. To achieve this, a new control
message type is defined: Multicast-Session-Information (MSI).
6.1. Multicast-Session-Information (MSI)
Multicast-Session-Information (MSI) control messages carry AVPs to
keep the OSL synchronized between the LNS and the LAC, and to 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 a particular multicast session.
Therefore, the control message MUST use the assigned session ID
associated with the multicast session (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 a change occurs in the Outgoing Sessions List, the LNS MUST
inform the LAC of that change. The OSL is built upon subscription
reports recorded by GMP or SFGMP processes running in the LNS
(Section 4.1).
The LAC maintains an OSL as a local table transmitted by the LNS. As
for the LNS, the LAC has to maintain an OSL for each L2TP multicast
session within an L2TP tunnel. To update the LAC OSL, the LNS sends
a New Outgoing Sessions AVP for additional sessions, or sends 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 to which the updating AVP refers. To
update the OSL, the following AVPs are used:
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. This AVP piggybacks every Session ID to which the
multicast traffic has to be forwarded.
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
establishment of the multicast session to indicate the initial
outgoing sessions to the LAC, and must be sent at any time when one
or more outgoing sessions appear during the multicast session
lifetime. Upon receipt of this AVP, the LAC sends a New Outgoing
Sessions Acknowledgment AVP to the LNS to notify that the LAC is
ready to replicate the multicast traffic toward the indicated
sessions.
Usage of this AVP is incremental; only new outgoing sessions have to
be listed in the AVP.
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. This AVP informs 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 the receipt of a New Outgoing Sessions list
received 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 this 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 the
duplication of multicast packets.
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 logical
interfaces associated to these Session IDs as long as these Session
IDs 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
(designated by the session ID on which the MSI is sent).
The LAC can stop forwarding packets to 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)
The Multicast Packets Priority AVP is an optional AVP intended to
indicate to the LAC how to process multicast traffic against unicast
traffic. Even though the LAC behavior is partially described here,
the nature of the traffic (layer-2 frames for unicast traffic and
pure IP packets for multicast traffic) is not a criteria for
enforcing a traffic prioritization policy. Traffic processing for
the provisioning of a uniformly framed traffic for the final user is
described is section 8.
Three different behaviors can be adopted:
1) Best effort: the traffic is forwarded from the LAC to the end-user
in the order in which it comes from the LNS, whatever the type of
traffic.
2) Unicast traffic priority: traffic coming down the L2TP unicast
session has priority over traffic coming down the L2TP multicast
session.
3) Multicast traffic priority: traffic coming down the L2TP multicast
session has priority over traffic coming down the L2TP unicast
session.
The priority is encoded as a 16-bit quantity, which can take the
following values:
0: Best effort (default)
1: Unicast traffic priority
2: Multicast traffic priority
The AVP has the following format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the multicast traffic rate can reach up to Maximum BPS (as
indicated in MSRQ). This rate can exceed the maximum rate allowed
for a particular end-user. This means that even with a priority
value of 0, the end-user may receive multicast traffic only; unicast
packets might be 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 of using this AVP: global configuration and
individual configuration.
6.3.1. Global Configuration
The Multicast Priority Packet AVP is sent for all L2TP unicast
sessions concerned with a specific multicast flow represented by an
L2TP multicast session. In this case, the AVP is sent in an L2TP MSI
control message for the corresponding multicast session ID (Session
ID = L2TP session for the corresponding multicast group). The
priority value applies to all L2TP unicast sessions to which the
multicast group designated by the L2TP multicast session is intended,
as soon as this AVP is received.
6.3.2. Individual Configuration
The Multicast Priority Packet AVP is sent for a specific L2TP unicast
session that SHALL adopt a specific behavior for both unicast and
multicast traffics. In this case, the AVP is sent in an L2TP MSI
control message for the L2TP unicast session (Session ID = L2TP
session for the concerned user). The priority value applies to the
targeted session only and does not affect the other sessions. Note
that in this case, all multicast packets carried in L2TP multicast
sessions are 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 is the responsibility of the network administrator to decide which
behavior to adopt between global or individual configurations, if the
AVP is sent twice (one for a multicast group and one for a specific
end-user). By default, only the individual configurations SHOULD be
taken into consideration in that case.
Support of the Multicast Packets Priority AVP is optional and SHOULD
be configurable by the LAC administrator, if it is relevant.
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, this number being
defined by a threshold.
Multicast session flapping may occur when the number of OSL entries
oscillates around the threshold, if the same value is used to trigger
the creation or deletion of an L2TP multicast session. To avoid this
behavior, two methods can be used:
- The threshold value that is used to determine 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 determine 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.
The multicast session can be torn down for multiple reasons,
including specific criteria not described here (which can be vendor
specific).
A multicast session teardown can be initiated by either the LAC or
the LNS. However, multicast session teardown MUST be initiated by
the LNS if the termination decision is motivated by the number of
users interested in receiving the traffic corresponding to a
multicast flow.
7.1. Operations
The actual termination of a multicast session is initiated with a new
Multicast-Session-End-Notify (MSEN) control message, sent either by
the LAC or by the LNS.
The following is 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
why the termination occurred. The peer MUST clean up any associated
resources and does not acknowledge the MSEN message.
As defined in [RFC2661], termination of a control connection will
terminate all sessions managed within, 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 the following 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
The following values are the defined result codes for MSEN control
messages:
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)
o 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.
o The code 2 refers to General Error Codes maintained by the IANA
for L2TP.
o The code 3 MAY be used by the LAC or the LNS when the OSL is
empty.
o 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 traffics have to be merged by the LAC in
order to forward properly framed data to the end-user. Multicast
packets are framed by the LAC and transmitted toward the proper end-
user. Methods used to achieve this function are not described here,
since it is an implementation-specific issue.
All frames conveyed from the LAC to the end-users have to follow the
framing scheme applied for the considered peer to which the traffic
is destined (e.g., the LAC is always aware of the PPP [RFC1661] link
parameters, as described in [RFC2661], Section 6.14). Note that
using L2TP Multicast Extension features is not appropriate for end-
users who have negotiated a sequenced layer-2 connection with the
LNS. While inserting PPP-encapsulated multicast packets in a
session, the LAC cannot modify PPP sequencing performed by the LNS
for each PPP session.
9. IANA Considerations
This document defines:
- 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
It is possible for one receiver to make additional multicast traffic
that has not been requested go down the link of another receiver.
This can happen if a single replication context per group is used in
INCLUDE mode with receivers having divergent source lists, and in
EXCLUDE mode if a receiver has a source list not shared by another.
This behavior can be encountered every time receivers are connected
to a common multi-access network.
The extension described in this document does not introduce any
additional security issues as far as the activation of the L2TP
protocol is concerned.
Injecting appropriate control packets in the tunnel toward the LAC to
modify Outgoing Session List and to flood end-users with unwanted
multicast traffic is only possible if the control connection is
hacked. As for any reception of illegitimate L2TP control messages,
the following apply:
- If the spoofed control message embeds consistent sequence