Elwin Stelzer Internet Draft Naveen Gowda Corona Networks, Inc. November 2001 Expires: May 2002 L2TP Extensions for PPVPN 1.0 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. 2.0 Abstract Provider Provisioned VPNs (PPVPNs) need a tunneling mechanism and a means to automatically discover VPN membership and signal these tunnels. This draft elaborates the use of L2TP as the tunneling mechanism, and defines extensions to L2TP to handle VPN membership discovery to leverage PPVPNs. Additional AVPs are defined, and their behaviour are explained. The solution presented here is applicable for both L3 VPNs and L2 VPNs. Elwin & Naveen [Page 1] draft-elwin-l2tpext-ppvpn-00 L2TP PPVPN Extn. Nov 2001 3.0 Table of Contents 1.0 Status of this Memo ................................. 1 2.0 Abstract ............................................ 1 3.0 Table of Contents ................................... 2 4.0 Introduction ........................................ 2 4.1 Terminology ......................................... 2 4.2 Overview of operations .............................. 3 4.3 Reference Case ...................................... 3 5.0 Control Tunnel ...................................... 4 5.1 Overview ............................................ 4 5.2 PPVPN-Control AVP ................................... 4 5.3 VPN-List AVP ........................................ 5 6.0 PerVPN tunnel ....................................... 6 7.0 IANA Considerations ................................. 7 8.0 Security Considerations ............................. 7 9.0 Intellectual Property Considerations ................ 7 10.0 References .......................................... 7 11.0 Authors' Addresses .................................. 8 4.0 Introduction 4.1 Terminology This draft uses the terms defined in [PPVPN-RQ] and [PPVPN-FW], and defines the following new terms. Control Tunnel - A tunnel or connection between two PE routers that controls the PerVPN tunnels in it. P Router - Provider core router. PE Router - Provider Edge router. PerVPN tunnel - A tunnel between a local VPN VFI and a remote VPN VFI. This tunnel setup is triggered through the Control tunnel. Virtual Tunnel Interface (VTI) - An interface created to represent a PerVPN tunnel. A VPN VFI may forward packet to this interface that can tunnel-encapsulate the packet and send it out. A VTI can also participate as interface in routing protocols like OSPF. VPN VFI - A Virtual Forwarding Instance meant for VPNs. This is also loosely referred as VRF or simply VR. Elwin & Naveen [Page 2] draft-elwin-l2tpext-ppvpn-00 L2TP PPVPN Extn. Nov 2001 4.2 Overview of operations Each PE knows its peers through configuration or any other means. When a PE router comes up, it establishes a Control Tunnel with each of its peers. The list of VPNs that each PE supports are informed to their peers using L2TP Hello messages, and any new VPNs getting added or being removed are informed to other PEs in a similar way. This VPN list in the Hello message that comes in the control tunnel triggers the establishment and tearing down of PerVPN tunnels. There is a PerVPN tunnel across each pair of VPN VFIs. Each PerVPN tunnel also has a corresponding VTI that participates in the VPN routing functions. 4.3 Reference Case The operation of the protocol extensions are illustrated with the reference example shown below. (V1, V3)...........................(V1, V2) PE1 ---------------------------- PE2 .| \. ./ |. .| \. ./ |. .| \. ./ |. .| \. ./ |. .| \. ./ |. .| \. ./ |. .| \. ./ |. .| .\. |. .| ./ \. |. .| ./ \. |. .| ./ \. |. .| ./ \. |. .| ./ \. |. .| ./ \. |. .| ./ \. |. PE4 ---------------------------- PE3 (V2, V3) (V1) Figure 4.1 Reference Case Here V1, V2 and V3 are three VPNs considered, and PE1, PE2, PE3 and PE4 are four PE routers. The intermediate P routers are not shown. The lines shown above represent Control tunnels. Elwin & Naveen [Page 3] draft-elwin-l2tpext-ppvpn-00 L2TP PPVPN Extn. Nov 2001 Consider a scenario in which the routers PE1, PE2 and PE3 are up and operational, and the router PE4 is started. First PE4 establishes control tunnel connection with each of the other PEs. And PE4 will indicate to all other PEs that V2 and V3 are the list of VPNs it supports. Seeing this, PE1 and PE2 initiates PerVPN tunnel setup with PE4, and corresponding PerVPN tunnels are setup. Note that PE3 does not initiate a PerVPN tunnel setup, since there are no VPN VFIs in PE3 for the VPNs V2 and V3. The '.' shown in the figure above represent PerVPN tunnels. 5.0 Control Tunnel 5.1 Overview Control Tunnels are created to discover the VPN VFIs on the other PEs using VPN-List AVP. Each VPN VFI in the PE will have its own unique VPN-ID [VPN-ID]. Control Tunnel remains always UP through Hello packet exchange. If a Control Tunnel to one PE goes down due to some failure then all the PerVPN tunnels to that PE will be cleared. Control Tunnel will follow LNS-LNS Reference model defined in [L2TP-V3]. The solution presented here could as well be done with L2TPv2 [L2TP-V2]. Once Control Tunnel is created, it MUST NOT accept any Call Management Messages and any Error Reporting Messages. It MUST only accept Control Connection Management messages during the life of the tunnel. Control Tunnels are differentiated from other Tunnels in the system by exchanging the PPVPN-Control AVP. Once the Control Tunnel moves into established state, both the peer can start advertising their VPN VFIs through Hello packets. Hello packets will be sent over the Control Tunnel either when the hello timer expires or when VPN VFI comes UP or goes DOWN in any of the PEs. Hence Hello packets in Control Tunnel serves three purposes: i) to findout whether the peer is DEAD or ALIVE, ii) to update the Peer with VPN List, and iii) to act as a trigger for PerVPN tunnel when a VPN VFI comes UP. 5.2 PPVPN-Control AVP This AVP is sent to the peer to inform about creation of PPVPN Control tunnel. This AVP MUST be present in SCCRQ and SCCRP to support L2TP extensions for PPVPN. The initiator of Control Tunnel will send this AVP in SCCRQ with M-bit set. Upon receiving SCCRQ, the peer MUST send StopCCN if it doesn't support PPVPN extension, or MUST reply with SCCRP. If the initiator gets StopCCN then it MUST not attempt to create Control Tunnel with the same peer. If the initiator recevies SCCRP, then it can send SCCCN to get the Control Tunnel to Established State. Elwin & Naveen [Page 4] draft-elwin-l2tpext-ppvpn-00 L2TP PPVPN Extn. Nov 2001 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| rsvd | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP MAY be hidden (the H-bit set to 0 or 1) and is mandatory (M-bit set). The length (before hiding) of this AVP is 8. Vendor ID is a two octet value, set to 3961 to indicate that this is a Corona-assigned attribute. Should this draft become a standard, the Vendor ID would become 0 and an appropriate Attribute-Type value will be assigned by IANA. 5.3 VPN-List AVP This AVP MUST be sent only in the Hello packets. The VPN-List acts as a trigger to initiate PerVPN tunnels. When a Control Tunnel comes up, it sends a Hello packet with the list of VPN IDs it supports. When the peer receives the Hello packet, it checks the received VPN List with its local VPN list and then initiates PerVPN tunnels to each of the VPN VFI pair. As soon as Control Tunnel is created only the initiator of Control Tunnel MUST transmit the first Hello packet containing the VPN-List. Afterwards if any VPN VFI comes UP or goes DOWN, then only that information must be sent to the peer as delta. The peer MUST update its database after receiving Hello packet and clear PerVPN tunnels for those VPN VFIs that went down and trigger PerVPN tunnel for those VPN VFIs that came UP. 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| rsvd | Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Num of VPN IDs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Elwin & Naveen [Page 5] draft-elwin-l2tpext-ppvpn-00 L2TP PPVPN Extn. Nov 2001 Optional Data formats: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN-ID 1 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Status-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN-ID 2 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Status-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M bit MUST be set to 1 and this AVP can be hidden (H-bit set 0 or 1). Length (before hiding) 8 + Optional Data Length. Optional Data length will be 8 * Num of VPN Ids. Vendor ID is a two octet value, set to 3961 to indicate that this is a Corona-assigned attribute. Should this draft become a standard, the Vendor ID would become 0 and an appropriate Attribute-Type value will be assigned by IANA. VPN-ID is 7-octet number corresponding to each VPN VFIs. Status is 1-octet in size and it indicates the status of VPN VFI, 0 means DOWN and 1 means UP. 6.0 PerVPN tunnel PerVPN tunnels are individual tunnels created for each VPN. PerVPN tunnel can transport IP traffic or other Layer-2 traffic over the sessions created within the tunnel. Unlike Control tunnels PerVPN tunnels are regular L2TP tunnels. Note that a PerVPN tunnel has the same IP endpoints as that of the Control tunnel. Sessions within PerVPN tunnel are created using Incoming Call Management Messages. NOTE: If two PEs want to create regular L2TP Tunnel along with Control and PerVPN tunnel, then a seperate Tunnel must be created between same two endpoints. Elwin & Naveen [Page 6] draft-elwin-l2tpext-ppvpn-00 L2TP PPVPN Extn. Nov 2001 7.0 IANA Considerations Should this document advance on as standards track official attribute values need to be assigned for the PPVPN-Control AVP, and VPN-List AVP. 8.0 Security Considerations This document does not introduce any new security issues beyond those inherent in L2TP, and may use the same mechanisms proposed for those technologies, where applicable. 9.0 Intellectual Property Considerations Corona Networks may seek patent or other intellectual property protection for some or all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Corona Networks, Corona intends to disclose those patents and license them on reasonable and non-discriminatory terms. 10.0 References [L2TP-V2] M. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661, August 1999. [L2TP-V3] J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret, G. Singh Pall, A. Rubens, B. Palter, "Layer Two Tunneling Protocol(L2TP)", Work in progress, July 2001 [L2TP-SU] Naveen Gowda, Elwin Stelzer, Umesh Sirsiwal, "L2TP Session Update Mechanism", draft-naveen-l2tpext-sessupdate-00.txt, Work in progress, June 2001 [PPVPN-RQ] M. Carugi et al, "Service Requirements for Provider Provisioned Virtual Private Networks", Work in progress, draft-ietf-ppvpn-requirements-01.txt, Jun 2001 [PPVPN-FW] R. Callon et al, "A Framework for Provider Provisioned Virtual Private Networks", Work in progress, draft-ietf-ppvpn-framework-00.txt, Feb 2001. [VPN-ID] B. Fox, B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, Sep 1999. Elwin & Naveen [Page 7] draft-elwin-l2tpext-ppvpn-00 L2TP PPVPN Extn. Nov 2001 11.0 Authors' Addresses Elwin Stelzer Eliazer Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 Email: elwinietf@yahoo.com Naveen PN Gowda Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 Email: naveenietf@yahoo.com Elwin & Naveen [Page 8]