Subject: L2TP multicast extension (resend)

From: BOURDON Gilles FTRD/DAC/ISS <[email-masked]>
Date: Tue, 6 Mar 2001 11:08:21 +0100

Sorry if you receive it twice, but it seems my first post failed.

A direct link : 
http://www.ietf.org/internet-drafts/draft-bourdon-l2tpmulticast-00.txt

Gilles.

--------------------------------------------------------
Previously sent the 02/23/01 to [email-masked]
Original message: 

Here is the first version of a draft addressing the problem of conveying
efficiently multicast traffic within L2TP tunnels. 
Comments, corrections, new ideas are welcome.

Thanks.

Gilles.

Network Working Group                                         G. Bourdon
Internet Draft                                        France Telecom R&D
Document: draft-bourdon-l2tpmulticast-00.txt               February 2001
  
                        L2TP Multicast Extension 
                  <draft-bourdon-l2tpmulticast-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 August 2001                   [Page 1] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 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.      Security Considerations....................................14 
   10.     References.................................................14 
   11.     Acknowledgments............................................15 
   12.     Author's Addresses.........................................15 
   Appendix A: IGMPv3 filters considerations..........................15 

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 
   L2TP tunnels that may be supported by the network will have to carry 
 
Bourdon                   Expires August 2001                   [Page 2] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 2001 

   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 RFC-2119 [1]. 
    
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 August 2001                   [Page 3] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 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 August 2001                   [Page 4] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 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 August 2001                   [Page 5] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 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 August 2001                   [Page 6] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 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. Random Vector AVP MUST 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 August 2001                   [Page 7] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 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 August 2001                   [Page 8] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 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 August 2001                   [Page 9] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 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 = XYZ (Note: XYZ 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            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              XYZ              |         Session ID 0          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              ...              |         Session ID N          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   There can be from 1 to N Session ID 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 August 2001                  [Page 10] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 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 = RST (Note: RST 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            | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |              RST              |         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 August 2001                  [Page 11] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 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 = JKL (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              |        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 August 2001                  [Page 12] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 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 
   MULTICAST_SESSION_THRESHOLD entries.   
   Multicast session teardown can be initiated either by the LAC or the 
   LNS. However, a multicast session SHOULD be killed after a period of 
   MULTICAST_SESSION_HOLDTIME seconds if the corresponding OSL is empty. 
   The MULTICAST_SESSION_HOLDTIME value is 10 by default, and SHOULD be 
   configurable either by the LAC or LNS administrator. This timer 
   prevents multicast session flapping.  
   The multicast session can be torn down for multiple reasons, which 
   may include specific criteria not described here (can be vendor-
   specific).   
        
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 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  

Bourdon                   Expires August 2001                  [Page 13] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 2001 

   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 
   is intended (e.g. the LAC is always aware of PPP link parameters, as 
   described in [RFC2661], Section 6.14). 
        
9. Security Considerations  
    
   This proposal does not introduce any additional issues as far as the 
   activation of the L2TP protocol is concerned. 

10. 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.  

Bourdon                   Expires August 2001                  [Page 14] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 2001 

   [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, B. Fenner, I. Kouvelas, A.          
                Thyagarajan, "Internet Group Management Protocol,        
                Version 3", <draft-ietf-idmr-igmp-v3-06.txt>, Work in  
                Progress, January 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]      B. Fenner, "IGMP-based Multicast Forwarding ("IGMP       
                proxying")", <draft-fenner-igmp-proxy-03.txt>, Work in  
                Progress, July 2000  
                     
   [SVCTYPE]    D. McPherson, S. Nanji, "L2TP Service Type",   
                <draft-ietf-l2tpext-svctype-00.txt>, Work in Progress,  
                August 2000.  
            
11. 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, and Francis Houllier for PPP 
   considerations. 
    
12. 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: [email-masked]  

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. 
 
Bourdon                   Expires August 2001                  [Page 15] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 2001 

   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 
   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 

Bourdon                   Expires August 2001                  [Page 16] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 2001 

   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 
    
   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 
 
Bourdon                   Expires August 2001                  [Page 17] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 2001 

   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. 
    
   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. 
 
Bourdon                   Expires August 2001                  [Page 18] 
 Internet Draft     draft-bourdon-l2tpmulticast-00.txt      February 2001 

   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 August 2001                  [Page 19]