One document matched: draft-xue-dhc-dynamic-gre-00.txt
Network Working Group L. Xue
Internet-Draft D. Guo
Intended status: Standards Track Huawei
Expires: January 10, 2014 July 09, 2013
Dynamic Stateless GRE tunnel
draft-xue-dhc-dynamic-gre-00
Abstract
Specifically, WiFi has emerged as an important access technology for
Multiple Service Operator (MSO) and mobile service provider. For
mobile service provider, WiFi is preferred as a trusted access
technology for service. It has became important to provide simple
transition method expected for service via WiFi access. For example,
tunnelling on the customer side aims at conveying WiFi service
between a hotspot and the Service Gateway. GRE tunnel is an
increasingly popular encapsulation choice because of simple
encapsulation and easy implementation, especially in aforementioned
environments. However, manual configuration is not suitable if there
are large numbers of the end-points of GRE tunnels. This document
proposes a dynamic-configured stateless GRE tunnel, which does not
modify encapsulation format of GRE, but adds signaling for tunnel
parameters discovery, such as address, GRE key etc.
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 10, 2014.
Xue & Guo Expires January 10, 2014 [Page 1]
Internet-Draft Dynamic Stateless GRE July 2013
Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Dynamic Stateless GRE Tunnel . . . . . . . . . . . . . . . . 4
3.1. Preliminary Phase . . . . . . . . . . . . . . . . . . . . 4
3.1.1. NPE discovery on CPE . . . . . . . . . . . . . . . . 5
3.1.2. CPE discovery on NPE . . . . . . . . . . . . . . . . 5
3.2. Establishment Phase . . . . . . . . . . . . . . . . . . . 6
3.3. Keepalive Phase . . . . . . . . . . . . . . . . . . . . . 6
4. DHCP Option Definition . . . . . . . . . . . . . . . . . . . 6
5. Application of Dynamic Stateless GRE Tunnel . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Generic Routing Encapsulation (GRE) tunnel[RFC1701][RFC2784] is
widely deployed in the ISP networks. There are several general
scenarios that many access devices set up GRE tunnels to a
concentrator network equipment for public or private services. In
this document, the tunnel endpoint may be Customer Premises Equipment
(CPE), i.e., a home gateway or an access point, and a network
concentrator equipment, i.e., a Service Gateway which is kind of
Network Facing PE (NPE).
Specifically, WiFi has emerged as an important access technology for
Multiple Service Operator (MSO) and mobile service provider. For
mobile service provider, WiFi is preferred as a trusted access
technology for private service. It has became important to provide
simple transition method expected for service via WiFi access. For
Xue & Guo Expires January 10, 2014 [Page 2]
Internet-Draft Dynamic Stateless GRE July 2013
example, tunnelling on the customer side aims at conveying WiFi
service. A tunnel is thus defined in this scenario as the connection
between the end-point at the cable modem or hotspot, and the other
end-point at the Service Gateway.
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 Customer Premises Equipment (CPE), such as cable modem
or hotspot is too simple to be a L2TPv3 initiator. In most
scenarios, providers do not need such a complicated transition
method. GRE tunnel is an increasingly popular encapsulation choice
because of simple encapsulation and easy implementation, especially
in aforementioned environments.
An illustration about GRE tunnel deployment in MSO network is shown
in the following figure.
+-----+ +-----+ +-----+
| | GRE Tunnel | | | |
| +-------------+-----+-----------+ |
| +-------------+-----+-----------+ |
| | | | | |
+-----+ +-----+ +-----+
CPE UPE NPE
Figure 1: An Illustration about GRE Tunnel Deployment
However, up to now, GRE tunnels are stateless and configured
manually. Manual configuration is not suitable if there are large
numbers of CPEs, i.e., Cable Modems (CMs) or hotspots, which are the
end-points of GRE tunnels. This document proposes a dynamic-
configured stateless GRE tunnel, which does not modify encapsulation
format of GRE, but adds signaling for tunnel parameters discovery,
such as address, GRE key, etc[RFC2890].
In addition, this document extends Dynamic Host Configuration
Protocol (DHCP) for IPv4 [RFC2131]or DHCP for IPv6 [RFC3315], so that
Customer Premises Equipment (CPE) can automatically acquire the
Network Premises Equipment (NPE) address. Then the stateless GRE
will be setup dynamically. Additionally, the discovery process may
also support load-sharing and recovery from a single point of
failure.
Xue & Guo Expires January 10, 2014 [Page 3]
Internet-Draft Dynamic Stateless GRE July 2013
In the absence of DHCP, PPP, Router Advertisements or CAPWAP could be
used for GRE tunnel discovery automatically, but this document does
not discuss these methods in detail.
2. Terminology
The following terminologies are used in this document.
User Equipment (UE)
The UE is the a device of the subscriber, which could be PC or Mobile
Phone.
Customer Premises Equipment (CPE)
The CPE equipment is the box that a provider places with the
customer, 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"
User Facing Equipment (UPE)
The UPE is the device to which the functions needs to take forwarding
or switching 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", when CPE is using DHCP to obtain
network address.
Network Facing Equipment (NPE)
The NPE is the device to which the signalling and control functions
are allocated. It is kind of Service Gateway.
3. Dynamic Stateless GRE Tunnel
Stateless Dynamic GRE tunnel mechanism enables the tunnel endpoints
can discovery each other dynamically at first. Based on this
preliminary discovery phase, GRE tunnel will be setup accordingly.
The process is described in the following sub-sections.
3.1. Preliminary Phase
Xue & Guo Expires January 10, 2014 [Page 4]
Internet-Draft Dynamic Stateless GRE July 2013
3.1.1. NPE discovery on CPE
Before tunneling to NPE,CPE MUST get the NPE address and other tunnel
parameters such as GRE Key, Version, Protocol Type[RFC2784][RFC2890]
if required. The information may be configured on the CPE.
However, manual configurations are difficult to operate when there
are large number of CPEs. A new mechanism is required to enable the
access point in the access network to discover the information of the
concentrator automatically. It is proposed to extend DHCPv4 or
DHCPv6 for discovery.
In order to support NPE discovery on CPE, new DHCP GRE Discovery (GD)
Options are defined respectively for DHCPv4 and DHCPv6. They have
the identical structure apart from address length. The form is
defined in Section 4.
When a DHCP server answers a CPE request message, the NPE information
can be carried in a DHCP reply message via DHCP options. Thus CPE
configures the NPE address and tunnel parameter of GRE tunnel, such
as GRE key etc if they are carried in the DHCP message. Details are
descried in Section 3.
DHCP server decides to attach GD option based on policy. One choice
is to respond only if the client requests the GD option; another is
to append it to every reply no matter the client requests it or not.
For load sharing or single-point failure recovery purposes, a DHCP
reply message may carry information of more than one NPEs.
3.1.2. CPE discovery on NPE
Normally, GRE encapsulated packet should be received by NPE. In this
case,NPE should recognize that this is a GRE packet. 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,
additionally, GRE Key, GRE Version, Protocol Type.
The GRE encapsulated packet used could be data 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. The destination IP
of outer layer header in GRE encapsulation can be obtained as
description of section 2.1.1. The outer source IP uses the IP
address of the CPE.
Xue & Guo Expires January 10, 2014 [Page 5]
Internet-Draft Dynamic Stateless GRE July 2013
Consequently, NPE can discover CPE via the received GRE encapsulated
packet from CPE.
3.2. Establishment Phase
As the description in aforementioned section, in order to set up the
dynamic tunnel, tunnel endpoints are required to discover each other.
After the Preliminary Phase, GRE tunnel can be setup subsequently.
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. For example, if NPE recognizes the packet is the DHCP
message from UE for address request after decapsulating GRE header.
Then the NPE can records the assigned UE's address, which is the
inner address of GRE encapsulated packet.
The tunnel client list records the information of all tunnel clients.
Each entry of the list describes information of a tunnel, includes
the mapping of the inner address of tunnel and the outer IP of
client. Based on transmission method over GRE, the inner address is
UE's IP address when IP over GRE, or MAC address when Eth over GRE.
For inbound traffic, NPE checks the tunnel client list according to
destination address of the packet and decides which tunnel the
traffic should be forwarded to.
3.3. Keepalive Phase
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.
4. DHCP Option Definition
The DHCPv4 GRE Discovery (GD) Option is mainly used 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 | NPE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cont. | Sub-Options (Optional)|
Xue & Guo Expires January 10, 2014 [Page 6]
Internet-Draft Dynamic Stateless GRE July 2013
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| cont. |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCPv4 GRE Discovery Option
Code: TBD1
Len: The length of total option. If there are several instance for
multiple NPE address considering redundancy, the length should be
Len1 + Len2 + ... + Len n +Len of sub options in octets.
NPE Address: IPv4 address of NPE, the endpoint of GRE tunnel.
Sub-Options (Optional): The sub-options are 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub Code | Sub Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. Suboption Value (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCP Sub-option
Based on requirement defined in [RFC2784] [RFC2890], following sub-
options are used in this document to configure the complementary
tunnel information.
Sub Code (1 octet)
o GRE Key Sub-option: Sub code = 1
o GRE Version Sub-option: Sub code = 2
o GRE Protocol Sub-option: Sub code =3
Sub length (1 octet): The total octets of the suboption value field
Suboption Value (variable): encodings of the value field depend on
the suboption type as enumerated above, according definition in
[RFC2890].
Xue & Guo Expires January 10, 2014 [Page 7]
Internet-Draft Dynamic Stateless GRE July 2013
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. Considering redundancy, more than one GD Options can be
carried in DHCPv6 message. The DHCPv6 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
. NPE Address .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Sub-option .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCPv6 GRE Discovery Option
Code: TBD1
Len: The length of total option.
NPE Address: IPv6 address of NPE, the endpoint of GRE tunnel.
Sub-Options (Optional): The sub-options are structured in TLV style.
They are consistent with the sub-options defined in DHCPv4 GD option.
5. Application of Dynamic Stateless GRE Tunnel
Figure 2 illustrates the procedure for dynamic stateless GRE tunnel
in MSO WLAN network. The CM, CMTS and SG in the picture are
respectively the CPE, UPE and NPE.
/ \ IPv4-x.x.x.x IPv4-y.y.y.y / \
/ \ +-------+ +-------+ +-------+ / \
| | | CM | | CMTS | | SG | | |
| UE +-----+ (CPE) +-------+ (UPE) +------+ (NPE) +------+Internet
\ / | | | | | | \ /
\ / +-------+ +-------+ +-------+ \ /
DHCP Client DHCP Server
| | | |
| |DHCPv4 Request | |
| Preliminay + ------------->| |
| Phase | | |
| (Discovery) | DHCPv4 Reply | |
| + <-------------| |
| | with y.y.y.y | |
|
Xue & Guo Expires January 10, 2014 [Page 8]
Internet-Draft Dynamic Stateless GRE July 2013
| | |
| *-------------------------------*
|--------------+----User Packet-in-GRE-Encap.->|
| Establishment*----with x.x.x.x -------------*
| Phase | / \
| | | Tunnel Client |
| | \ List Config. /
| | |
| Keepalive *-------------------------------*
| Phase |<-------KeepAlive Packet------>|
| *-------------------------------*
Figure 2: Dynamic Stateless GRE Tunnel in MSO WLAN Network
At Preliminary Phase, the CM, as one endpoint of GRE tunnel, may get
information of SG by the DHCP method mentioned in section 2.1.1.
Subsequently, the CM encapsulates the UE's packet with GRE
encapsulation to SG's address y.y.y.y. The source IP of GRE header is
x.x.x.x. Once receiving the packet, the SG looks up the outer source
IP x.x.x.x of the packet in its tunnel client list. If it is a new
client, SG will creat and configure a new GRE tunnel. Generally, the
encapsulated packet could be DHCP packet from UE for address. For
example, if NPE recognizes the packet is the DHCP message from UE for
address request after decapsulating GRE header. Then the NPE can
records the assigned UE's address, which is the inner address of GRE
encapsulated packet. In addition, a mapping between the inner
address of UE and the outer IP address of GRE is added into the
tunnel client list on SG. Finally the application IPv4 traffic can
pass through the GRE tunnel, and the establishment phase finished.
During Keepalive Phase, 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.
6. IANA Considerations
IANA is requested to allocate one DHCPv4 GD Option code TBD1 and one
DHCPv6 GD Option code TBD2.
7. Security Considerations
[RFC2890] describes the security requirement of GRE tunnel. This
document follows the requirements based on sub-options used when
necessary, mentioned in Section 3.
Xue & Guo Expires January 10, 2014 [Page 9]
Internet-Draft Dynamic Stateless GRE July 2013
8. 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.
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 January 10, 2014 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 14:52:24 |