Network Working Group L. Xue
Internet-Draft D. Guo
Intended status: Standards Track Huawei
Expires: January 5, 2015 July 4, 2014
Dynamic Stateless GRE Tunnel
draft-xue-dhc-dynamic-gre-02
Abstract
Generic Routing Encapsulation (GRE) is regarded as a popular
encapsulation tunnel technology because of simpleness and easy
implementation. When a node tries to encapsulate the user traffic in
a GRE tunnel, it needs to first obtain the IP address of the
destination node which need to decapsulate the GRE packets. In
practice, the GRE tunnel destination IP address may be manually
configured. This configuration introduces efficiency issues for
operators, especially, in the scenarios where there are a large
number entities need to deploy GRE tunnels. This work proposes an
approach to configure the GRE information dynamiclly.
Requirements Language
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]
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 5, 2015.
Xue & Guo Expires January 5, 2015 [Page 1]
Internet-Draft Dynamic Stateless GRE July 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Dynamic GRE Tunnel . . . . . . . . . . . . . . . . . . . . . 4
5. DHCP Option Definition . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Generic Routing Encapsulation (GRE) [RFC1701][RFC2784] is widely
deployed in the operators' networks. When a node tries to
encapuslate the user traffic in a GRE tunnel, it needs to first
obtain the IP address of the destination node which can decapsulate
the GRE packets.
In practice, the decapsulation node IP address of GRE may be manually
configured. This configuration introduces efficiency issues for
operators, espeically, in the scenarios where there are large amount
of GRE tunnels needed. This work describes a case about large amount
of GRE tunnels deployment required and proposes a solution which
extends Dynamic Host Configuration Protocol (DHCP) so as to enable to
configure the GRE destination node IP address dynamically.
Xue & Guo Expires January 5, 2015 [Page 2]
Internet-Draft Dynamic Stateless GRE July 2014
2. Terminology
The following terminologies are used in this document.
Access Controller (AC)
The network entity that provides Wireless Termination Point (WTP)
access to the network infrastructure in the data plane, control
plane, management plane, or a combination therein.
Customer Premises Equipment (CPE)
The CPE equipment is the box that a provider may distribute to the
customers, which could be Home Gateway (HG), Cable Modem (CM), etc.
When CPE is using DHCP to obtain network address, CPE is acting as
"DHCP Client"
Network Facing Equipment (NPE)
The NPE is the device to be deployed with the signalling and control
functions. It is kind of Service Gateway.
User Equipment (UE)
The UE is the a device of the customers, which could be PC or Mobile
Phone.
User Facing Equipment (UPE)
The UPE is the device to make forwarding decisions at the ingress of
the provider network, which could be Cable Modem Termination Systems
(CMTS). UPE is the "DHCP Server" or "DHCP relay agent" in DHCP
framework.
Wireless Termination Point (WTP)
The physical or logical network entity that contains an RF antenna
and wireless physical layer (PHY) to transmit and receive station
traffic for wireless access networks.
3. Use Case
Wireless Local Area Network (WLAN) has emerged as an important access
technology for service operators. Some operators deploy a large
number of WTPs in the specific environments with the dense crowd. In
this scenario, WTPs are preferred to be managed and controlled in a
centralized location by AC. The traffic of WTPs are generally
handled on the access router of the network, which is a different
Xue & Guo Expires January 5, 2015 [Page 3]
Internet-Draft Dynamic Stateless GRE July 2014
node from AC. This architecture can avoid the overload for traffic
management on the AC. This motivates the need for the WTP to support
some tunnel encapsulation technologies to the Access Router. GRE is
one of the preferred tunnel solution, because of simple and easy
deployment reasons.
Currently, several tunnel mechanisms have been standardized, for
example Layer Two Tunneling Protocol version 3 (L2TPv3) [RFC3931].
L2TPv3 supports IP/UDP encapsulation and fulfills the tunnel
requirements. However, as a multi-layers encapsulation protocol,
L2TPv3 has to carry multiple protocol headers per data packet. It is
complicated and costly, mostly used for Virtual Private Network
(VPN). Most CPE devices are too simple to be a L2TPv3 initiator.
An illustration of WLAN network is shown in figure 1. When WTP tries
to encapsulate the user traffic in a GRE tunnel, it needs to first
obtain the Access Router (AR) IP address. In practice, this IP
address is usually deployed on WTP manually, which introduces
efficiency issues for operators. Especially, a large number of WTPs
are deployed with the dense crowd.
CAPWAP +--------+
++========+ AC |
// +--------+
//
+-----+// DATA Tunnel (GRE) +--------------+
| WTP |===========================| Access Router|
+-----+ +--------------+
Figure 1: WLAN Illustration
4. Dynamic GRE Tunnel
This work proposes an automatic solution which extends Dynamic Host
Configuration Protocol (DHCP) so as to configure the GRE destination
IP address. Due to successful IP address configuration, GRE tunnel
can be setup dynamically.
Figure 2 illustrates the procedure for dynamic GRE tunnel in WLAN
network. The WTP, AR in the picture are respectively the CPE and
NPE.
Xue & Guo Expires January 5, 2015 [Page 4]
Internet-Draft Dynamic Stateless GRE July 2014
/ \ IPv4-x.x.x.x IPv4-y.y.y.y / \
/ \ +-------+ +-------+ +-------+ / \
| | | | | | | | | |
| UE +-----+ CPE +-------+ DHCP +------+ NPE +------+Internet
\ / | | | | | | \ /
\ / +-------+ +-------+ +-------+ \ /
DHCP Client DHCP Server
| | | |
| |DHCPv4 Request | |
| Preliminary + -------------> |
| Phase | | |
| (Discovery) | DHCPv4 Reply | |
| + <-------------| |
| | with y.y.y.y | |
|
| | |
| *-------------------------------*
|--------------+----User Packet-in-GRE-Encap.->|
| Establishment*----with x.x.x.x -------------*
| Phase | / \
| | | Tunnel Client |
| | \ List Config. /
| | |
| Keepalive *-------------------------------*
| Phase |<-------Keepalive Packet------>|
| *-------------------------------*
Figure 2: Dynamic GRE Tunnel in WLAN Network
At Preliminary Phase, the CPE as one endpoint of GRE tunnel, may get
information of NPE by the DHCP approach. CPE sends the DHCP request
to initiate a IPv4 address request. When a DHCP server replies the
CPE request message, the NPE information can be carried in a DHCP
reply message via DHCP options. Thus CPE configures the NPE address
y.y.y.y and tunnel parameter of GRE tunnel, such as GRE key etc if
they are carried in the DHCP message. For load sharing or single-
point failure recovery purposes, a DHCP reply message may carry
information of more than one NPEs.
Consequently, NPE can discover CPE via the received GRE encapsulated
packet from CPE. Then the GRE tunnel information, such as IP address
of CPE as source address is checked and restored as destination of
GRE tunnel on NPE side. Generally, CPE can encapsulate UE's first
packet with GRE, no matter data packet or control packet. For
example, during a User Equipment (UE) subscriber attached initiates
the DHCP procedure for an inner address, CPE should encapsulated this
DHCP message via GRE.
Xue & Guo Expires January 5, 2015 [Page 5]
Internet-Draft Dynamic Stateless GRE July 2014
When NPE receives the packet with GRE encapsulation, it should look
up the outer source IP of the packet in its tunnel client list. If
it is a new client, the NPE adds source IP into the tunnel client
list, decapsulates GRE header and deals with the packet encapsulated
by GRE.
There could be a keepalive mechanism for GRE tunnel between CPE and
NPE. If there is neither keepalive packet nor data packet when the
deployed timer expires, the NPE will tear down the tunnel and
releases resource
5. DHCP Option Definition
As introduced above, The DHCPv4 GRE Discovery (GD) Option is defined,
when CPE wants to obtain an NPE address in IPv4 network. This Option
is carried in DHCPv4.
The DHCPv4 GD Option is structured as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Len | Ver |Reserved |Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cont. | NPE address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cont. |
+---------------+
DHCPv4 GRE Discovery Option
Code: TBD1
Len: The length of value field. If there are several instance for
multiple NPE address considering redundancy, the length should be
Len1 + Len2 + ... + Len n +Len of sub option in octets.
Ver: The Version Number field which is contained in GRE header,
defined in [RFC2784].
Reserved: This field is reserved for future use. A receiver MUST
discard a packet where this field is non-zero. These bits MUST be
sent as zero and MUST be ignored on receipt.
Protocol Type: The Protocol Type field contains the protocol type of
the payload packet. This field is defined in [RFC2784].
Xue & Guo Expires January 5, 2015 [Page 6]
Internet-Draft Dynamic Stateless GRE July 2014
NPE Address: IPv4 address of NPE, the endpoint of GRE tunnel.
Sub-Option (Optional): DHCPv4 GRE Key Suboption is structured in TLV
style shown as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Len = 4 | GRE Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCPv4 GRE Key Suboption
Based on requirement defined in [RFC2784] [RFC2890], GRE Key
Suboption is used in this document to configure the complementary
tunnel information. GRE Key is generated from [RFC2890]. If the
client receives the GRE Key suboption, the key MUST be inserted into
the GRE encapsulation header. It is used for identifying extra
context information about the received payload. The payload packets
without the correspondent GRE Key or with an unmatched GRE Key will
be silently dropped.
Code 1 for GRE Key Suboption.
Len (1 octet): The total octets of the suboption value field.
Suboption Value : GRE Key according definition in [RFC2890].
The DHCPv6 GRE Discovery (GD) Option is mainly used when CPE wants to
obtain an NPE address in IPv6 network. This option is carried in
DHCPv6. According to [I-D.ietf-dhc-option-guidelines]The DHCPv6 GD
Option is structured as follows.
Xue & Guo Expires January 5, 2015 [Page 7]
Internet-Draft Dynamic Stateless GRE July 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |Reserved | Protocol Type | NPE IPv6 Add |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. NPE IPv6 Address (cont.) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cont. |
+-+-+-+-+-+-+-+-+
DHCPv6 GRE Discovery Option
Code: TBD2
Len: The length of the option value.
Ver: The Version Number field which is contained in GRE header,
defined in [RFC2784].
Reserved: This field is reserved for future use. A receiver MUST
discard a packet where this field is non-zero. These bits MUST be
sent as zero and MUST be ignored on receipt.
Protocol Type: The Protocol Type field contains the protocol type of
the payload packet. This field is defined in [RFC2784].
NPE Address: IPv6 address of NPE, the endpoint of GRE tunnel.
Based on requirement defined in [RFC2784] [RFC2890], DHCPv6 GRE Key
Option is used in this document to configure the complementary tunnel
information. Optionally, the DHCPv6 GRE Key Option is encapsulated
in DHCPv6 GRE Discovery Option. It is structured in TLV style shown
as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Len = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCPv6 GRE Key Option
Code 1 for DHCPv6 GRE Key Option: TBD3
Xue & Guo Expires January 5, 2015 [Page 8]
Internet-Draft Dynamic Stateless GRE July 2014
Len (1 octet): The total octets of the option value field.
Option Value : GRE Key according definition in [RFC2890].
6. IANA Considerations
TBD
7. References
7.1. Normative References
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
7.2. Informative References
[I-D.ietf-dhc-option-guidelines]
Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
draft-ietf-dhc-option-guidelines-17 (work in progress),
January 2014.
Authors' Addresses
Xue & Guo Expires January 5, 2015 [Page 9]
Internet-Draft Dynamic Stateless GRE July 2014
Li Xue
Huawei
No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,HaiDian District
Beijing 100095
China
Email: xueli@huawei.com
Dayong Guo
Huawei
No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,HaiDian District
Beijing 100095
China
Email: guoseu@huawei.com
Xue & Guo Expires January 5, 2015 [Page 10]