L2TPEXT Working Group G. Bourdon
Internet Draft France Telecom R&D
Document: draft-ietf-l2tpext-mcast-00.txt July 2001
Category: Experimental
L2TP Multicast Extension
<draft-ietf-l2tpext-mcast-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard
method for tunneling PPP [RFC1661] packets. This document describes
an extension to L2TP, in order to have an efficient use of L2TP
tunnels within the context of deploying multicast services whose data
will have to be conveyed by such 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. Negotiation of multicast capability.........................4
3.1. LAC behaviour...............................................4
3.2. LNS behaviour...............................................5
4. L2TP multicast session establishment........................5
4.1. IGMP states in LNS..........................................5
4.2. Considerations about IGMP versions..........................6
4.3. Triggering..................................................7
Bourdon Expires January 2002 [Page 1]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
5. L2TP multicast session opening process......................7
5.1. OCRQ........................................................7
5.2. OCRP........................................................8
5.3. OCCN........................................................8
6. Session maintenance and management..........................8
6.1. Outgoing Sessions List updates..............................9
6.1.1. New Outgoing Sessions AVP...................................9
6.1.2. Withdraw Outgoing Sessions AVP.............................10
6.2. Multicast Packets Priority AVP.............................11
6.2.1. Global configuration.......................................12
6.2.2. Individual configuration...................................12
6.2.3. Priority...................................................13
7. Multicast session teardown.................................13
7.1. Operations.................................................13
7.2. Result Codes...............................................14
8. Traffic merging............................................14
9. IANA Considerations........................................15
10. Security Considerations....................................15
11. References.................................................15
12. Acknowledgments............................................16
13. Author's Addresses.........................................16
Appendix A: IGMPv3 filters considerations..........................16
1. Introduction
The deployment of IP multicast services may co-exist with L2TP tunnel
engineering. From this perspective, the forwarding of multicast data
within L2TP sessions may impact the throughput of L2TP tunnels. This
proposal aims to reduce this impact by applying replication mechanism
of multicast traffic only when necessary.
The solution described herein provides a mechanism to transmit
multicast data once for all the L2TP sessions that have been
established in a tunnel, each multicast group having a dedicated L2TP
session.
Within the context of deploying IP multicast services, it is assumed
that the routers of the IP network that act as LNS may participate in
the forwarding of multicast data, towards users who access the
network through an L2TP tunnel. Then the LNS is in charge of
replicating the multicast data for a multicast group G for each L2TP
session that is used by a receiver who has actually subscribed to
group G. The solution described here gives the ability for a LNS to
send multicast data once and have the traffic replicated in the LAC
only. This is assumed to spare transmission resources in the network
that supports L2TP tunnels. This multicast extension for L2TP is
designed so that it does not affect the behavior of L2TP equipment
under normal conditions. The need for a solution to carry multicast
data once in an L2TP tunnel is crucial for service providers since
the edge equipment of the network are aggregating more and more
users. This is particularly true for operators who are deploying xDSL
(Digital Subscriber Line) and cable infrastructure. Therefore, the
Bourdon Expires January 2002 [Page 2]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
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 towards the 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
their framing scheme is.
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
L2TP unicast session or unicast session
These terms refer to the definition of "Session", as it is described
in the terminology section of [RFC2661]. In addition, this document
may use this term to designate other connection types than PPP
connection.
L2TP multicast session or multicast session
These terms refer to a connection between the LAC and the LNS. This
connection is opened, maintained and closed as it is performed for
L2TP unicast sessions, using the same mechanisms described in
[RFC2661].
Additional messages and 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 only intended to convey multicast traffic.
L2TP session or session
These terms are used when there is no need to dissociate multicast
from unicast sessions, and thus designate both.
M-IGP
Designate a Multicast Internet Gateway Protocol. PIM-SM (and SSM
extension), PIM-DM, M-OSPF, DVMRP, CBT are M-IGPs.
(*, G)
Designate a multicast group state, considering the group G and all
sources sending to this group G.
(S, G)
Bourdon Expires January 2002 [Page 3]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
Designate a multicast group state, considering the group G and the
source S sending to this group G.
(*-{S}, G)
Designate a multicast group state, considering the group G and all
source addresses sending to the group G, but source address(es) S.
2. Motivation for a session-based solution
Multicast data has to be seen as a singular flow which concerns all
kinds of protocols carried within L2TP sessions already existing in a
tunnel. It means that a given L2TP session can be dedicated for the
forwarding of a unique multicast flow that is addressed to multiple
users. A session carrying IP multicast data is independent from the
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 group G to carry multicast
data is motivated by the following arguments:
- The administrator of the LNS has to be in charge of the IP
multicast service and the related engineering aspects. He must be
capable of filtering multicast flows on a multicast source basis, on
a multicast group basis, and on a user basis (who access the network
using an L2TP session ending in this LNS).
- Having an L2TP session dedicated for a multicast group gives the
ability to have distinct policies for each group. For instance, it is
possible to allow more bandwidth for some groups, or change the
priority treatment for multicast packets against unicast packets.
- It is not always acceptable nor possible to have multicast
forwarding done 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, without necessity of
having a multicast capability in the underlying network.
3. Negotiation of multicast capability
Multicast extension capability is negotiated by LAC and LNS during
the tunnel establishment phase.
3.1. LAC behaviour
The procedure used is described in [SVCTYPE], with the following
particularities:
- The Service Capabilities List AVP includes a Service Type with a
value = X corresponding to the L2TP multicast capability (Note: value
X to be assigned as defined in [SVCTYPE]).
Bourdon Expires January 2002 [Page 4]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
- The L2TP multicast capability value is sent in a Service
Capabilities List AVP only from a LAC to an LNS. It SHOULD NOT be
sent from the LNS to the LAC.
As described in [SVCTYPE], the basic tunnel establishment procedures
defined in [RFC2661] remain unchanged.
3.2. LNS behaviour
Upon reception by an LNS of a Service Capabilities List AVP embedding
a service type corresponding to the L2TP multicast capability, an LNS
may have three distinct behaviours:
1) The LNS doesn't implement service types as defined in [SVCTYPE]:
the Service Capabilities List AVP is ignored, and the LNS will not
initiate any L2TP multicast action.
2) The LNS implements service types as defined in [SVCTYPE], but
doesn't activate or recognize the L2TP multicast capability
parameter: the LNS will not initiate any L2TP multicast action.
3) The LNS implements service types as defined in [SVCTYPE], and
supports the L2TP multicast capability parameter: the LNS is granted
to send L2TP specific commands for multicast towards the LAC.
The L2TP multicast capability applies exclusively to the tunnel for
which the parameter has been received during tunnel establishment
phase.
4. L2TP multicast session establishment
4.1. IGMP states in LNS
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 router that embeds the LNS feature
MUST support IGMP (Internet Group Management Protocol, v1, v2 or v3)
and acts as a IGMP querier.
The router MUST also be Designated Router for the M-IGP running in
the network, or be IGMP proxy (as defined in [PROXY]).
As a multicast router, the equipment that embeds the LNS function
will be involved in the state maintenance related to the multicast
groups for which receivers have subscribed to, i.e. the maintenance
of an OIL (Outgoing Interface List) for every multicast group G which
is defined either by a (*, G) or by an (S, G) state. The OIL for a
given multicast group G will be partly composed by logical
interfaces. All or some of these logical interfaces will correspond
to L2TP unicast sessions in this context.
Implementing IGMP requires the LNS-capable equipment to create and
maintain such a list. Using this list, the LNS can build for each
subscribed group within a tunnel a list of the associated L2TP
sessions. This "Outgoing Sessions List" (OSL) gives the ability to
identify which L2TP sessions are conveying a common multicast group,
Bourdon Expires January 2002 [Page 5]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
and this for each L2TP tunnel. Whenever the OSL gets empty, the LNS
MUST stop sending multicast traffic over the L2TP multicast session.
Then the L2TP multicast session MUST be torn down as described in
Section 8. There is one OSL maintained per L2TP multicast session
within an L2TP tunnel.
The LAC does not have any IGMP activity. IGMP processing is only
performed by the LNS. The LAC is a layer-2 equipment, and is not
supposed to track IGMP messages between users and the LNS.
In order for the LAC to forward the multicast traffic received
through the L2TP multicast session to end-users, the LNS sends to the
LAC the OSL for the related multicast session (see Section 6).
4.2. Considerations about IGMP versions
[IGMPv3] provides source filtering and thus gives the ability for a
receiver to report interest in receiving packets from specific source
addresses or from all but specific source addresses. The complexity
of combinations which can be achieved with IGMPv3 reports to set a
filter makes difficult the establishment of an optimal L2TP multicast
session. The L2TP Multicast Extension model gives the opportunity for
developers to have their own way to handle IGMPv3 filters to
establish L2TP multicast sessions: the decision process of L2TP
multicast session creation, the OSL set up and multicast traffic
filtering capability based on the source address are hosted by the
LNS. Thus developers have all degrees of liberty to set up their own
multicast L2TP session creation rules. Here is a non-exhaustive list
of rules that might be applied to handle IGMPv3 filters:
a- Establishment of an L2TP multicast session based on the IGMPv3
filter.
b- Establishment of multiple (S, G) multicast sessions for "INCLUDE"
IGMPv3 filters, and filter-based multicast sessions for "EXCLUDE"
IGMPv3 filters (which would be (*, G) multicast sessions with packet
filtering performed by the LNS based on the source addresses which
have been explicitly excluded in the IGMPv3 report).
c- Establishment of multiple (S, G) multicast sessions, resulting
from the decomposition of IGMPv3 filters for the group G. Each
session creation would be triggered by reception by the LNS of a
multicast packet for group G coming from source S and matching
subscriptions recorded for several unicast sessions. IGMPv1/2
subscriptions would be translated in multiple (S, G) sessions, except
if there are only IGMPv1/2 reports.
d- Establishment of (Si, G) and (*-{Si}, G) L2TP multicast sessions
to match all IGMPv3 filters existing for the users in the considered
tunnel. Individual filters are then composed by an appropriate set of
L2TP multicast sessions forwarding rules (i.e. determined by OSL
entries).
Bourdon Expires January 2002 [Page 6]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
The solutions briefly mentioned above are more detailed in Appendix
A.
Usage of IGMPv1 ([RFC1112]) or IGMPv2 ([RFC2236]) does not require
such a particular attention: there can be only one L2TP multicast
session for a group within a tunnel, and there is no filtering
features required in the LNS equipment.
For simplicity purposes, this document refers to L2TP multicast
sessions as sessions conveying all the traffic for a given multicast
group. Of course, this has to be moderated by what the IGMPv3 filter
might be. Triggering rules as well as session maintenance described
in this document are operation functions separated from optimisation
policies introduced by IGMPv3.
4.3. Triggering
The rules to be enforced by the LNS so as to decide 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 number of MULTICAST_SESSION_THRESHOLD receivers/sessions
is reached. This threshold value SHOULD be valued at 2 by default, if
we consider that it is worth opening a dedicated L2TP multicast
session for a multicast group received by 2 receivers (which means
that 2 L2TP unicast sessions are concerned).
Reception by the LNS of actual multicast traffic requested by end-
users can also be taken into account to decide if the associated L2TP
multicast session has to be opened.
5. L2TP multicast session opening process
The opening of L2TP multicast session is performed by the LNS as
described in [RFC2661]. However, since the decision is made by the
LNS, the multicast session opening always starts with an OCRQ
(Outgoing Call ReQuest) message. If required, the Random Vector AVP
has to be used as defined in [RFC2661].
5.1. OCRQ
The LNS opens a L2TP multicast session by sending an OCRQ to the LAC.
Due to the particular status of a multicast session, the multicast
OCRQ message has some restrictions compared to the rules defined in
[RFC2661] for regular L2TP sessions (e.g. no real outgoing call has
to be performed by the LAC, although this is an Outgoing Call ReQuest
message).
The Service Type AVP corresponding to L2TP multicast capability MUST
be placed as defined in [SVCTYPE], and may be preceded by a Random
Vector AVP if the Service Type AVP has to be hidden.
The Service Type AVP gives the ability for the LAC to adapt its
behavior for standard OCRQ and for multicast OCRQ.
Bourdon Expires January 2002 [Page 7]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
The following AVPs MUST be present in multicast OCRQ :
Message Type
Service Type
Assigned Session ID
The following AVP MAY be present in multicast OCRQ:
Maximum BPS
The Maximum BPS value is set up by the LNS administrator. However,
this value should be chosen in accordance with the line capabilities
of final users. The Maximum BPS value SHOULD NOT be higher than the
highest speed connection for all final users within the L2TP tunnel.
5.2. OCRP
OCRP (Outgoing Call ResPonse) is sent by the LAC to the LNS in
response to the OCRQ message previously sent. There is no Service
Type AVP in OCRP.
The following AVPs MUST be present in multicast OCRP:
Message Type
Assigned Session ID
Since Physical Channel ID AVP makes no sense in this context, it
SHOULD NOT be present in OCRP, even though its presence is defined as
optional in [RFC2661]. If present, the Physical Channel ID AVP MUST
be ignored in this context.
5.3. OCCN
OCCN is sent by the LAC to the LNS, giving the start for the latter
to send necessary multicast information (Section 6) for the group
using the newly created L2TP session. There is no Service Type AVP in
OCCN.
The following AVP MUST be present in multicast OCCN:
Message Type
The following AVP MAY be present in multicast OCCN:
Sequencing Required
The sequencing will occur only from the LNS to the LAC since
multicast session is only used for downstream purposes.
6. Session maintenance and management
Bourdon Expires January 2002 [Page 8]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
Once the multicast session is established, the LAC has to be informed
of the L2TP unicast sessions interested in getting the traffic from
the newly created session, as well as a related optional priority
parameter defined in Section 6.2.
To achieve this, a new control message type is defined: Multicast
Session Information (MSI). The associated Message Type AVP is encoded
with the values:
Vendor ID = to be defined
Attribute Type = 0
Attribute Value = XY (Note: XY to be assigned by IANA)
The M-bit MUST be set to 0, the H-bit MUST be set to 0.
The MSI control message is always sent by the LNS towards the LAC,
and carries additional AVPs to keep the OSL synchronised between the
LNS and the LAC, with an optional priority parameter for multicast
traffic versus unicast traffic. MSI can also be used to carry future
additional features.
Each MSI message is specific to a particular multicast session.
Therefore, the control message MUST use the associated multicast
session number previously assigned by the LAC, except for the case
mentioned in 6.2.2.
Random Vector AVP can be used with AVPs carried within a MSI control
packet according to the procedure specified in [RFC2661].
6.1. 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 the IGMP process running in the LNS (Section
4.1).
The LAC maintains an OSL as a per-group 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 send a New Outgoing Sessions AVP for additional(s) session(s) or
send a Withdraw Outgoing Sessions AVP to remove session(s). All
sessions mentioned in these AVPs MUST be added or removed by the LAC
from the pertaining OSL. The Outgoing Session List is identified by
the Tunnel ID and the multicast Session ID from which the updating
AVP is received.
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 a MSI message.
6.1.1. New Outgoing Sessions AVP
Bourdon Expires January 2002 [Page 9]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
The New Outgoing Sessions AVP can only be carried within a 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 = to be defined
Attribute = ABC (Note: ABC to be assigned by IANA)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ABC | Session ID 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Session ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There can be from 1 to N Session IDs present in the New Outgoing
Sessions AVP. This AVP must be placed in a MSI and sent immediately
after the establishment of the multicast session to indicate the LAC
what are the initial outgoing sessions, and at any time when one or
more outgoing sessions appear during the multicast session lifetime.
Upon reception of this AVP, the LAC MUST be ready to forward the
multicast traffic towards the indicated sessions as soon as the MSI
control message is acknowledged by the LAC.
An LNS is allowed to send multicast traffic within the L2TP multicast
session and stop sending multicast traffic for the related group
within L2TP unicast sessions mentioned in the AVP only when it
receives a reception acknowledgement from the LAC about the MSI
message carrying these session IDs. It has to be noted that from this
point, the multicast traffic for this group SHOULD NOT be transported
within each L2TP unicast session, and this to avoid duplicate
multicast packets. The multicast traffic can use L2TP unicast
sessions again (as these sessions are mentioned in this AVP) when the
L2TP multicast session goes down.
The M-bit MUST be set to 0, the AVP MAY be hidden (H-bit set to 0 or
1).
6.1.2. Withdraw Outgoing Sessions AVP
The Withdraw Outgoing Sessions AVP is sent whenever there is one or
more withdrawn subscriptions for the related multicast group
(designated by the session ID on which the MSI is sent). A latency
timer may be configurable in the LNS in order to group multiple
withdrawals in a single message. A recommended value for this timer
would be 0, which gives the best reactivity.
Bourdon Expires January 2002 [Page 10]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
Of course, in a very active multicast context this timer should be
changed accordingly, in order to avoid multiplicity of Withdraw
Outgoing Sessions AVP tranmissions.
The LAC can stop forwarding multicast traffic to the users mentioned
in the AVP for the related group as soon as it receives the MSI
message embedding this Withdraw Target Session AVP.
The format of the AVP follows the format adopted for New Outgoing
Sessions AVP.
The AVP has the following format:
Vendor ID = to be defined
Attribute = DEF (Note: DEF to be assigned by the IANA)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEF | Session ID 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Session ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There can be from 1 to N Session ID present in the Withdraw Outgoing
Sessions AVP. The M-bit MUST be set to 0, the AVP MAY be hidden (H-
bit set to 0 or 1).
6.2. Multicast Packets Priority AVP
The Multicast Packets Priority AVP is intended to provide the LAC
with indication on how to process multicast against unicast traffic.
Even though the LAC behavior is partially described here, the nature
of the traffic (layer-2 frames for regular sessions and pure IP for
multicast sessions) is not a criteria for priority decisions. Traffic
processing to provide a uniformly framed traffic for the final user
is described is section 8.
Three different behaviors can exist:
1) Best effort: the traffic is forwarded from the LAC to the final
user in the order it comes from the LNS, no depending on the type of
traffic. If the LAC forwarding interface buffer is full, packets
coming from unicast session or multicast session will be dropped with
equal chances, depending on their order of arrival.
2) Standard traffic priority: traffic coming down the L2TP unicast
session has priority over traffic coming down the L2TP multicast
session.
Bourdon Expires January 2002 [Page 11]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
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
values:
0: Best effort (default)
1: Standard traffic priority
2: Multicast traffic priority
The AVP has the following format:
Vendor ID = to be defined
Attribute = GHI (Note: GHI to be assigned by the IANA)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GHI | Priority Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is important to note that the multicast traffic rate can reach up
to Maximum BPS (as indicated in OCRQ). This rate can exceed the
maximum rate allowed for a particular final user. This means that
even with a priority value = 0, the final user might receive almost
only multicast traffic: unicast packets might be dropped because of
the multicast flow overwhelming the LAC forwarding buffer.
The default Priority Value is 0. The M-bit MUST be set to 0, 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.2.1. Global configuration
The Multicast Priority Packet AVP is sent for all L2TP unicast
sessions concerned by a specific multicast group represented by an
L2TP multicast session.
In this case, the AVP is sent in a L2TP MSI control message for the
related multicast session ID (Session ID = L2TP session for the
related 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.2.2. Individual configuration
The Multicast Priority Packet AVP is sent for a specific L2TP unicast
session concerned by applying specific behavior on unicast and
Bourdon Expires January 2002 [Page 12]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
multicast traffic. In this case, the AVP is sent in a L2TP MSI
control message for the L2TP unicast session (Session ID = L2TP
session for the concerned user). The priority value applies to the
individual session only, and doesn't affect other individual
sessions. It is important to note that in this case, all multicast
groups carried in L2TP multicast sessions are treated by the LAC the
same way.
This is the only case when a MSI control message can be sent for a
L2TP unicast session.
6.2.3. Priority
It is an administrator prerogative to decide which behavior has to be
applied between global or individual configuration, if the AVP is
sent twice (one for a multicast group and one for an individual
user). By default, only the individual configuration SHOULD be taken
into consideration in that case.
7. Multicast session teardown
A L2TP multicast session should be torn down when there are no longer
users interested in. More generally, we can consider that a multicast
session becomes useless as soon as the related OSL has less than a
predefined number of entries, this number being represented by a
threshold.
Multicast session flapping may occur when the number of OSL entries
is oscillating around the threshold, if the same value is used to
trigger the creation or the deletion of an L2TP multicast session.
To avoid this behavior, two methods can be used:
1) The threshold value used to determine if the L2TP multicast
session has to be torn down is lower than the
MULTICAST_SESSION_THRESHOLD value;
2) The MULTICAST_SESSION_THRESHOLD value is used to determine if
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 less than MULTICAST_SESSION_THRESHOLD entries. The
MULTICAST_SESSION_HOLDTIME value is 10 by default, and SHOULD
be configurable either by the LAC or LNS administrator.
The multicast session can be torn down for multiple reasons, which
may include specific criteria not described here (can be vendor-
specific).
A multicast session teardown can be initiated either by the LAC or
the LNS.
7.1. Operations
Bourdon Expires January 2002 [Page 13]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
The effective termination of a multicast session is initiated with a
CDN control message, sent either by the LAC or by the LNS. The CDN
message carries a Result Code AVP with an optional Error Code.
The following AVPs MUST be present in multicast CDN:
Message Type
Result Code
Assigned Session ID
The following AVP SHOULD NOT be present in multicast CDN (because
Q.931 Cause Codes make no sense in a multicast session context):
Cause Code
However, the Cause Code AVP MUST be ignored if received in this
context.
7.2. Result Codes
In order to make the Result Code AVP useful, the following values are
defined as additional codes to those listed in [RFC2661], Section
4.4.2:
xx - No multicast traffic for the group
yy - No more receivers
(Note: these are temporary numbers, may be changed later)
o The code xx 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 for the related group during a certain period of
time.
o The code yy may be used by the LAC or the LNS when the OSL is
empty.
As defined in [RFC2661], termination of a tunnel will terminate all
sessions carried within, including multicast sessions if any.
The Error Code field can be used within a CDN message, however no
additional codes are defined here (can be defined later).
8. Traffic merging
Both unicast and multicast traffic have to be merged by the LAC in
order to provide properly framed data to the end-user. Multicast
packets are framed by the LAC and transmitted towards the proper end-
user. Methods to achieve this function are not described here, since
it is mostly a vendor implementation issue.
All frames conveyed from the LAC to end-users have to follow the
framing scheme applied for the considered peer to which the traffic
Bourdon Expires January 2002 [Page 14]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
is intended (e.g. the LAC is always aware of PPP link parameters, as
described in [RFC2661], Section 6.14).
9. IANA Considerations
This document defines:
- 1 Service Type value to be used in the Service Capabilities
List AVP (see [SVCTYPE]).
- 1 message type (MSI)
- 3 AVPs (New Outgoing Sessions, Withdraw Outgoing Sessions,
Multicast Packets Priority)
- 2 result codes (No multicast traffic for the group, No more
receivers)
IANA will assign, register and maintain values for these new
attributes.
10. Security Considerations
This proposal does not introduce any additional issues as far as the
activation of the L2TP protocol is concerned.
However, activation of the L2TP multicast capability on a LAC could
make the equipment more sensitive to Denial of Service attacks if the
tunnel or the related LNS is hacked. By injecting appropriate control
packets in the tunnel towards a LAC, final users could be flooded by
unwanted multicast traffic. The LAC might also be sensitive to the
burden generated by the additional replication work.
11. References
[RFC1112] S. Deering, "Host Extensions for IP Multicasting",
RFC 1112, August 1989.
[RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2236] W. Fenner, "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
B. Palter, "Layer 2 Tunneling Protocol "L2TP" ",
RFC2661, August 1999.
[IGMPv3] B. Cain, S. Deering, W. Fenner, I. Kouvelas, A.
Thyagarajan, "Internet Group Management Protocol,
Version 3", <draft-ietf-idmr-igmp-v3-07.txt>, Work in
Progress, March 2001.
Bourdon Expires January 2002 [Page 15]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
[L2TPBIS] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
B. Palter, "Layer 2 Tunneling Protocol "L2TP" ",
<draft-ietf-l2tpext-l2tpbis-01.txt>, Work in Progress,
November 2000.
[PROXY] W. Fenner, "IGMP-based Multicast Forwarding ("IGMP
proxying")", <draft-ietf-idmr-proxy-00.txt>, Work in
Progress, April 2001.
[SVCTYPE] D. McPherson, S. Nanji, "L2TP Service Type",
<draft-ietf-l2tpext-svctype-01.txt>, Work in Progress,
April 2001.
12. Acknowledgments
Thanks to Christian Jacquenet for all the corrections done on this
document and his precious advice, Pierre Levis for his contribution
about IGMPv3 optimisation, Francis Houllier for PPP considerations
and Xavier Vinet for his input about thresholds.
13. Author's Addresses
Gilles Bourdon
France Telecom R&D
38-40, rue du General Leclerc
92794 Issy les Moulineaux Cedex 9 - FRANCE
Phone: +33 1 4529-4645
Email: gilles.bourdon@francetelecom.com
Appendix A: IGMPv3 filters considerations
Section 4.2 mentions some ways to handle IGMPv3 subscription reports.
This appendix intends to describe more precisely what might be the
decision process to create L2TP multicast session when the LNS has to
deal with IGMPv3.
Conceptually, there is no obligation for the LNS to proceed in a
particular way more than another: the LNS decides what multicast
sessions to open and how to forward them to appropriate users, and
the LAC follows. Therefore, there is no risk of incompatibility
between LAC and LNS implementations.
Although, to remain consistent with what L2TP Multicast Extension
intends to do, the multicast session opening process on the LNS MUST
be respectful of the following precepts:
a- End-users MUST NOT be impacted by usage of L2TP Multicast
Extension procedures between the LAC and the LNS;
b- Usage of L2TP Multicast Extension is done for bandwidth
optimisation between the LAC and the LNS. A solution which logically
Bourdon Expires January 2002 [Page 16]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
might break this rule MUST NOT be implemented, since it might impact
negatively the L2TP service provided.
IGMPv3 filters are applied to IGMP capable equipment interfaces
getting reports from IGMPv3 capable end-users. Depending on the
filter, the Designated Router (DR) initiate appropriate actions using
the M-IGP. IGMPv3 gives the ability for users to subscribe to a group
with either:
- an explicit list of source addresses from which the user wants to
get multicast traffic (INCLUDE mode);
or
- an explicit list of source addresses from which the user does not
want to get multicast traffic (EXCLUDE mode);
Of course, usual (*, G) reports are still possible with IGMPv3.
Depending of the IGMPv3 reports received by a DR, the filter for an
interface can be a complex combination of traffic to forward or to
discard. The problem could have been simple for the L2TP case since
each L2TP unicast session may be considered as a logical interface.
However, an L2TP multicast session may aggregate all IGMP states for
L2TP unicast session composing a L2TP tunnel. IGMPv3 filtering
capabilities raise the problem on how to satisfy users who want to
get multicast traffic for a group G coming from specific sources S,
and users who want to get traffic for the same group G, but not from
S. This means that the L2TP multicast session can not be seen only as
a group G forwarding issue.
The following sections give some idea of what is possible, each
solution having its own advantages and drawbacks.
A.1. Multicast sessions based on IGMPv3 filters
This is the easiest solution to understand, and probably to
implement. Each logical interface has its own IGMPv3 filter for
downstream traffic on the LNS. If the MULTICAST_SESSION_THRESHOLD is
reached with a set of matching IGMPv3 filters for logical interfaces
belonging to the same L2TP tunnel, then the LNS creates an L2TP
multicast session to convey the corresponding traffic.
The issue with this solution is that it is likely to have the same
multicast traffic conveyed several times in distinct sessions.
Example:
User A and B subscribe for sources S1 and S2 for group G1;
User C and D subscribe for sources S1 and S3 for group G1.
Then two multicast sessions would be created for ({S1, S2}, G1) and
for ({S1, S3}, G1). (S1, G1) would be conveyed twice, but the
bandwidth usage balance is still in favour of the L2TP Multicast
Extension solution.
A.2. Filter-based sessions and source-based sessions
Bourdon Expires January 2002 [Page 17]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
To solve the problem raised in A.1, it is possible to make specific
multicast sessions for (S, G), if the filter-mode is INCLUDE. If the
filter-mode is EXCLUDE, the process would be the same as described in
A.1.
Example 1:
Users A and B subscribe for sources S1 and S2 for group G1;
Users C and D subscribe for sources S1 and S3 for group G1.
Then three multicast sessions would be created for (S1, G1) (users A,
B, C and D), for (S2, G1) (users A and B) and for (S3, G1) (users C
and D).
This creates more multicast sessions, but is efficient in term of
bandwidth usage.
Example 2:
Users A and B subscribe to G1 but no traffic from source addresses S1
and S2
Users C and D subscribe to G1 but no traffic from source addresses S1
and S3
Then two multicast sessions would be created for (*-{S1, S2}, G1) and
for (*-{S1, S3}, G1). Most of the (*, G1) traffic would be conveyed
twice.
A.3. Source-based sessions
To solve the problem raised in A.2 example 2, a solution would be to
create only (S, G) multicast sessions, even with an EXCLUDE filter-
mode. INCLUDE filters would be handled as described in A.2.
For any EXCLUDE filter-mode applied to a group G: upon reception of
(S, G) traffic, the LNS creates an L2TP multicast session except if S
is explicitly excluded by all the IGMPv3 filters for the tunnel.
If all end-users for a tunnel are only reporting (*, G) interest,
there would be no creation of (S, G) multicast sessions.
The main risk with this solution is the creation of n multicast
sessions if group G has n senders.
The LNS may choose to trigger (S, G) multicast sessions creation only
upon reception of the related traffic in INCLUDE mode: this can
prevent from creating a multicast session if there is no related
traffic.
A.4. Optimal multicast sessions
In order to have a reasonable number of multicast sessions created
and an optimal bandwidth usage between the LAC and the LNS, a optimal
set of (*-{Si}, G) and (Si, G) sessions can be achieved.
- (*, G) interests would be satisfied by sending all (Si, G) sessions
and the (*-{Si}, G) session to the interested users;
- (*-{Sj}, G) interests would be satisfied by sending the right
combination of "outgoing sessions" to the LAC for (Si, G) sessions
and for the (*-{Si}, G) session;
- (Si, G) interests would be naturally satisfied.
Bourdon Expires January 2002 [Page 18]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
Although the optimal set of (*-{Si}, G) and (Si, G) sessions is
calculable, it is unlikely to keep it a long time: user subscriptions
would often change the existing states, probably leading to a
perpetual instable set of multicast sessions. However, this instable
behavior can be limited by privileging OSL changes rather than
multicast session changes, as demonstrated by the next example.
Session changes to obtain an optimal number of multicast sessions
opened can be done an a periodic basis. This period time should be
long enough to prevent multicast session instability.
Example:
Users A and B subscribe for sources S1 and S2 for group G1;
Users C and D subscribe to G1 but no traffic from source addresses S1
and S3.
Then three multicast sessions would be created (S1, G1) (users A and
B), (S2, G1) (users A, B, C and D) and (*-{S1, S2, S3}, G1) (users C
and D).
If a user E report interest for (*, G1), a fourth multicast session
(S3, G1) would be created.
If users C and D report interest for (*, G1) afterwards, then there
are two possibilities:
1- Delete the (S3, G1) session and change (*-{S1, S2, S3}, G1) for
(*-{S1, S2}, G1), and add C and D to (S1, G1) OSL.
2- Keep the sessions, and just change the OSL for (S1, G1) and (S3,
G1) to add users C and D.
Even though solution 1 is optimal in term of opened multicast
sessions, stability considerations give the advantage to solution 2.
However, both solution are optimal in term of bandwidth usage.
Full Copyright Statement
"Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Bourdon Expires January 2002 [Page 19]
Internet Draft draft-ietf-l2tpext-mcast-00.txt July 2001
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Bourdon Expires January 2002 [Page 20]
