Subject: [L2tpext] Comments on draft-ietf-l2tpext-mcast-02.txt

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 02 Aug 2002 16:32:38 +0200

Bonjuor Gilles,

Please find comments and questions inline by WMT. 

Thanks,

- Mark 

Network Working Group                                         G. Bourdon 
Internet Draft                                        France Telecom R&D 
Document: draft-ietf-l2tpext-mcast-02.txt                    August 2002 
Category: Experimental                                                   
 
                        L2TP Multicast Extension 
                   <draft-ietf-l2tpext-mcast-02.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. 

WMT Editorial: No RFC references allowed in an abstract. 
    
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 February 2003               [Page 1] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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 

WMT Looks like some of your paragraphs have been merged (e.g. no space between,
or fully concatenated) in the Intro and throughout the document.
    
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 February 2003               [Page 2] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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. 

WMT Conjecture: In cases where the operator of the LAC and operator of the LNS
are different corporate entities, it may be an interesting business exchange as
to who should perform the replication here. Naturally, the LAC performing this
makes more sense from an overall bandwidth usage perspective. Replication isn't
free, so transferring this requirement from the LNS to the LAC is a transfer of
capital investment requirement as well. I suppose these issues exist with
cross-domain multicast in general though, and is something for the bean-counters
to figure out....

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 

WMT "L2TP foo bar or foo bar" in each of these terminology definitions seems
strange. Perhaps you could define these like:

   Unicast Session
   
       These terms.... ... (Also: L2TP Unicast Session)
    
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 February 2003               [Page 3] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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 

WMT Perhaps "Control Connection establishment" phase rather than "tunnel
establishment" phase would be more precise. The reader could probably more
easily correlate that this means the SCCRQ, SCCRP, and SCCCN messages, and it is
more inline with L2TPv3 (understanding that this draft is not targeted
specifically at L2TPv3 at this time).

   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 February 2003               [Page 4] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 2002 

   multicast actions will be initiated by the LNS, if the remote LAC(s) 
   support the multicast extensions.  

WMT But, if your Control Connection is serving an a box which can be an LAC or
LNS, there may be more reason than just debugging. There is no protocol
restriction disallowing initiation of an L2TP session from either side of a
Control Connection after it is established. e.g. Once a Control Connection is
up, either side can be an LAC or an LNS (this isn't just an L2TPv3 thing, it
exists in L2TPv2 as well). This is arguably an edge case, and you can get around
this by qualifying that your solution only covers the canonical LAC/LNS case
where neither side may have a dual-personality on a single Control Connection.
        
   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 February 2003               [Page 5] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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].  

WMT Why the Random Vector AVP called out specifically here? Also, note that you
*could* have still used the ICRQ/P/N exchange here, as Control Connections
SHOULD allow 2-way session bringup (something that may not be so obvious in
RFC2661). 

Bourdon                    Expires February 2003               [Page 6] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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). 

WMT Why not just create your own messages for multicast session bringup? e.g.
MCRQ/MCRP with whatever set of AVPs you like? What you have works too, but with
your own messages you don't have to worry about these being "special" OCRQ
messages. 

   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 February 2003               [Page 7] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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 February 2003               [Page 8] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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)  

WMT Regarding the attributes, ABC, DEF, XF, etc. Perhaps TBA1 TBA2 TBA3, etc.
(TBA == To Be Assigned) would be a little easier to track and for IANA to find
in the document?
    
   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. 

WMT "Carrying additional features" doesn't make a lot of sense... perhaps "carry
additional AVPs", but that is implicit in an L2TP message. Perhaps "MSI may be
extended to update the Multicast Session with additional parameters as needed"
is more accurate.

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

WMT Random Vector support should be implicit for all L2TP messages, but I agree
that it should be listed as a "May Be Present" AVP with your new control message
for completeness. 

WMT You should clearly list which AVPs MAY be present and MUST be present with
any new control message.
    
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 February 2003               [Page 9] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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. 

WMT If you are going to rely on acknowledgement of a message, you should do so
with an explicit REQ/REP message structure. You should have to rely on the
underlying control plane to have to provide an upcall when a specific message is
delivered.

   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.  

WMT Note that many L2TP implementations have been optimized to be able to handle
large numbers of control messages at one time. If your control channel windowing
is performing up to par, it should handle the necessary backoff for your peer. I
am not saying that what you are suggesting with the latency timer and
concatenation of withdrawls into a single message is bad, in fact it is probably
a good thing to have. But, we should remember to chalk this up as Yet Another
Motivation for a general ability to consolidate multiple actions into a single
message - this has come up for failover applications, port flapping affective
numerous l2tp sessions, etc.

   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 February 2003              [Page 10] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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.  

WMT How do you handle sequencing of the merged traffic ("we don't" is OK, but it
should be pointed out clearly somewhere)?
        
   The priority is encoded as a 16-bit quantity, which can take the 
   values:  
        
      0: Best effort (default)  
 
Bourdon                    Expires February 2003              [Page 11] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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 February 2003              [Page 12] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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.  

WMT Is it a requirement for the LAC to be able to handle each of these modes?
Or, can it simply ignore the message and do whatever it wants? 

WMT Also, if you do end up with a REQ/REP for the new/withdraw operations, I
think the dynamic priority update message could still be its own single message.
    
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 seconds 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. 

WMT Hmm... If a wide variety of methods are allowed here, and the teardown may
be initiated by the LAC or the LNS, then could you not end up in some serious
thrashing? Perhaps you need some more MUSTs here, or have one side always be the
decision-maker.
      
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 February 2003              [Page 13] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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.

WMT An "MCDN" could be your own message along with the MCRQ/MCRP messages.
        
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. 

WMT Aha, here is the mention that you don't do sequencing. This should probably
be called out a little more clearly. 

9. IANA Considerations 
    
   This document defines: 
      - 1 message type: MSI (Multicast Session Information) 
      - 5 AVPs: 
           o Multicast Capability 
 
Bourdon                    Expires February 2003              [Page 14] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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. 

WMT Here you should identify the sections, and TBA1, TBA2, etc. that they appear
in, and a reference to which values these refer to on the IANA page for L2TP.
The easier life is for IANA, the easier it is on us, and the less chance of
error.

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. 

WMT I suspect that the ability to setup a single session and cause packet
replication and injection into L2TP multiple sessions could be an interesting
platform for staging all sorts of attacks... This section might need a little
more filling out to get by the IESG, though some of the issues are probably
similar as those for Multicast in general (allowing you to reference or borrow
text from there if possible).

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 February 2003              [Page 15] 

Internet Draft      draft-ietf-l2tpext-mcast-02.txt         August 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: [email-masked]  

    
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 February 2003              [Page 16]

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: "BOURDON Gilles FTRD/DAC/ISS" <[email-masked]>
Date: Mon, 5 Aug 2002 18:21:14 +0200

Hi,

Thanks again for your comments, my questions/comments inline (GB:).

Gilles.

-----Message d'origine-----
De : W. Mark Townsley [mailto:[email-masked]]
Envoye : vendredi 2 aout 2002 16:33
A : BOURDON Gilles FTRD/DAC
Cc : [email-masked]
Objet : Comments on draft-ietf-l2tpext-mcast-02.txt

Bonjuor Gilles,

Thanks,

- Mark 

Category: Experimental

                        L2TP Multicast Extension 

Status of this Memo 

    

Abstract 

    
Table of Contents 

WMT Looks like some of your paragraphs have been merged (e.g. no space
between,
or fully concatenated) in the Intro and throughout the document.

GB: I double-checked the file and I didn't notice any editing/paging
issue in the document. Could you point one of these problems ?

1. Introduction 

   session. 

 

   scheme is. 

WMT Conjecture: In cases where the operator of the LAC and operator of
the LNS
are different corporate entities, it may be an interesting business
exchange as
to who should perform the replication here. Naturally, the LAC
performing this
makes more sense from an overall bandwidth usage perspective.
Replication isn't
free, so transferring this requirement from the LNS to the LAC is a
transfer of
capital investment requirement as well. I suppose these issues exist
with
cross-domain multicast in general though, and is something for the
bean-counters
to figure out....

GB: Yes, that is definitely true... and if replicating packets as close
as possible from the edge doesn't fit any business model, then we just
have to get rid off multicast in networks. In L2TP, that's one
motivation for the LAC to announce the multicast capability on a per
tunnel basis: the LAC operator can therefore control what it
allows/forbids depending on the LNS (on a contractual basis, using a
dedicated RADIUS tag signaling for instance).

<...snip...>

WMT But, if your Control Connection is serving an a box which can be an
LAC or
LNS, there may be more reason than just debugging. There is no protocol
restriction disallowing initiation of an L2TP session from either side
of a
Control Connection after it is established. e.g. Once a Control
Connection is
up, either side can be an LAC or an LNS (this isn't just an L2TPv3
thing, it
exists in L2TPv2 as well). This is arguably an edge case, and you can
get around
this by qualifying that your solution only covers the canonical LAC/LNS
case
where neither side may have a dual-personality on a single Control
Connection.
        
GB: I have to admit that is a case I never imagined so far. That is
another motivation to move from a OCRQ/RP/CN message exchange to a
multicast-specific one (MCRQ/RP/CN, as you suggested). I will change
that...

<...snip...>

 

    

       0                   1                   2                   3  

WMT If you are going to rely on acknowledgement of a message, you should
do so
with an explicit REQ/REP message structure. You should have to rely on
the
underlying control plane to have to provide an upcall when a specific
message is
delivered.

GB: I agree that using an explicit reply message will be more relevant,
especially for New Outgoing Session messages. I think withdrawals don't
need any acknowledgment, since we aim to stop the multicast traffic
ASAP. 

<...snip...>

    

WMT How do you handle sequencing of the merged traffic ("we don't" is
OK, but it
should be pointed out clearly somewhere)?

GB: As you noticed, I make it clearer in a specific section.

<...snip...>        
    
6.2.3. Priority 

WMT Is it a requirement for the LAC to be able to handle each of these
modes?
Or, can it simply ignore the message and do whatever it wants? 

GB: I don't think the priority message is a requirement for the LAC, it
just has to be treated as a preference expressed by the LNS. I will make
this more clear in the next release. This means that priority messages
should be ignored by the LAC if not supported (that is implicitly the
current behavior since M-bit must be 0).

WMT Also, if you do end up with a REQ/REP for the new/withdraw
operations, I
think the dynamic priority update message could still be its own single
message.
    
GB: Yes, as for withdrawals.

     by a threshold. 

      

       

WMT Hmm... If a wide variety of methods are allowed here, and the
teardown may
be initiated by the LAC or the LNS, then could you not end up in some
serious
thrashing? Perhaps you need some more MUSTs here, or have one side
always be the
decision-maker.

GB: The idea is to keep the decision process in the LNS only to bring up
or tear down the multicast session on  threshold crossing. The LAC could
also stop the session "de facto" by killing the multicast session, in
case of failure or configuration change for instance, but never when
crossing a threshold in any case. I will write this more explicitly.

7.1. Operations 

        
      Message Type  
      Result Code  
      Assigned Session ID  

           

WMT An "MCDN" could be your own message along with the MCRQ/MCRP
messages.
       
GB: Don't you think a CDN could suit to all Incoming/Outgoing/Multicast
calls, since a CDN doesn't carry any information on the session type ?

<...snip...>

WMT I suspect that the ability to setup a single session and cause
packet
replication and injection into L2TP multiple sessions could be an
interesting
platform for staging all sorts of attacks... This section might need a
little
more filling out to get by the IESG, though some of the issues are
probably
similar as those for Multicast in general (allowing you to reference or
borrow
text from there if possible).
            
GB: That a combined L2TP/Multicast security issue. The Control
Connection must first be hacked (and that is an RFC2661 security
problem), and thereafter individual terminals can be attacked using
multicast methods. I will add some references about multicast security.