L2TPEXT Working Group G. Bourdon Internet Draft France Telecom R&D Document: draft-ietf-l2tpext-mcast-01.txt January 2002 Category: Experimental L2TP Multicast Extension <draft-ietf-l2tpext-mcast-01.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. Tunnel establishment........................................4 3.1. Negotiation phase...........................................4 3.2. Multicast Capability AVP (SCCRQ, SCCRP).....................4 4. L2TP multicast session establishment........................5 4.1. IGMP states in LNS..........................................5 4.2. Triggering..................................................6 5. L2TP multicast session opening process......................6 Bourdon Expires July 2002 [Page 1]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 5.1. Multicast Session AVP (OCRQ)................................7 5.2. OCRQ........................................................7 5.3. OCRP........................................................8 5.4. OCCN........................................................8 6. Session maintenance and management..........................8 6.1. Outgoing Sessions List updates..............................9 6.1.1. New Outgoing Sessions AVP (MSI).............................9 6.1.2. Withdraw Outgoing Sessions AVP (MSI).......................10 6.2. Multicast Packets Priority AVP (MSI).......................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........................................14 10. Security Considerations....................................15 11. References.................................................15 12. Acknowledgments............................................15 13. Author's Addresses.........................................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 for transmitting multicast data only 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 embed a L2TP Network Server (LNS) capability may be involved 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 make the L2TP Access Concentrator (LAC) perform the traffic replication. By doing so, it is expected to spare transmission resources in the core network that supports L2TP tunnels. This multicast extension to L2TP is designed so that it does not affect the behavior of L2TP equipment under normal conditions. A solution to carry multicast data once in a L2TP tunnel is interesting for service providers since edge equipments are aggregating more and more users. This is particularly true for operators who are deploying xDSL (Digital Subscriber Line) and cable infrastructure. Therefore, L2TP tunnels that may be Bourdon Expires July 2002 [Page 2]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 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 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 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]. 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 intended to convey multicast traffic only. 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 Designates a Multicast Interior Gateway Protocol. (*, G) Designates a multicast group state, considering the group G and all sources sending to this group G. Bourdon Expires July 2002 [Page 3]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 2. Motivation for a session-based solution Multicast data has to be seen as a singular flow that potentially concerns all 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 is presumably in charge of the IP multicast service and the related engineering aspects. As such, he must be capable of filtering multicast flows on a multicast source basis, on a multicast group basis, and on a user basis (users who access the network using an L2TP session that terminates in this LNS). - Having an L2TP session dedicated for a multicast 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. Tunnel establishment 3.1. Negotiation phase Multicast extension capability is negotiated between the LAC and the LNS during the tunnel establishment phase. However, establishment procedures defined in [RFC2661] remain unchanged. A LAC indicates its multicast extension capability by using a new AVP, the "Multicast Capability" AVP. There is no explicit acknowledgement from the LNS during the tunnel establishment phase. Instead, the LNS is granted to use a "Multicast Session" AVP during the L2TP session opening phase, as defined in Section 5 of this document. 3.2. Multicast Capability AVP (SCCRQ, SCCRP) In order to inform the LNS that a LAC is able to handle multicast sessions, the LAC sends a Multicast Capability AVP during the tunnel establishment phase. This AVP is sent either in a SCCRQ or SCCRP control message by the LAC towards the LNS. There is no point to send this AVP from an LNS to a LAC except for information or debugging purposes, since all L2TP Bourdon Expires July 2002 [Page 4]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 multicast actions will be initiated by the LNS, if the remote LAC(s) support the multicast extensions. Upon receipt of the Multicast Capability AVP, an LNS may have two distinct behaviors: 1) The LNS doesn't implement L2TP multicast extensions: the Multicast Capability AVP is ignored, and the LNS will not initiate any L2TP multicast action. 2) The LNS implements L2TP multicast extensions, and therefore supports the Multicast Capability AVP: the LNS is granted to send L2TP specific commands for multicast towards the LAC. The multicast capability refers exclusively to the tunnel for which the AVP has been received during tunnel establishment phase. It SHOULD be possible for a LNS administrator to shut down L2TP multicast extension features towards one or a set of LAC. In this case, the LNS behavior is similar to 1). The AVP has the following format: Vendor ID = to be defined Attribute = ABC (16 bits) (Note: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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 IGMPv1 ([RFC1112]) or IGMPv2 ([RFC2236]) and acts as an IGMP querier. The router that supports the LNS capability MUST also be the Designated Router for the M-IGP running in the network. Bourdon Expires July 2002 [Page 5]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 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 defined by a (*, 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 OILs. Using these tables, the LNS can build for each subscribed group within a tunnel a list of the associated L2TP sessions: the Outgoing Sessions List (OSL). An OSL gives the ability to identify which L2TP sessions connect users interested in a common multicast group, and this for each L2TP tunnel. There is one OSL maintained per L2TP multicast session (i.e. per (*, G) state) within an 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 of this document. The LAC does not have any IGMP activity; IGMP processing is 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 this context. 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. 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 subscribed by two receivers (which means that two L2TP unicast sessions are concerned). Reception by the LNS of 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 an 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 procedure always starts with an OCRQ message. If required, the Random Vector AVP has to be used as defined in [RFC2661]. Bourdon Expires July 2002 [Page 6]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 5.1. Multicast Session AVP (OCRQ) The Multicast Session AVP has to be used in OCRQ control message by the LNS during the L2TP multicast session opening phase in order to inform the LAC of the particular status of the session to be created. Using this AVP will give a multicast context to the session, and will therefore require a specific behavior from the LAC and the LNS as described in Section 6. There are also some restrictions associated with the usage of this AVP in an OCRQ control message, as described in Section 5.2. A LNS MUST NOT send an OCRQ with the Multicast Session AVP if the remote LAC did not open the L2TP tunnel with the Multicast Capability AVP. The LAC MUST close the session if it receives an OCRQ control message with a Multicast Session AVP, while the L2TP tunnel was not opened with a Multicast Capability AVP. The AVP has the following format: Vendor ID = to be defined Attribute = DEF (16 bits) (Note: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DEF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The M-bit MUST be set to 1, the AVP MAY be hidden (H-bit set to 0 or 1). The length of this AVP is 6 octets. 5.2. 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 Multicast Session AVP MUST be placed as defined in section 5.1 of this document, and may be preceded by a Random Vector AVP if the Multicast Session AVP has to be hidden. The Multicast Session AVP gives the ability for the LAC to adapt its behavior for standard OCRQ and for multicast OCRQ. The following AVPs MUST be present in multicast OCRQ : Bourdon Expires July 2002 [Page 7]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 Message Type Multicast Session Assigned Session ID The following AVP MAY be present in multicast OCRQ: Maximum BPS The Maximum BPS value is set by the LNS administrator. However, this value should be chosen in accordance with the line capabilities of the end-users. The Maximum BPS value SHOULD NOT be higher than the highest speed connection for all end-users within the L2TP tunnel. 5.3. OCRP OCRP (Outgoing Call ResPonse) is sent by the LAC to the LNS in response to the OCRQ message previously sent. 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.4. 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. 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 a multicast session is used for downstream purposes only. 6. Session maintenance and management 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 Bourdon Expires July 2002 [Page 8]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 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 assigned session ID associated to the multicast session (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 the updating AVP is referring to. 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 (MSI) 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. Bourdon Expires July 2002 [Page 9]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 The AVP has the following format: Vendor ID = to be defined Attribute = GHI (16 bits) (Note: GHI 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GHI | 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 message 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 to avoid duplicate multicast packets. The multicast traffic can use L2TP unicast sessions again (since these sessions are identified 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 (MSI) 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, but should be set accordingly to the multicast activity 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. Bourdon Expires July 2002 [Page 10]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 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 = JKL (16 bits) (Note: JKL 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JKL | Session ID 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Session ID N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There can be from 1 to N Session IDs 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 (MSI) The Multicast Packets Priority AVP is intended to provide the LAC with an 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 for the provisioning of 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 end-user in the order it comes from the LNS, whatever 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. 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) Bourdon Expires July 2002 [Page 11]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 1: Standard traffic priority 2: Multicast traffic priority The AVP has the following format: Vendor ID = to be defined Attribute = MNO (16 bits) (Note: MNO 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MNO | 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 multicast traffic only: unicast packets might be dropped because the multicast flow overwhelms 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 a 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 adopting a specific behavior for both unicast and 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 for the concerned user. This is the only case where a MSI control message can be sent for a Bourdon Expires July 2002 [Page 12]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 L2TP unicast session. 6.2.3. Priority It is the responsibility of the network administrator to decide which behavior to adopt 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 defined 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: - The threshold value used to determine if the L2TP multicast session has to be torn down is lower than the MULTICAST_SESSION_THRESHOLD value; - The MULTICAST_SESSION_THRESHOLD value is used to determine 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, including 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 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 a multicast CDN message: Message Type Result Code Assigned Session ID Bourdon Expires July 2002 [Page 13]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 The Cause Code AVP SHOULD NOT be present in a multicast CDN message (because Q.931 Cause Codes make no sense in a multicast session context). 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: aa - No multicast traffic for the group bb - No more receivers (Note: aa and bb to be defined by the IANA) o The code aa 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 bb 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. 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 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 PPP link parameters, as described in [RFC2661], Section 6.14). It has to be noted that using L2TP Multicast Extension features is not appropriate for end-users who have negotiated a sequenced layer-2 connection with the LNS. 9. IANA Considerations This document defines: - 1 message type: MSI (Multicast Session Information) - 5 AVPs: o Multicast Capability Bourdon Expires July 2002 [Page 14]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 o Multicast Session o New Outgoing Sessions o Withdraw Outgoing Sessions o Multicast Packets Priority - 2 result codes: o No multicast traffic for the group o No more receivers IANA will assign, register and maintain values for these new attributes. 10. Security Considerations The extension described in this document does not introduce any additional security 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. 12. Acknowledgments Thanks to Christian Jacquenet for all the corrections done on this document and his precious advice, Pierre Levis for his contribution about IGMP, Francis Houllier for PPP considerations and Xavier Vinet for his input about thresholds. Bourdon Expires July 2002 [Page 15]
Internet Draft draft-ietf-l2tpext-mcast-01.txt January 2002 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@rd.francetelecom.com Full Copyright Statement "Copyright (C) The Internet Society (2002). 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. 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 July 2002 [Page 16]
