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.