One document matched: draft-xue-dhc-dynamic-gre-01.txt
Differences from draft-xue-dhc-dynamic-gre-00.txt
Network Working Group L. Xue
Internet-Draft D. Guo
Intended status: Standards Track Huawei
Expires: August 18, 2014 February 14, 2014
Dynamic Stateless GRE Tunnel
draft-xue-dhc-dynamic-gre-01
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 some
destination node to decapsulate the GRE packets. According to the
information of destination node, a node can setup the GRE tunnel
connection. In practice, the IP address of decapsulation node of GRE
tunnel may be manually configured on the GRE encapsulation side.
This configuration introduces efficiency issues for operators,
especially, in the scenarios where there are large amount of GRE
tunnels needed. This work proposes an approach to configure the GRE
tunnel dynamically.
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 August 18, 2014.
Xue & Guo Expires August 18, 2014 [Page 1]
Internet-Draft Dynamic Stateless GRE February 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 . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
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
encapsulate the user traffic in a GRE tunnel, it needs to first
obtain the IP address of some destination node to decapsulate the GRE
packets. According to the information of destination node, a node
can setup the GRE tunnel connection.
In practice, the IP address of decapsulation node of GRE may be
manually configured on the GRE encapsulation node. This
configuration introduces efficiency issues for operators, especially,
in the scenarios where there are large amount of GRE tunnels needed.
This work describes a case about large amount of GRE tunnels
deployment requirement and proposes a solution which extends Dynamic
Host Configuration Protocol (DHCP) so as to enable an encapsulate
node of GRE tunnel to be configured the IP address of the destination
node.
Xue & Guo Expires August 18, 2014 [Page 2]
Internet-Draft Dynamic Stateless GRE February 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 gateway of the network, which is a different node from
Xue & Guo Expires August 18, 2014 [Page 3]
Internet-Draft Dynamic Stateless GRE February 2014
AC. This architecture can avoid the overload for traffic management
on the AC. Further, the lawful intercepting of user traffic is
needed on the access router. This motivates the need for the WTP to
support some tunnel encapsulation technologies where the data
tunnelled from the WTP are terminated at an AR.
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. In
this scenario, providers prefer an candidate tunnel encapsulation
(i.e.,GRE) with simple and easy implementation.
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 IP address of the destination node (AR) to decapsulate the
GRE packets. According to the IP address of AR, CPE can then setup
the GRE tunnel to AR.
CAPWAP +--------+
++========+ AC |
// +--------+
//
+-----+// DATA Tunnel (GRE) +--------------+
| WTP |===========================| Access Router|
+-----+ +--------------+
Figure 1: WLAN Illustration
In practice, GRE encapsulation node generally be configured with the
destination IP address manually. This configuration introduces
efficiency issues for operators, especially, in the scenarios a large
number of WTPs are deployed with the dense crowd. As a result, there
will be huge manual configuration work on the WTPs in the network,
which could be costly for operators and could introduce enormous
management costs.
4. Dynamic GRE Tunnel
This work proposes a solution which extends Dynamic Host
Configuration Protocol (DHCP) so as to enable an encapsulate node of
GRE tunnel to be configured the IP address of the destination node.
Based on the IP address configured phase, GRE tunnel can be setup
accordingly.
Xue & Guo Expires August 18, 2014 [Page 4]
Internet-Draft Dynamic Stateless GRE February 2014
Figure 2 illustrates the procedure for dynamic GRE tunnel in WLAN
network. The WTP, AR in the picture are respectively the CPE and
NPE.
/ \ 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 may send 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 parameters of tunnel, such as IP address
of CPE as source address may be checked and restored as destination
of GRE tunnel on NPE. The GRE encapsulated packet used could be data
Xue & Guo Expires August 18, 2014 [Page 5]
Internet-Draft Dynamic Stateless GRE February 2014
packet or control packet. Generally, CPE can encapsulate UE's first
packet with GRE. For example, during a User Equipment (UE)
subscriber attached initiates the DHCP procedure for an inner
address, CPE should encapsulated this DHCP message from UE via GRE.
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/v6 GRE Discovery (GD) Option is
defined, when NPE sends the its IPv4/6 address to CPE in IPv4/6
network for GRE tunnel between CPE and NPE. This Option is carried
in DHCPv4/v6 Reply message.
According to [I-D.ietf-dhc-option-guidelines], the DHCPv4/6 GD Option
and the DHCPv4/6 GRE Key Suboption are 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].
Xue & Guo Expires August 18, 2014 [Page 6]
Internet-Draft Dynamic Stateless GRE February 2014
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: IPv4 address of NPE, the endpoint of GRE tunnel.
Sub-Option (Optional): DHCPv4 GRE Key Suboption is structured in TLV
style shown as follows. It is used to configure the complementary
information of a GRE tunnel according to [RFC2784] and [RFC2890].
If the CPE receives suboption, the key MUST be inserted into the GRE
encapsulation header. The GRE Key is used for identifying extra
context information about the received payload. On the decapsulate
node NPE, the GRE packets without the correspondent GRE Key or with
an unmatched GRE Key will be dropped silently.
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
In IPv6 network,the DHCPv6 GRE Discovery (GD) Option and the DHCPv6
GRE Key Option are defined accordingly.
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
Xue & Guo Expires August 18, 2014 [Page 7]
Internet-Draft Dynamic Stateless GRE February 2014
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.
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
Len (1 octet): The total octets of the option value field.
Option Value : GRE Key defined in [RFC2890].
6. IANA Considerations
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.
Xue & Guo Expires August 18, 2014 [Page 8]
Internet-Draft Dynamic Stateless GRE February 2014
[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
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 August 18, 2014 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 16:29:12 |