Network Working Group P.Rajinikanthan Internet-Draft R.Thirumurthy Expiration date: April,2005 Midas Communications Pvt Ltd. Timothy.A.Gonsalves IIT, Madras November 2004 Multipoint Connectivity With L2TP Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo talks about the problem that exist in the current L2TP network and the solution to that problem. In L2TP, internet link at LNS gets congested when two or more remote user starts communicating between them. This memo suggest multipoint capabality for L2TP, where LACs communicates between them and need not require LNS for every data packet. This draft also deals with the applications of multipoint L2TP in broadband networks. Rajini,Rtm,Tag Expires: April 2005 page[1] Internet-Draft Multipoint Connectivity With L2TP November 2004 Table of Contents 1. Introduction.................................................. 2 2. Specification of Requirements................................. 3 3. Terminology and Scope......................................... 3 4. Current L2TP Topology......................................... 3 4.1. Problem With Current Topology........................... 4 5. Multipoint Topology With L2TP................................. 5 5.1. Packet Flow In Multipoint L2TP.......................... 5 6. Comparing ML2TP with other Proposals.......................... 7 6.1 Types of L2 VPNs......................................... 7 6.2 Comparison Table......................................... 8 7. L2TP Extension For Multipoint Support......................... 9 7.1 Control Message Types.................................... 9 7.2 AVPs Applicable to Multipoint L2TP....................... 10 8. Control Connection States..................................... 12 9. ML2TP and IPsec............................................... 13 10. Applications Of ML2TP........................................ 14 10.1 ASP Model............................................... 14 10.2 Corporate Model......................................... 16 11. Security Considerations...................................... 16 12. IANA Considerations.......................................... 17 13. Acknowledgements............................................. 17 14. References 14.1 Normative References.................................... 17 14.2 Informative References.................................. 17 15. Author's Address............................................. 18 16. Full Copyright Statement..................................... 19 17. Appendix A - Example Network................................. 20 1. Introduction In the present era, it has become a common practice for employees to dial-in to their enterprise over the PSTN (Public Switched Telephone Network) and perform day-to-day operations just as they would if they were in corporate premises. This includes people who dial-in from their home and road warriors, who cannot be at corporate premises. L2TP [RFC2661] is a standard protocol used for providing the above mentioned service. Normally, an enterprise will have a single internet connection for local employees to access internet, email transaction and to allow their remote employees to enter into the home network. Enterprise's internet link get congested when two or more remote employees communicate between them. This may lead to delay in delivery of emails or accessing the internet from home network, in some situations this may even affect the enterprise's business. This draft talks about the L2TP extension to solve this problem by defining the necessary control messages required for creating logical mesh topology between LACs ( L2TP Access Concentrator ). Rajini,Rtm,Tag Expires: April 2005 page[2] Internet-Draft Multipoint Connectivity With L2TP November 2004 This memo also talks about the applications of this multipoint L2TP ( ML2TP ) in broadband networks and corporate networks to provide efficient service to the customers. Appendix A of this draft explains the topology of ML2TP enabled broadband network. 2. Specification of Requirements 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]. 3. Terminology and Scope Definition of terms used in this document may be found in one of (a) L2TP Protocol document [RFC2661], (b) L2TP Management Information Base document [RFC3371]. Note, while PPP ( Point to Point Protocol ) may be used to carry a variety of network layer packets, the focus of this document is limited to carrying IP datagrams only. Solution discussed in this document will not work when sequence number (Ns and Nr) is enabled for data packets. Normally sequence numbers are not enabled for data packets because the data sequence will be done by the higher layer protocols. 4. Current L2TP Topology The following diagram depicts a typical L2TP scenario. The goal is to establish the tunnel between the remote system and LNS located at home LAN. Remote System 1 (RS1) reaches the LNS through LAC 1 and Remote system 2 (RS2) reaches the LNS through LAC 2. [Home LAN] [LAC Client]----------+ | ____|_____ +--[Host] | | | [LAC1]--------| Internet |-----[LNS]-----+ | |__________| _____|_____ | | | | | PSTN | | [Remote]--| Cloud |-----[LAC2] [System] | | [1] |___________| | | [Remote] [System] [2] Figure 1: L2TP Network Topologgy Rajini,Rtm,Tag Expires: April 2005 page[3] Internet-Draft Multipoint Connectivity With L2TP November 2004 During data transfer from RS1 to RS2, the packet from RS1 reaches LNS through LAC1 and then it get forwarded to LAC2 by the LNS. LAC2 forwards the packet to RS2. 4.1. Problem With Current Topology The following depicts the packet flow in the current L2TP scenario. RemoteSystem1 (by short RS1) is connected with LAC1 and RemoteSystem2 (by short RS2) is connected with LAC2. Assume that both the LAC have established the tunnel with LNS and LNS has provided the IP address for the remote users. [Home LAN] +++-->[pkt1]-->+++++++++++++++++ | + __________ | |--[Host] + | | V | ++++[pkt]->[LAC1]--------| Internet |-----[LNS]-----| + | |__________| | | + _____|_____ | V + | | | [pkt2] + | PSTN | | + [Remote]--| Cloud |-------[LAC2]<--++++++++++ [System] | | + [1] |___________| + | + | + [Remote]<--++[pkt]+++ [System] [2] Figure 2: Packet Flow in L2TP Network When RS1 sends a packet ('pkt' as in diagram) to RS2, it will reach LAC1. LAC1 adds the tunnel header and sends the packet (pkt1) to LNS. when packet (pkt1) is received at LNS, LNS modifies the tunnel header for LAC2 and forwards the packet (pkt2) to LAC2. Now the packet (pkt2) reaches LAC2 and LAC2 removes the tunnel header from the packet and sends the original packet (pkt) to RS2. Timing diagram for this packet flow is shown is below. RS1 LAC1 LNS LAC2 RS2 | | | | | |------->| | | | | pkt |-------->| | | | | pkt1 |-------->| | | | | pkt2 |------->| | | | | pkt | Figure 3: Timing diagram for packet flow in L2TP Rajini,Rtm,Tag Expires: April 2005 page[4] Internet-Draft Multipoint Connectivity With L2TP November 2004 If we look deeply into the packet flow, we can see that internet link at LNS get congested for all the packets transfer between the remote systems. This should be avoided but not possible in the current topology. Next section deals with the changes in L2TP that is required to alleviate this problem. 5. Multipoint Topology With L2TP L2TP components LAC and LNS remains the same and their roles and responsibilities are not changed. Instead, LAC and LNS are added with few functionalities. LNS is required to update the LACs of the same domain with the routing entry it has for that domain. LACs which supports this technology SHOULD accept the routes sent by the LNS other LACs should discard it. LNS implemented this feature MUST support the existing topology i.e. it SHOULD forward the packet received from one LAC to other. Creating Logical Mesh Topology After the session establishment, LNS updates the LAC with the forwarding information it has. This includes the LAC IP, LAC PORT, LAC TID, LAC SID, USER IP ADDRESS, USER IP MASK and LNS PORT. With these information LAC constructs the forwarding table for that domain. Domain MAY be identified by the tunnel id in the received L2TP packet. LNS also updates the other LACs with the information of newly added Session. This creates the logical mesh among all the LACs and LNS of the particular domain. This logical connection enables the multipoint packet transaction between LACs. Similarly, when the LAC terminates the session with LNS, LNS should update all LACs in the domain with the deletion of this entry from the forwarding table. LAC SHOULD clear the forwarding table when it closes all the sessions for the domain with the LNS. 5.1. Packet Flow In Multipoint L2TP Packet flow in multipoint L2TP topology is in the diagram given below. As discussed earlier, RS1 is connected with LAC1 and RS2 is connected with LAC2 and both the LACs are established the tunnel with LNS. At this point of multipoint L2TP environment, LACs will have a entry in forwarding table for all the LACs connected in the domain. Rajini,Rtm,Tag Expires: April 2005 page[5] Internet-Draft Multipoint Connectivity With L2TP November 2004 +++-->[pkt2]-->+++++++ [Home LAN] + | | + | | + ________V_ |--[Host] + | | + ++++[pkt]->[LAC1]--------| Internet |-----[LNS]-----+ + | |__________| | + _____|_____ | | + | | | V + | PSTN | | [pkt2] [Remote]--| Cloud | | + [System] | | | + [1] |___________|-------[LAC2]<-+ | + | + [Remote]<--++[pkt]+++ [System] [2] Figure 4: Packet Flow in Multipoint L2TP Now, when RS1 sends the packet (pkt) to RS2, it reaches the LAC1. LAC1 SHOULD do a forwarding lookup with information in the received packet (pkt). A new packet (pkt2) is generated by the LAC1 with the information found in forwarding table and the generated packet is sent out. Packet (pkt2) reaches the LAC2 directly from LAC1, LAC2 removes the tunnel header from the received packet (pkt2) and the original packet (pkt) is sent to RS2. Note that, in multipoint L2TP topology , packet (pkt2) generated at LAC1 is the packet generated at LNS in the normal L2TP toplogy (Refer Figure 2). Under this scenario, data packets will be sent to LNS only when remote syetems (RSx) communicates with the host connected at LNS or when the LAC does not support multipoint L2TP. Timing diagram for the packet flow in ML2TP is given below. RS1 LAC1 LAC2 RS2 | | | | |------->| | | | pkt |------------------>| pkt | | | pkt2 |------->| | | | | | | | | Figure 5: Timing diagram for packet flow in ML2TP Rajini,Rtm,Tag Expires: April 2005 page[6] Internet-Draft Multipoint Connectivity With L2TP November 2004 6. Comparing ML2TP with other Proposals ML2TP enables L2TP to create mesh L2 VPN, it is necessary to look into the operation of existing L2 VPNs and to compare those proposals with ML2TP. 6.1 Types of L2 VPNs MPLS-based L2 VPNs ATM or Frame Relay VCs ( Virtual Circuits ) are used between the PE ( Provider Equipment ) and CE ( Customer Equipment )devices and to cross-connect each of these to seperate MPLS circuit ( Lable Switched Paths or LSPs ) through the provider network. Since LSPs are unidirectional, and so two LSPs are required for each bi-directional connection. This is shown in the following figure. ________ ______ LSP | | | | +------->| PE2 |======| CE2 | | |________| |______| | ______ ___V____ | | VC | | LSP | CE1 |=====| PE1 |<------+ |______| |________| | | ___V____ ______ | | | | | PE3 |======| CE3 | |________| |______| Figure 6: MPLS Based L2VPN This is a straightforward approach, and it does not scale well in the provider network for the following reasons. Firstly, each LSP through the provider network needs to be configured individually and then cross-connected to the specified VC at each end, which requires considerable management effort from the service provider. Secondly, a large number of LSPs may be needed in the provider network, which uses large amounts of resource in the service provider's routers. This also requires additional state in the intermediate provider devices. Rajini,Rtm,Tag Expires: April 2005 page[7] Internet-Draft Multipoint Connectivity With L2TP November 2004 Martini L2 VPNs An improvement to the above approach is to use Martini extensions to MPLS. Martini improves scalability by using a fixed number of MPLS LSPs between PE devices in the provider network. Emulated, point-to-point layer 2 connections are then created between pairs of PE devices by tunneling through such an LSP. Therefore, an alternative to the MPLS based VPNs described above is to cross- connect layer 2 PE-CE connections with martini pseudo-wires using the appropriate layer 2 encapsulation. Martini pseudo-wire only consumes resources in the PE devices. Although this reduces the amount of resource consumed in the provider routers, this approach still requires too much management effort to create large scale VPNs, because each pseudo-wire needs to be configured individually. Kompella L2VPNs One of the important features of this solution is that the configuration and management required in the provider network is much simpler than that for leased lines or the MPLS and martini solutions mentioned above. It uses BGP ( Border Gateway Protocol ) as an auto-discovery protocol and a signalling protocol. This require PE devices to maintain local and remote labels to connect the CE to other CEs in the group. Kompella requires Firtsly, Unique identifier is associated with each CE in the group. Secondly, Provider must setup tunnels between the PE routers thereby avoiding additional occupancy in the provider devices. 6.2 Comparison Table Since the Multipoint-L2TP supports mesh VPN network, it is necessary to compare it with other L2VPN technologies. The Comparison table is given below. Rajini,Rtm,Tag Expires: April 2005 page[8] Internet-Draft Multipoint Connectivity With L2TP November 2004 MPLS Based Martini Kompella ML2TP -------------------------------------------------------------------- Manual Manual Automatic Auto Configurations Configurations Configurtion Configuration Uses BGP Uses only L2TP Requires MPLS Requires MPLS Requires MPLS Requires network network network Existing IP network Requires Requires Requires Does not provider support provider support Provider support require provider support Intermediate Only PE devices Only PE devices Only CE devices provider devices require require knowledge require requires knowledge about about VPN knowlegde about knowledge about VPN VPN VPN - - - Supports firewall to restrict user communication within the group 7. L2TP Extension For Multipoint Support Some of the new AVPs are added as a part of L2TP to support multipoint capability. This document defines a new control message type and AVPs for Multipoint L2TP. 7.1 Control Message Types Control Connection Management Value To be defined (ML2TP) Multipoint L2TP information by IANA Message type AVP SHOULD carry ML2TP in Attribute Value field of AVPs when delivering the multipoint route information to LACs. This Message Type AVP SHOULD be the first AVP [RFC2661] in the control packet. M bit of this AVP MUST be set to 0. This makes the LAC to discard the packet if it does not support this feature. This AVP may be hidden (the H-bit is 1). The Length of this AVP is 8. These AVPs are global to tunnel so the session id should be 0 in the control packets. Rajini,Rtm,Tag Expires: April 2005 page[9] Internet-Draft Multipoint Connectivity With L2TP November 2004 7.2 AVPs Applicable to Multipoint L2TP Add Route ( ML2TP ) The Add Route AVP, Attribute Type is 1 and it is used to inform currently active LAC and their routing information. These AVPs are global to tunnel so the session id should be 0 in the control packets. First two Attribute Value fields are set to 0 ( Reserved ). This can be used in feature advancement and to align the IP address in the AVP to 32 bit boundary. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Tunnel ID | Peer Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer LAC IP / LNS IP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LAC UDP Port | LNS UDP Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User IP Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tunnel ID in the L2TP header identifies to which tunnel these information is to be added in LAC. User IP address, and User Mask, LAC IP and others form an entry in the forwarding table. Peer Session ID and Peer Tunnel ID are used for sending the packets to corresponding LAC. LNS IP is used when the user is behind the LNS. Default gateway SHOULD be added in the forwarding table with LNS IP as a gateway. This allows LAC to send the packets to LNS if user tries to access Internet or Invalid address. Length of this AVP varies depends up on the number of entries. Delete Route ( ML2TP ) The Delete Route AVP, Attribute Type is 2 and it is used to delete the given route from forwarding table of LAC. These AVPs are global to tunnel so the session id should be 0 in control packet. First two Attribute Value fields are set to 0 ( Reserved ). This can be used in feature advancement and to align the IP address in the AVP to 32 bit boundary. The Attribute Value field for this AVP has the following format: Rajini,Rtm,Tag Expires: April 2005 page[10] Internet-Draft Multipoint Connectivity With L2TP November 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer LAC IP / LNS IP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tunnel ID in the L2TP header indicates for whom the route is to be deleted in LAC. Entry to be deleted from forwarding table is specified with LAC IP and User IP. Length of this AVP varies depends up on the number of entries. Default gateway can be deleted by the LAC when it closes all the sessions (for the particular domain) with LNS. Add FireWall Rule ( ML2TP ) Add FireWall Rule AVP, Attribute Type is 3 and it is used to inform currently active firewall rules for the domain. These AVPs are global to tunnel so the session id should be 0 in the control packets. First two Attribute Value fields are set to 0 ( Reserved ). This can be used in feature advancement and to align the IP address in the AVP to 32 bit boundary. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Type | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | Rule Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP is used by LNS when session is established from LAC. This AVP has firewall rules with source IP as the IP address assigned to this session. Rajini,Rtm,Tag Expires: April 2005 page[11] Internet-Draft Multipoint Connectivity With L2TP November 2004 Session ID and Tunnel ID fields indicates for whom (domain) the rule is to be added in LAC. Any of the field is set to 0 then the corresponding field is treated as ANY. Value of Action field can be ACCEPT (1) or DENY (2). Rule index specifies the index for the given rule in the firewall table. Length of this AVP varies depends up on the number of entries. Delete FireWall Rule ( ML2TP ) The Delete FireWall Rule AVP, Attribute Type is 4 and it is used to delete the firewall rules for the domain. These AVPs are global to tunnel so the session id should be 0 in the control packets. First two Attribute Value fields are set to 0 ( Reserved ). This can be used in feature advancement and to align the AVP to 32 bit boundary. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rule Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Session ID and Tunnel ID fields indicates for whom (domain) the rule is to be deleted from LAC. Rule index specifies the index for the rule to be deleted from the firewall table. Length of this AVP varies depends up on the number of entries. 8. Control Connection States The control connection protocol of L2TP is not modified by ML2TP. Instead, new AVPs are sent by LNS to LACs after the established state of connection ( session ). These AVP's are sent whenever LAC is added to LNS or LAC leaves the LNS. LNS which supports ML2TP should send ADD_ROUTE AVP with current forwarding information to the newly added LAC and also update other active LACs in the group with the information of new LAC. Similarly, when LAC closes connection with LNS, LNS should update all other active LACs in the group with DELETE_ROUTE AVP. LAC MUST discard these AVPs if it does not support ML2TP. Timing diagram is shown below. Rajini,Rtm,Tag Expires: April 2005 page[12] Internet-Draft Multipoint Connectivity With L2TP November 2004 Connection Establishment Newly added LNS LAC | | established | |established | ADD_ROUTE AVP | |------------------------------>| | | | | | ADD_FIREWALL AVP | |------------------------------>| | (if rules exist) | | | | | Connection Termination Active LNS LACs | | established | |established | DELETE_ROUTE AVP | |------------------------------>| | | | | | | Figure 7: Timing Diagram for Connection Establishment and Termination 9. ML2TP and IPsec IPsec provides packet-level security via ESP and/or AH. All L2TP control and data packets for a particular tunnel appear as homogeneous UDP/IP data packets to the IPsec system. In case of L2TP [RFC2661], IPSec encryption and authentication rules are defined at LNS and LAC. Here Packet transmissions across LACs wont be a problem, because the packets from LAC reaches LNS and LNS performs IPsec operation on the received packet depends up on the configuration in destined LAC. In ML2TP, LACs in the domain can communicate with each other so it is necessary for the LAC's should know the IPsec rules. Packet can be sent as normal if IPsec is not enabled in the destined LAC. LACs that shares the same domain SHOULD have same IPsec rules. Rajini,Rtm,Tag Expires: April 2005 page[13] Internet-Draft Multipoint Connectivity With L2TP November 2004 10. Applications Of ML2TP ML2TP can be used in broadband networks to offer better services to customers through ASPs ( Application Service Provider ) and in enterprises environment. 10.1 ASP Model Few applications of ML2TP in ASP environment are discussed below. Online Multiplayer Gaming Increase in usage of broadband networks gives way for the growth of entertainment applications in the internet. One of the most specific application is online multiplayer gaming. This allows user to play game with others in the internet. These applications are provided by ASPs. Customers login to the ASP network and chooses the game to play. Accounting is done on the duration of time that customer is accessing the services from ASP. Currently, ASP networks should have more bandwidth to support more customers to play online which is more costly. This can be avoided by using ML2TP where L2TP connections are established with the customers when they login to the ASP network. ML2TP allows customers to interact without the knowledge of ASP. With ML2TP ASP network is not over loaded with customers traffic so ASP can have internet connection with optimum bandwidth. Network of this application is discussed in detail in Appendix A. Video On Demand A pay-per-view television service in which a viewer can order a program from a menu and have it delivered instantly to the television set, typically with the ability to pause, rewind, etc. Customer access this sevice through ASP and ASP charges customer depends upon the program he choose. This service also suffers in lack of bandwidth in ASP network if customers are more. ML2TP can be used to solve the bandwidth issue that exist in the ASP network. Solution is similar to application we discussed earlier ( Online Multiplayer Gaming ). The network architecture is given below. Rajini,Rtm,Tag Expires: April 2005 page[14] Internet-Draft Multipoint Connectivity With L2TP November 2004 ++++++++++++++++ + + L2TP _____+____ | + tunnel | CP | | ___+______ | With LAC | | | ASP | |__________| | | With LNS | | | |__________| | | | + | | + | | ++++++++++++++++ | _____|____ + | | | + | -------| Internet |----------[Customer] LAC Client |__________| Login [PC ] into ASP Figure 8: VoD In ML2TP Network In this figure, it is shown that ASP has a LNS which has L2TP connection with CP ( Content Provider ). When customer needs a video he or she should establish a L2TP connection with ASP where ASP authenticates the customer and allow him to choose the program from CP. During the L2TP connection establishment LNS transfers tunnel information of CP to customer's LAC. This makes the customer's LAC to interact directly with LAC at CP and access the program diectly without the support of ASP bandwidth. Audio On Demand / Content On Demand These applications are similar to video on demand ( VoD ) as discussed previously. Voice over IP In this application, customer login to the ASP and dials the telephone number he wish to reach. Soft switch in the ASP connects the customer to other end through VoIP gateway, which allows both the ends to talk as in telephone line. Here ML2TP can be used when both the ends has IP phones and they are connected with the gateway under the same ASP. Logical mesh using ML2TP is created between both the ends of the connection. Voice traffic of the customer will not affect network bandwidth of the ASP. Rajini,Rtm,Tag Expires: April 2005 page[15] Internet-Draft Multipoint Connectivity With L2TP November 2004 Video Conferencing Similarly, video conferencing is also one of the application get benefited by the ML2TP. Apart from ML2TP support in LAC, LAC should also capable of handling multicast packet and sending it to local users in the LAC when more then one user joined in the same multicasting group. File and Peripheral Sharing This is also a another application where ML2TP can be used. Logical mesh using ML2TP is created between the file servers/ pherperals and the customers accessing it. 10.2 Corporate Model This is one of the area where ML2TP can be used to provide solution to save the network bandwidth of the corporate. Network topology of ML2TP in corporate model looks similar to Figure 4 discussed in section 5.1. This topology allows two remote users of corporate network to communicate without the knowledge of LNS at home LAN. But this is not the only requirement for corporate, apart from this they also require some restrictions to be provided between the users (say employees in accounts should not access employees in R & D). These types of restrictions are possible in L2TP by using firewalls in LNS. But in case of ML2TP, LACs communicates between them so they should aware of firewall rules to forward the packet. These rules are communicated to LACs from LNS using AVPs, these AVPs are explained in section 7.2. When LAC receives the packet from user it should check the firewall rules. If the rule is deny the packet is dropped at LAC itself. If the rule is accept then the packet is sent to corresponding LAC. 11. Security Considerations Since LAC is forwarding the packet to other point of network it is recommended to perform the tunnel authentication between LAC and LNS. AVP's introduced in this document can send as hidden AVP's ( H bit ) from LNS to LAC. Basic security issues are discussed in the base L2TP specification [RFC 2661] MUST be considered. Rajini,Rtm,Tag Expires: April 2005 page[16] Internet-Draft Multipoint Connectivity With L2TP November 2004 12. IANA Considerations This document reqiures one new L2TP "Message Type" number to be assigned by IANA Section 7.1., ML2TP Multipoint L2TP information Values for four new "AVP Attributes" to be assigned by IANA: Section 7.2., Add Route AVP Section 7.2., Delete Route AVP Section 7.2., Add FireWall Rule AVP Section 7.2., Delete FireWall Rule AVP 13. Acknowledgements Anjaneya Sharma BabuGanesh Balamurugan Jai chitra Kalyan Chakravarthy Priya RajKumar Ramesh Midas Communications Ltd. provided invaluable help in reviewing this document and its implementation. 14. References 14.1 Normative References [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Peter, "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999. 14.2 Informative References [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Rajini,Rtm,Tag Expires: April 2005 page[17] Internet-Draft Multipoint Connectivity With L2TP November 2004 15. Author's Address P.RajiniKanthan Midas Communications Technologies Pvt Ltd 403, 8th floor, Guna complex AnnaSalai Chennai-600 018, TamilNadu INDIA Ph: +91 44 24352078 Email: rajini@banyannetworks.com Rajini,Rtm,Tag Expires: April 2005 page[18] Internet-Draft Multipoint Connectivity With L2TP November 2004 16. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and 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 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Rajini,Rtm,Tag Expires: April 2005 page[19] Internet-Draft Multipoint Connectivity With L2TP November 2004 17. Appendix A - Example Network Using ML2TP In this section we discuss a network topology required for online multiplayer gaming in ASP environment using ML2TP. In the previous discussion we have described about the changes reqiured in the current ASP environment to support online multiplayer gaming efficiently to more customers. The figure shown below is such a network established with the support of ML2TP. ++++++++++++++++++++++++++++++++ LAC _____________________________+_______ +Client | _________ _________ + L2TP | +---------[Customer] ||Game | |Game | + Tunnel| | [1 # ] ||Server 1 | |Server 2 |++++++ | ____|___ # ||_________| |_________| ___+____ | | | ML2TP # | | | | | | |Internet| Logical# | ----------------------| LNS |--|---| | Mesh # | __|______ Home LAN |________| | |________| # | |RADIUS | + | | # | |Server | + | | # | |_________| + | +---------[Customer] | + | [2 + ] | + | + LAC | ++++++++++++++++++++++++++++++++Client | | | ASP | | NETWORK | |_____________________________________| Figure 9: Online Multiplayer Gaming In ML2TP Network There are two customers connected with ASP to access games from the game server. When they are authenticated by the ASP, LNS in the ASP transfers the tunnel information to the LACs in the customer pc which creates logical mesh. Now both the users can play the game without using bandwidth of ASP network. RADIUS in ASP is used to perform authentication and accounting of the customers. Authentication is performed during the L2TP session establishment between ASP and the customer. Rajini,Rtm,Tag Expires: April 2005 page[20]