From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4045.txt | 1571 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1571 insertions(+) create mode 100644 doc/rfc/rfc4045.txt (limited to 'doc/rfc/rfc4045.txt') diff --git a/doc/rfc/rfc4045.txt b/doc/rfc/rfc4045.txt new file mode 100644 index 0000000..505557b --- /dev/null +++ b/doc/rfc/rfc4045.txt @@ -0,0 +1,1571 @@ + + + + + + +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 + + + +Bourdon Experimental [Page 1] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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 + + + + +Bourdon Experimental [Page 2] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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. + + + + + + + + +Bourdon Experimental [Page 3] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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). + + + + + + +Bourdon Experimental [Page 4] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + - 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 + + + + +Bourdon Experimental [Page 5] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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. + + + + + + +Bourdon Experimental [Page 6] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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 + + + +Bourdon Experimental [Page 7] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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). + + + +Bourdon Experimental [Page 8] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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 + + + +Bourdon Experimental [Page 9] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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. + + + + +Bourdon Experimental [Page 10] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + +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 + + + + + +Bourdon Experimental [Page 11] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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 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 + + + + +Bourdon Experimental [Page 12] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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. + + + + + + + + +Bourdon Experimental [Page 13] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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. + + + + + + +Bourdon Experimental [Page 14] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + +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. + + + + + + + + +Bourdon Experimental [Page 15] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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). + + + + + + + +Bourdon Experimental [Page 16] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + +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. + + + + + + +Bourdon Experimental [Page 17] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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 + + + +Bourdon Experimental [Page 18] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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; + + + + + + +Bourdon Experimental [Page 19] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + - 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. + + + + + +Bourdon Experimental [Page 20] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + 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). + + + +Bourdon Experimental [Page 21] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + +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 + + + + + + + + + +Bourdon Experimental [Page 22] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + +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 + numbers, next messages will appear out of synch, yielding the + control connection to terminate. + + - If sequence numbers are inconsistent with current control + connection states, the spoofed control message will be queued + or discarded, as described in [RFC2661], Section 5.8. + + The activation of 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 is hacked. The LAC might also + be sensitive to the burden generated by the additional replication + work. + + As mentioned in [RFC2661], Section 9.2, securing L2TP requires that + the underlying transport make encryption, integrity, and + authentication services available 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. + + + +Bourdon Experimental [Page 23] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + [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 + + Thanks to Christian Jacquenet for all the corrections done on this + document and his precious advice, to Pierre Levis for his + contribution about IGMP, to Francis Houllier for PPP considerations, + and to Xavier Vinet for his input about thresholds. Many thanks to + W. Mark Townsley, Isidor Kouvelas, and Brian Haberman for their + highly valuable input on protocol definition. + + + + + + + + + +Bourdon Experimental [Page 24] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + +Appendix A. Examples of Group States Determination + + *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, {}) + + Therefore, two replication contexts will be 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 will be 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), one replication context will be created: + + -RC1: + ({S1, S2}, G1) packets, Multicast Session MS1, OSL = [1..9] + + + + +Bourdon Experimental [Page 25] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + + *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}) + + Therefore, one replication context will be 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 is changed to: + + (G1, EXCLUDE, {}) + + The replication context RC1 is changed 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)}) + + Therefore, two replication contexts will be created: + + -RC1: + (S1, G1) packets, Multicast Session MS1, OSL = 1, 2, 3 + -RC2: + (S2, G1) packets, Multicast Session MS2, OSL = 1, 2, 3 + + + + + + + +Bourdon Experimental [Page 26] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + + Next, user {4} subscribes to (Group G1, EXCLUDE {}), equivalent to an + IGMPv2 membership report. The group state for the L2TP tunnel is + changed to: + + (G1, EXCLUDE, {}) + + The replication context RC1 is changed to: + + -RC1: (*, G1) packets, Multicast Session MS1, OSL = 1, 2, 3, 4 + + The replication context RC2 is changed 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}) + + 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 + + + + + + + + + + + + + + +Bourdon Experimental [Page 27] + +RFC 4045 Efficient Multicast Traffic in L2TP April 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain 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 takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Bourdon Experimental [Page 28] + -- cgit v1.2.3