Internet DRAFT - draft-elwin-ppvpn-vtp
draft-elwin-ppvpn-vtp
Network Working Group Elwin Stelzer
INTERNET DRAFT Corona Networks, Inc.
July 2001
Expires: Jan 2002
VPN Tunneling Protocol
<draft-elwin-ppvpn-vtp-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
This draft describes a VPN Tunnel encapsulation shim header (VTE) to be
used in VPN tunnels and also defines a simple tunnel signaling protocol,
called VPN Tunneling Protocol (VTP). It provides a simple mechanism for
carrying VPN traffic over provider backbone. The protocol is expected to
be run at each of the PE routers in the provider backbone. Remote access
nodes can also join the VPN using this protocol.
3.0 Table of Contents
1.0 Status of this Memo ..................................... 1
2.0 Abstract ................................................ 1
3.0 Table of Contents ....................................... 1
4.0 Introduction ............................................ 2
4.1 Terminology ............................................. 2
4.2 Specification of Requirements ........................... 2
4.3 Comparison with other approaches ........................ 2
5.0 VTP Overview ............................................ 2
5.1 VTE ..................................................... 3
Elwin [Page 1]
draft-elwin-ppvpn-vtp-00.txt VPN Tunneling Protocol July 2001
5.2 VTP Signaling ........................................... 3
6.0 VTP ..................................................... 4
6.1 VTP protocol header format .............................. 4
6.2 AVPs .................................................... 5
6.3 VTP State Machine ....................................... 7
7.0 Protocol Operation ...................................... 9
7.1 Control connection operation ............................ 9
7.2 Datapath Operation ...................................... 9
7.3 VPN Route Exchanges ..................................... 10
8.0 Multipoint Tunnels ...................................... 10
9.0 IANA Considerations ..................................... 10
10.0 Security Considerations ................................. 10
11.0 Summary and Conclusions ................................. 10
12.0 Acknowledgments ......................................... 10
13.0 References .............................................. 10
14.0 Author's Address ........................................ 11
APPENDIX A: Summary for Sub-IP Area .......................... 11
4.0 Introduction
4.1 Terminology
This draft uses the terms defined in [PPVPN-RQ] and [PPVPN-FW], and
defines the following new terms.
TVI - Tunnel Virtual Interface
VTE - VPN Tunnel Encapsulation
VTP - VPN Tunneling Protocol
4.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].
4.3 Comparison with other approaches
TBD
5.0 VTP Overview
VTP has two components:
- VTE (VPN Tunnel Encapsulation): header used in datapath
Elwin [Page 2]
draft-elwin-ppvpn-vtp-00.txt VPN Tunneling Protocol July 2001
- VTP Signaling
5.1 VTE
The VTE encapsulation is over IP, and the IP protocol field uses the
protocol-type value TBD to indicate this. This shim header is used to
identify VPNs and other tunnel parameters.
This is a 16 octet header and is formatted as shown in Fig 6.1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Reserved (0) | VPN_ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... VPN_ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... VPN_ID | PayloadProtocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TunnelTag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.1 VTE Format
Where:
Ver = 0001, for this format of VRTE
Reserved = all bits 0, till more extensions are added
VPN_ID = the 7 octet VPN ID, corresponding to the VPN traffic
being tunneled. Refer [RFC 2685].
PayloadProtocol = protocol corresponding to the payload. Mostly
it is expected to be IP.
TunnelTag = a 4 octet value for additional tagging.
Special keepalive packets can also be sent with this encapsulation to
check the data-path tunnel operational status.
5.2 VTP Signaling
A VTP session is established between each pair of participating PEs.
Each PE router, when it becomes operational, learns all the VPNs
existing in each of the PE peers. The VpnInfo message is used for this
Elwin [Page 3]
draft-elwin-ppvpn-vtp-00.txt VPN Tunneling Protocol July 2001
purpose. The message is sent with the list of VPNs a PE router supports,
and it also has a request flag, that denotes if the peers needs to
respond with VpnInfo message. VpnInfo is also sent to other PEs when a
new VPN is enabled in a PE router. This delta information is conveyed
using another flag in the VpnInfo message.
Once the VPN information is obtained about the peers, the PE router
initiates the establishment of VTP tunnels. With the tunnel being
established, packets in the datapath are encapsulated with VTE.
The VTP runs on top of TCP, and listens to the port-number TBD.
The relationship between VTP, VTE and other modules are shown in
Fig 5.2.
+--------+ +--------------+
! ! ! Application !
! VTP ! ! Process !
! ! !--------------!
+--------+ ! Appl Protocol!
^ ^ +--------------+
! ! ^
! ! !
! ! !
!----------------! ! !
! ! !
! v v
! +---------------------------------------------+
! ! Socket Layer !
! !---------------------------------------------!
v ! Transport Protocol (TCP / UDP) !
+----------+ !---------------------------------------------!
! VTE ! <----> ! IP !
! ! !---------------------------------------------!
+----------+ ! Link Layer Protocol !
+---------------------------------------------+
Figure 5.2 VTP Relationships
6.0 Protocol Specification
6.1 VTP protocol header format
Each VTP PDU is a VTP header followed by a VTP messages.
Elwin [Page 4]
draft-elwin-ppvpn-vtp-00.txt VPN Tunneling Protocol July 2001
The VTP header is a 12 octet value and is shown in Fig 6.1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Reserved (0) | VPN_ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... VPN_ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... VPN_ID | PDU_Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageCode | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6.1 VTP Header
Where:
Ver = 0001, for this format of VTE
Reserved = all bits 0, till more extensions are added
VPN_ID = the 7 octet VPN ID, corresponding to the VPN traffic
being tunneled. Refer [RFC 2685].
PDU_Len = Two octet integer specifying the total length of this PDU
in octets starting from version field.
MessageCode = This identifies what message is carried in this PDU.
Following are the messages that are defined for VTP:
VpnInfo message (msgCode = 1)
TunStpRq message (msgCode = 11)
TunStpRp message (msgCode = 12)
TunClrRq message (msgCode = 13)
TunUpdRq message (msgCode = 14)
TunUpdRp message (msgCode = 15)
6.2 AVPs
VTP uses a Attribute-Value-Pair (AVP) encoding scheme to encode the
information carried in VTP messages.
Each AVP is encoded as:
Elwin [Page 5]
draft-elwin-ppvpn-vtp-00.txt VPN Tunneling Protocol July 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Length | VendorID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AttributeID | AttributeValue ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... AttributeValue ... (till remaining Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6.2 AVP Format
Where:
Reserved = all bits 0, till more extensions are added
Length = number of octets in this AVP, starting from 'reserved'.
VendorID = IANA assigned enterprise code.
AttributeID = Identifier for the Attribute
AttributeValue = Value for the Attribute
Following are the different AVPs defined for VTP:
ResultCode AVP - has code denoting errors, or reason for tunnel
clearing, etc.
Capability AVP - has a capability bitmap denoting the optional
features supported.
Keepalive AVP - used for controlling keepalive functions.
VpnList AVP - has a list of VPNs supported, also has additional
flags
TunnelTag AVP - the tunnel tag value
ProtocolVersion AVP - protocol version supported.
Elwin [Page 6]
draft-elwin-ppvpn-vtp-00.txt VPN Tunneling Protocol July 2001
6.3 VTP State Machine
The following state machine represent the state corresponding to each
VPN tunnels in a device. As soon as the TCP connection is established,
all the VPN tunnels start with a IDLE state.
State Event Action New State
----- ----- ------ ---------
IDLE Trigger for Tx TunStpRq TXWAIT
setting up tunnel
IDLE Rx TunStpRq Tx TunStpRp ESTAB
estab tunnel
IDLE Rx any other Tx TunClrRq IDLE
VRTP msg
TXWAIT Rx TunStpRp estab tunnel ESTAB
TXWAIT Rx TunStpRq TxTunStpRp ESTAB
estab tunnel
TXWAIT Rx any other Tx TunClrRq IDLE
VRTP msg close tunnel
ESTAB Rx TunClrRq close tunnel IDLE
ESTAB Rx TunStpRq Tx TunClrRq IDLE
close tunnel
ESTAB Rx TunStpRp Discard msg ESTAB
ESTAB Rx any other Process msg ESTAB
VRTP msg
ESTAB Trigger for Tx TunClrRq IDLE
clearing up tunnel close tunnel
Elwin [Page 7]
draft-elwin-ppvpn-vtp-00.txt VPN Tunneling Protocol July 2001
+-----+
| | Any other msg
| | -------------
| v Tx TunClrRq
+------------+
| |
+------------>| IDLE |------------------+
| | | |
| +------------+ |
| trigger | ^ |
Rx TunClrRq | tunnel setup | | |
----------- | ------------ | | Any other msg |
close tunnel | Tx TunStpRq | | ------------- |
| | | Tx TunClrRq |
| | | close tunnel |
| | | |
| | | |
Rx TunStpRq | | | |
------------ | | | |
Tx TunClrRq | v | |
close tunnel | +--------+ |
| | | |
| | TXWAIT | |
| | | |
| +--------+ |
| | |
Trigger for | | Rx TunStpRp |
closing tunnel| Rx TunStpRq | ----------- |
------------ | ----------- | estab tunnel |
Tx TunClrRq | Tx TunStpRp | |
close tunnel | estab tunnel | |
| | |
| | |
| v |
| +-----------+ |
| | | |
+-------------| ESTAB |<------------------+
| | Rx TunStpRq
+-----------+ ------------
Any other msg ^ | Tx TunStpRp
------------- | | estab tunnel
Process msg | |
+-----+
Figure 6.3 VTP State Machine
Elwin [Page 8]
draft-elwin-ppvpn-vtp-00.txt VPN Tunneling Protocol July 2001
7.0 Protocol Operation
The protocol operation is illustrated with the sample scenario shown
in Fig 7.1. This section is just used for illustration and does not
constrain any variation in implementation.
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 represent VTP tunnels.
(V1, V3) (V1, V2)
PE1 ---------------------------- PE2
| \ / |
| \ / |
| \ / |
| \ / |
| \ / |
| \ / |
| \ / |
| \ |
| / \ |
| / \ |
| / \ |
| / \ |
| / \ |
| / \ |
| / \ |
PE4 PE3
(V2, V3) (V1)
Figure 7.1 Sample Scenario
7.1 Control connection operation
- Consider a scenario in which the routers PE1, PE2 and PE3 are up
and operational, and the router PE4 is started.
- PE4 understands the PE1 and PE2 are the routers with which it needs
to establish a tunnel, through VTP.
- PE4 establishes these tunnels, using VTP.
7.2 Datapath Operation
- Take for example a packet in VPN V1 to reach PE3 from PE1.
- Packet is received in PE1 from a V1 CE, attached to this PE.
- Forwarding lookup done with the V1 VFI forwarding table in PE1.
Elwin [Page 9]
draft-elwin-ppvpn-vtp-00.txt VPN Tunneling Protocol July 2001
- Egress interface is obtained which is a TVI.
- The TVI Tx function, encapsulates the packet with VTE and outer
IP header. The source IP address is that of PE1, and destination
IP address of the remote PE is determined based on TVI.
- Backbone forwarding table lookup is done with the encapsulated
packet, and eventually the packet is sent out.
- The remote PE receives this packet and finds it as a local packet.
- VTE decapsulation is done, during which the appropriate VFI is
determined.
- Forwarding lookup is done with this VPN forwarding table, and
eventually the packet is transmitted out.
7.3 VPN Route Exchanges
- IGP routing protocols are instantiated per VFI.
- The dynamic TVIs are also added as interfaces to the appropriate
routing protocol instance.
- Thus routing protocol PDUs get encapsulated in VTE and reach the
remote PE, where it gets decapsulated and is handed over to the
appropriate routing instance.
8.0 Multipoint Tunnels
TBD
9.0 IANA Considerations
- TCP port number for VTP to be assigned.
- IP protocol type value for VTE to be assigned.
10.0 Security Considerations
The VTP as such does not have any authentication or encryption in
it. Rather it relies on other protocols, like IPSec to do this.
11.0 Summary and Conclusions
The draft defines a mechanism to tunnel VPN traffic over a backbone
network. The solution described does not need MPLS or IPSec as a
prerequisite to achieve this. For cases where security is needed
IPSec can still be used along with this, in transport mode.
12.0 Acknowledgments
13.0 References
[RFC 2026] S. Bradner, "The Internet Standards Process - Revision 3",
RFC 2026, Oct 1996.
Elwin [Page 10]
draft-elwin-ppvpn-vtp-00.txt VPN Tunneling Protocol July 2001
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14 and RFC 2119, Mar 1997.
[RFC 2685] B. Fox, B. Gleeson, "Virtual Private Networks Identifier",
RFC 2685, Sep 1999.
[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.
14.0 Author's Address
Elwin Stelzer Eliazer
Corona Networks, Inc.
630 Alder Drive
Milpitas, CA 95035
Phone: 408-519-3832
Email: elwinietf@yahoo.com
APPENDIX A: Summary for Sub-IP Area
This draft defines a tunneling and signaling mechanism to achieve
Provider Provisioned VPNs.
A.1 Where does it fit in the Picture of the Sub-IP Work
This work fits in the PPVPN Working Group.
A.2 Why is it Targeted at this WG
The WG is chartered with developing Provider Provisioned VPN
solutions. This draft contributes to this.
A.3 Justification
The WG should consider this document since it provides a means to
achieve PPVPNs.
Elwin [Page 11]
