Internet DRAFT - draft-elwin-l2tpext-ppvpn
draft-elwin-l2tpext-ppvpn
Elwin Stelzer
Internet Draft Naveen Gowda
Corona Networks, Inc.
November 2001
Expires: May 2002
L2TP Extensions for PPVPN
<draft-elwin-l2tpext-ppvpn-00.txt>
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]
