Network Working Group G. Bourdon
Request for Comments: 4045 France Telecom
Category: Experimental April 2005
Extensions to Support Efficient Carrying of
Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)
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.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Layer Two Tunneling Protocol (L2TP) provides a method for
tunneling PPP packets. This document describes an extension to L2TP,
to make efficient use of L2TP tunnels within the context of deploying
multicast services whose data will have to be conveyed by these
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
The deployment of IP multicast-based services may have to deal with
L2TP tunnel engineering. The forwarding of multicast data within
L2TP sessions may impact the throughput of L2TP tunnels because the
same traffic may be sent multiple times within the same L2TP tunnel,
but in different sessions. This proposal aims to reduce the impact
by applying the replication mechanism of multicast traffic only when
necessary.
The solution described herein provides a mechanism for transmitting
multicast data only once for all the L2TP sessions that have been
established in a tunnel, each multicast flow having a dedicated L2TP
session.
Within the context of deploying IP multicast-based services, it is
assumed that the routers of the IP network that embed a L2TP Network
Server (LNS) capability may be involved in the forwarding of
multicast data, toward users who access the network through an L2TP
tunnel. The LNS is in charge of replicating the multicast data for
each L2TP session that a receiver who has requested a multicast flow
uses. In the solution described here, an LNS is able to send
multicast data only once and to let the L2TP Access Concentrator
(LAC) perform the traffic replication. By doing so, it is expected
to spare transmission resources in the core network that supports
L2TP tunnels. This multicast extension to L2TP is designed so that
it does not affect the behavior of L2TP equipment under normal
conditions.
A solution whereby multicast data is carried only once in a L2TP
tunnel is of interest to service providers, as edge devices are
aggregating more and more users. This is particularly true for
operators who are deploying xDSL (Digital Subscriber Line) services
and cable infrastructures. Therefore, L2TP tunnels that may be
supported by the network will have to carry multiple redundant
multicast data more often. The solution described in this document
applies to downstream traffic exclusively; i.e., data coming from the
LNS toward end-users connected to the LAC. This downstream multicast
traffic is not framed by the LNS but by the LAC, thus ensuring
compatibility for all users in a common tunnel, whatever the framing
scheme.
1.1. Conventions Used in This Document
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
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 is no need to dissociate multicast
from unicast sessions, and thus it designates 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
Multicast data have to be seen as a singular flow that may be
conveyed into all the L2TP sessions that have been established in a
tunnel. This means that a given L2TP session can be dedicated for
the forwarding of a multicast flow that will be forwarded to multiple
receivers, including those that can be reached by one or several of
these L2TP sessions. A session carrying IP multicast data is
independent from the underlying framing scheme and is therefore
compatible with any new framing scheme that may be supported by the
L2TP protocol.
Using a single L2TP session per multicast flow is motivated by the
following arguments:
- The administrator of the LNS is presumably in charge of the IP
multicast-based services and the related engineering aspects. As
such, he must be capable of filtering multicast traffic on a
multicast source basis, on a multicast group basis, and on a user
basis (users who access the network using an L2TP session that
terminates in this LNS).
- Having an L2TP session dedicated for a multicast flow makes it
possible to enforce specific policies for multicast traffic. For
instance, it is possible to change the priority treatment for
multicast packets against unicast packets.
- It is not always acceptable or possible to have multicast
forwarding performed within the network between the LAC and the
LNS. Having the multicast traffic conveyed within an L2TP tunnel
ensures a multicast service between the LNS and end-users,
alleviating the need for activating multicast capabilities in the
underlying network.
3. Control Connection Establishment
3.1. Negotiation Phase
The multicast extension capability is negotiated between the LAC and
the LNS during the control connection establishment phase. However,
establishment procedures defined in [RFC2661] remain unchanged. An
LAC indicates its multicast extension capability by using a new AVP,
the "Multicast Capability" AVP. There is no explicit acknowledgement
sent by the LNS 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)
In order to inform the LNS that an LAC has the ability to handle
multicast sessions, the LAC sends a Multicast Capability AVP during
the control connection establishment phase. This AVP is either sent
in a SCCRQ or a SCCRP control message by the LAC towards the LNS.
Upon receipt of the Multicast Capability AVP, a LNS may adopt two
distinct behaviors:
1) The LNS does not implement the L2TP multicast extension: any
multicast-related information (including the Multicast Capability
AVP) will be silently ignored by the LNS.
2) 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 exclusively refers to the tunnel for which
the AVP has been received during the control connection establishment
phase. It SHOULD be possible for an LNS administrator to shut down
L2TP multicast extension features towards one or a set of LAC(s). In
this case, the LNS behavior is similar to that in 1).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The M-bit MUST be set to 0, the AVP MAY be hidden (H-bit set to 0 or
1).
The length of this AVP is 6 octets.
4. L2TP Multicast Session Establishment Decision
4.1. Multicast States in LNS
The router that embeds the LNS feature MUST support at least one
Group Management Protocol (GMP), such as:
- IGMPv1
- IGMPv2
- MLD
or a Source Filtering Group Management Protocol (SFGMP), such as:
- IGMPv3
- MLDv2
The LAC does not have any group management activity: GMP or SFGMP
processing is performed by the LNS. The LAC is a layer-2 equipment,
and is not supposed to track GMP or SFGMP messages between the
receivers and the LNS in this context. The LNS MUST always be at the
origin of the creation of a multicast L2TP session dedicated for the
forwarding of IP multicast datagrams destined to a multicast group.
The LNS acts as a GMP or SFGMP Querier for every logical interface
associated to an L2TP session.
As a multicast router, the equipment that embeds the LNS function
will keep state per group per attached network (i.e., per L2TP
session). The LNS-capable equipment activating multicast extensions
for L2TP will have to classify and analyze GMP and SFGMP states in
order to create L2TP multicast sessions within the appropriate L2TP
tunnels. This is performed in three steps:
1) The LNS has to compute group states for each L2TP tunnel, by using
group states recorded for each L2TP session of the tunnel. Group
state determination for L2TP tunnels is discussed in Section 4.2.
For each L2TP tunnel, the result of this computation will issue a
list of states of 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 from which multicast
reception is desired or not, depending on the filter-mode.
2) According to each group state, the LNS will create one or multiple
replication contexts, depending on the filter-mode for the
considered 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.
or
- One session per group: the LNS creates one replication context
per (source-list, group) pair.
For groups in EXCLUDE mode, the LNS will create one replication
context per (list of sources excluded by *all* the receivers,
group). The list of sources represents the intersection of the
sets, not the union.
3) For each replication context, the LNS will create one L2TP
multicast session (if threshold conditions are met; see Section
4.3) and its associated Outgoing Session List (OSL). The OSL
lists L2TP sessions that requested the multicast flow
corresponding to the group and the associated source-filtering
properties. There is one OSL per replication context; i.e., per
L2TP multicast session.
For a group member running an SFGMP, it is therefore possible to
receive multicast traffic from sources that have been explicitly
excluded in its SFGMP membership report if other group members in the
same L2TP tunnel wish to receive packets from these sources. This
behavior is comparable to the case where group members are 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
connected to the same multi-access network in terms of multicast
traffic received. For groups in INCLUDE mode with a policy allowing
one L2TP multicast session per (source, group), the behavior is
slightly improved because it prevents group members from receiving
traffic from non-requested sources. On the other hand, this policy
potentially increases the number of L2TP multicast sessions to
establish and maintain. Examples are provided in Appendix A.
In order for the LAC to forward the 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, to condense the
total desired reception state of a group to a minimum set so that all
systems’ memberships are satisfied.
Within the context of L2TP, each L2TP session has to be considered an
attached network by GMP and SFGMP protocols. When the L2TP multicast
extension is activated, each L2TP Control Connection has to be
considered a pseudo attached network, as well, in order to condense
group membership reports for every L2TP session in the tunnel.
Therefore, a list of group states is maintained for each L2TP Control
Connection into which the membership information of each of its L2TP
sessions is merged. This list of group states is a set of membership
records of the form (group, filter-mode, source-list).
Each group state represents the result of a merging process applied
to subscriptions on L2TP sessions of a Control Connection for a
considered group. This merging process is performed in three steps:
1) Conversion of any GMP subscription into SFGMP subscription
(IGMPv1/v2 to IGMPv3, MLDv1 to MLDv2);
2) Removal of subscription timers and, if filter-mode is EXCLUDE,
sources with source timer > 0;
3) Then, resulting subscriptions are merged by using merging rules
described in SFGMP specifications ([RFC3376], Section 3.2,
[RFC3810], Section 4.2).
This process is also described in [PROXY]. Examples of group state
determination are provided in Appendix A.
4.3. Triggering
The rules to be enforced by the LNS whereby it is decided when to
open a dedicated L2TP multicast session for a multicast group SHOULD
be configurable by the LNS administrator. This would typically
happen whenever a threshold of MULTICAST_SESSION_THRESHOLD
receivers/sessions referenced in a replication context is reached.
This threshold value SHOULD be valued at 2 by default, as it is worth
opening a dedicated L2TP multicast session for two group members
sharing the same desired reception state (which means that two L2TP
unicast sessions are concerned). In this case, the OSL will
reference two distinct L2TP sessions.
The actual receipt by the LNS of multicast traffic requested by end-
users can also be taken into account to decide whether the associated
L2TP multicast session has to be opened.
Whenever an OSL gets empty, the LNS MUST stop sending multicast
traffic over the corresponding L2TP multicast session. Then the L2TP
multicast session MUST be torn down as described in Section 7.
Filter-mode changes for a group can also trigger the opening or the
termination of L2TP multicast sessions in the following ways:
a) From INCLUDE Mode to EXCLUDE Mode
When a group state filter-mode switches from INCLUDE to EXCLUDE, only
one replication context (and its associated L2TP multicast session)
issued 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 has to update it 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 (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 is below a predefined threshold (see Section 7).
To limit the duration of temporary packet loss or duplicates to
receivers, the LNS has to minimize delay between OSL updates messages
sent to the LAC. Therefore, one can assume that terminating a
multicast session passively gives the smoothest transition.
b) From EXCLUDE Mode to INCLUDE Mode
When a group state 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 has to update
it accordingly with the following information:
- 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 will be 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 these 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 delay between OSL updates messages sent to the LAC.
4.4. Multicast Traffic Sent from Group Members
The present document proposes a solution to enhance the forwarding of
downstream multicast traffic exclusively; i.e., data coming from the
LNS toward end-users connected to the LAC. If a group member that
uses an L2TP session is also a multicast source for traffic conveyed
in a multicast session, datagrams may be sent back to the source. To
prevent this behavior, two options can be used in the LNS:
1) Disable the multicast packets’ forwarding capability, for those
multicast datagrams sent by users connected to the network by
means of an L2TP tunnel. Protocols using well-known multicast
addresses MUST NOT be impacted.
2) Exclude from the OSL the L2TP session used by a group member
that sends packets matching the replication context of this
OSL. Therefore, the corresponding multicast flow is sent by
the LNS over the user L2TP unicast session, using standard
multicast forwarding rules.
5. L2TP Multicast Session Opening Process
The opening of an L2TP multicast session is initiated by the LNS. A
three-message exchange is used to set up the session. The following
is 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)
Multicast-Session-Request (MSRQ) is a control message sent by the LNS
to the LAC to indicate that a multicast session can be created. The
LNS initiates this message according to the rules in Section 4.3. It
is the first in a three-message exchange used for establishing a
multicast session within an L2TP tunnel.
A LNS MUST NOT send a 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 the L2TP
tunnel was not opened with control messages including a Multicast
Capability AVP.
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