The Linux kernel GTP tunneling module

문서와 구현 위치

`drivers/net/gtp.c`에는 GTP 터널 종단점의 커널 수준 구현이 있습니다. 문서는 Harald Welte와 Andreas Schultz가 작성했습니다.

.. SPDX-License-Identifier: GPL-2.0

=====================================
The Linux kernel GTP tunneling module
=====================================

Documentation by
                 Harald Welte <[email protected]> and
                 Andreas Schultz <[email protected]>

In 'drivers/net/gtp.c' you are finding a kernel-level implementation
of a GTP tunnel endpoint.

GTP란 무엇인가

GTP(Generic Tunnel Protocol)는 이동국인 휴대전화나 모뎀과 인터넷 같은 외부 패킷 데이터 네트워크 사이에서 사용자 IP payload를 터널링하는 3GPP 프로토콜입니다. 단말이 데이터 연결을 시작하면 제어 평면으로 터널 생성을 신호하고, 터널 종단점은 단말 쪽과 gateway 쪽에 놓입니다. 중간 노드는 캡슐화된 패킷을 전달합니다.

단말 자체는 GTP 대신 LLC/SNDCP/RLC/MAC 같은 무선 기술별 스택으로 사용자 IP를 보냅니다. 사업자 망의 SGSN, 3G femtocell hNodeB, LTE eNodeB 같은 요소가 종단 간 터널을 끊지 않고 이 무선 스택을 GTP로 변환해 relay합니다.

GSM/UMTS의 GGSN 또는 LTE의 P-GW가 GTP 터널을 종료하고 패킷을 decapsulation한 뒤 외부 네트워크로 전달합니다. 대상은 공용 인터넷, 사설 IP망, 이론적으로는 X.25 같은 비 IP망도 될 수 있습니다. 프로토콜 규격은 3GPP TS 29.060이며 원문에는 v13.6.0 PDF 링크도 제공됩니다.

What is GTP
===========

GTP is the Generic Tunnel Protocol, which is a 3GPP protocol used for
tunneling User-IP payload between a mobile station (phone, modem)
and the interconnection between an external packet data network (such
as the internet).

So when you start a 'data connection' from your mobile phone, the
phone will use the control plane to signal for the establishment of
such a tunnel between that external data network and the phone.  The
tunnel endpoints thus reside on the phone and in the gateway.  All
intermediate nodes just transport the encapsulated packet.

The phone itself does not implement GTP but uses some other
technology-dependent protocol stack for transmitting the user IP
payload, such as LLC/SNDCP/RLC/MAC.

At some network element inside the cellular operator infrastructure
(SGSN in case of GPRS/EGPRS or classic UMTS, hNodeB in case of a 3G
femtocell, eNodeB in case of 4G/LTE), the cellular protocol stacking
is translated into GTP *without breaking the end-to-end tunnel*.  So
intermediate nodes just perform some specific relay function.

At some point the GTP packet ends up on the so-called GGSN (GSM/UMTS)
or P-GW (LTE), which terminates the tunnel, decapsulates the packet
and forwards it onto an external packet data network.  This can be
public internet, but can also be any private IP network (or even
theoretically some non-IP network like X.25).

You can find the protocol specification in 3GPP TS 29.060, available
publicly via the 3GPP website at http://www.3gpp.org/DynaReport/29060.htm

A direct PDF link to v13.6.0 is provided for convenience below:
http://www.etsi.org/deliver/etsi_ts/129000_129099/129060/13.06.00_60/ts_129060v130600p.pdf

Linux GTP-U 모듈

커널 모듈은 터널 종단점의 사용자 평면을 구현합니다. 단말이 보낸 uplink GTP-U 패킷을 decapsulation하고, 외부 패킷망에서 받은 원시 IP 패킷을 단말 방향 downlink GTP-U로 encapsulation합니다.

모듈은 사용자 IP payload를 운반하는 GTP-U만 처리하고 터널 생성과 해제를 신호하는 GTP-C 제어 평면은 구현하지 않습니다. 따라서 완전한 GGSN/P-GW를 만들려면 사용자 공간 프로그램이 GTP-C를 처리하고 커널 GTP-U 모듈의 netlink 인터페이스로 데이터 경로를 설정해야 합니다.

PPPoE나 L2TP처럼 사용자 공간 데몬은 터널 설정과 인증을 맡고 커널은 데이터 평면을 가속합니다. 즉 GTP User Plane은 커널 가속 경로, GTP Control Plane은 사용자 공간 경로를 지납니다.

The Linux GTP tunnelling module
===============================

The module implements the function of a tunnel endpoint, i.e. it is
able to decapsulate tunneled IP packets in the uplink originated by
the phone, and encapsulate raw IP packets received from the external
packet network in downlink towards the phone.

It *only* implements the so-called 'user plane', carrying the User-IP
payload, called GTP-U.  It does not implement the 'control plane',
which is a signaling protocol used for establishment and teardown of
GTP tunnels (GTP-C).

So in order to have a working GGSN/P-GW setup, you will need a
userspace program that implements the GTP-C protocol and which then
uses the netlink interface provided by the GTP-U module in the kernel
to configure the kernel module.

This split architecture follows the tunneling modules of other
protocols, e.g. PPPoE or L2TP, where you also run a userspace daemon
to handle the tunnel establishment, authentication etc. and only the
data plane is accelerated inside the kernel.

Don't be confused by terminology:  The GTP User Plane goes through
kernel accelerated path, while the GTP Control Plane goes to
Userspace :)

The official homepage of the module is at
https://osmocom.org/projects/linux-kernel-gtp-u/wiki

지원 사용자 공간 프로그램

문서 작성 시점에 Linux 커널 GTP-U netlink를 사용할 수 있는 자유 소프트웨어 GTP-C 구현은 C로 작성한 고전 2G/3G GGSN인 OpenGGSN과 Erlang으로 작성한 GGSN/P-GW인 ergw가 있습니다. 각 프로젝트 링크는 원문에 보존되어 있습니다.

Userspace Programs with Linux Kernel GTP-U support
==================================================

At the time of this writing, there are at least two Free Software
implementations that implement GTP-C and can use the netlink interface
to make use of the Linux kernel GTP-U support:

* OpenGGSN (classic 2G/3G GGSN in C):
  https://osmocom.org/projects/openggsn/wiki/OpenGGSN

* ergw (GGSN + P-GW in Erlang):
  https://github.com/travelping/ergw

libgtpnl 라이브러리

`libgtpnl`은 `libmnl`을 기반으로 커널 GTP 모듈의 netlink 인터페이스를 C API로 제공하는 사용자 공간 라이브러리입니다. 원문은 Osmocom 저장소 링크를 안내합니다.

Userspace Library / Command Line Utilities
==========================================

There is a userspace library called 'libgtpnl' which is based on
libmnl and which implements a C-language API towards the netlink
interface provided by the Kernel GTP module:

http://git.osmocom.org/libgtpnl/

프로토콜 버전

GTP-U에는 GSM TS 09.60의 v0과 3GPP TS 29.281의 v1이 있으며 커널 모듈은 둘 다 구현합니다. v0은 legacy이며 최신 3GPP 규격에서는 폐기되었습니다. GTP-U는 UDP로 PDU를 운반합니다. 이 절은 수신 포트를 v1-U 2151, v0-U 3386으로 기록하며, 뒤의 아키텍처 절은 v1-U 포트를 2152로 기록하므로 구현과 최신 규격을 확인할 때 이 차이에 주의해야 합니다.

GTP-C에는 v0, v1, v2가 있지만 커널은 GTP-C를 구현하지 않으므로 버전 처리는 사용자 공간 제어 평면 구현의 책임입니다.

Protocol Versions
=================

There are two different versions of GTP-U: v0 [GSM TS 09.60] and v1
[3GPP TS 29.281].  Both are implemented in the Kernel GTP module.
Version 0 is a legacy version, and deprecated from recent 3GPP
specifications.

GTP-U uses UDP for transporting PDUs.  The receiving UDP port is 2151
for GTPv1-U and 3386 for GTPv0-U.

There are three versions of GTP-C: v0, v1, and v2.  As the kernel
doesn't implement GTP-C, we don't have to worry about this.  It's the
responsibility of the control plane implementation in userspace to
implement that.

IPv6 지원 상태

3GPP 규격은 내부 사용자 IP 계층과 외부 전송 계층 모두 IPv4 또는 IPv6를 사용할 수 있다고 정합니다. 그러나 이 문서의 커널 모듈은 사용자 IP payload와 외부 IP 계층 어느 쪽에도 IPv6를 지원하지 않는다고 명시하며 기여를 요청합니다.

IPv6
====

The 3GPP specifications indicate either IPv4 or IPv6 can be used both
on the inner (user) IP layer, or on the outer (transport) layer.

Unfortunately, the Kernel module currently supports IPv6 neither for
the User IP payload, nor for the outer IP layer.  Patches or other
Contributions to fix this are most welcome!

커뮤니티와 역사

커널 GTP 모듈 사용과 개발 논의는 `osmocom-net-gprs` 메일링 리스트에서 하고, Osmocom 프로젝트의 Kernel GTP-U issue tracker에 문제를 기록합니다. 주소와 구독 및 tracker 링크는 원문에 있습니다.

Harald Welte가 2012년에 모듈을 시작했고 Pablo가 완성을 시도했지만 사용자 관심 부족으로 병합되지 못했습니다. 2015년 Andreas Schultz가 많은 버그를 고치고 기능을 확장해 mainline 반영을 추진했으며 Linux 4.7.0에 병합되었습니다.

Mailing List
============

If you have questions regarding how to use the Kernel GTP module from
your own software, or want to contribute to the code, please use the
osmocom-net-grps mailing list for related discussion. The list can be
reached at [email protected] and the mailman
interface for managing your subscription is at
https://lists.osmocom.org/mailman/listinfo/osmocom-net-gprs

Issue Tracker
=============

The Osmocom project maintains an issue tracker for the Kernel GTP-U
module at
https://osmocom.org/projects/linux-kernel-gtp-u/issues

History / Acknowledgements
==========================

The Module was originally created in 2012 by Harald Welte, but never
completed.  Pablo came in to finish the mess Harald left behind.  But
doe to a lack of user interest, it never got merged.

In 2015, Andreas Schultz came to the rescue and fixed lots more bugs,
extended it with new features and finally pushed all of us to get it
mainline, where it was merged in 4.7.0.

GTP-U 엔터티와 터널 식별

GTP-U PDU는 UDP로 전송되며 이 절에서는 수신 포트를 v1-U 2152, v0-U 3386으로 명시합니다. IP 주소 하나에는 하나의 GTP-U 엔터티, 즉 SGSN/GGSN/S-GW/PDN-GW 인스턴스만 있으며 TEID는 그 엔터티 안에서 고유합니다.

목적지 포트가 고정이므로 송신 터널은 원격 IP와 TEID로 정의됩니다. 송신 쪽 source IP와 port는 터널 식별에 의미가 없고 언제든 바뀔 수 있습니다. 수신 쪽 로컬 엔터티는 로컬 목적지 IP와 TEID로 정해지며 원격 source IP와 port 역시 바뀔 수 있습니다.

TS 29.281은 TEID가 서로 다른 사용자, 패킷 프로토콜, QoS 수준을 multiplex한 입력 트래픽을 user plane 엔터티로 demultiplex한다고 설명합니다. 원격 두 종단점이 같은 TEID를 쓰지 않아야 하지만 이동성 절차의 data forwarding은 예외이며, 이 때문에 한 GTP-U 엔터티가 여러 또는 알 수 없는 peer에서 온 같은 TEID 트래픽을 받아야 할 수 있습니다. 따라서 수신 터널은 source IP가 아니라 TEID만으로 식별합니다.

Architectural Details
=====================

Local GTP-U entity and tunnel identification
--------------------------------------------

GTP-U uses UDP for transporting PDU's. The receiving UDP port is 2152
for GTPv1-U and 3386 for GTPv0-U.

There is only one GTP-U entity (and therefore SGSN/GGSN/S-GW/PDN-GW
instance) per IP address. Tunnel Endpoint Identifier (TEID) are unique
per GTP-U entity.

A specific tunnel is only defined by the destination entity. Since the
destination port is constant, only the destination IP and TEID define
a tunnel. The source IP and Port have no meaning for the tunnel.

Therefore:

  * when sending, the remote entity is defined by the remote IP and
    the tunnel endpoint id. The source IP and port have no meaning and
    can be changed at any time.

  * when receiving the local entity is defined by the local
    destination IP and the tunnel endpoint id. The source IP and port
    have no meaning and can change at any time.

[3GPP TS 29.281] Section 4.3.0 defines this so::

  The TEID in the GTP-U header is used to de-multiplex traffic
  incoming from remote tunnel endpoints so that it is delivered to the
  User plane entities in a way that allows multiplexing of different
  users, different packet protocols and different QoS levels.
  Therefore no two remote GTP-U endpoints shall send traffic to a
  GTP-U protocol entity using the same TEID value except
  for data forwarding as part of mobility procedures.

The definition above only defines that two remote GTP-U endpoints
*should not* send to the same TEID, it *does not* forbid or exclude
such a scenario. In fact, the mentioned mobility procedures make it
necessary that the GTP-U entity accepts traffic for TEIDs from
multiple or unknown peers.

Therefore, the receiving side identifies tunnels exclusively based on
TEIDs, not based on the source IP!

APN과 네트워크 장치

GTP-U 드라이버는 Gi/SGi 인터페이스마다 Linux 네트워크 장치를 만듭니다. 3GPP가 Gi/SGi reference point를 interface라고 부르지만 GGSN/P-GW가 하나만 가질 수 있다는 뜻은 아닙니다. Gi/SGi는 GTP-U 기반 3GPP packet domain과 IP 기반 네트워크 사이의 interworking 지점이며 규격은 그 수를 제한하지 않습니다.

TS 29.061은 APN으로 특정 Gi/SGi 인터페이스를 선택한다고 설명합니다. 각 사설망이 자체 주소를 관리하면 주소 범위가 겹칠 수 있으므로 GGSN/P-GW와 각 사설망 사이에 논리적으로 분리된 연결이 필요합니다. 이때 IP 주소만은 고유하지 않을 수 있지만 APN과 IPv4 주소 또는 IPv6 prefix의 쌍은 고유합니다. 겹치는 주소를 지원하려고 각 APN을 별도의 Gi/SGi 네트워크 장치에 매핑합니다.

APN은 순수한 GTP-C 제어 평면 개념입니다. GTP-U 패킷에는 TEID만 있고 커널 데이터 평면은 네트워크 장치를 압니다. UE 송신 매핑은 `network device + MS IP -> Peer IP + Peer TEID`, 수신 매핑은 `local GTP-U IP + TEID -> network device`입니다. 받은 T-PDU를 장치에 주입하기 전에는 MS IP가 PDP context에 기록된 IP와 일치하는지도 검사합니다.

APN vs. Network Device
======================

The GTP-U driver creates a Linux network device for each Gi/SGi
interface.

[3GPP TS 29.281] calls the Gi/SGi reference point an interface. This
may lead to the impression that the GGSN/P-GW can have only one such
interface.

Correct is that the Gi/SGi reference point defines the interworking
between +the 3GPP packet domain (PDN) based on GTP-U tunnel and IP
based networks.

There is no provision in any of the 3GPP documents that limits the
number of Gi/SGi interfaces implemented by a GGSN/P-GW.

[3GPP TS 29.061] Section 11.3 makes it clear that the selection of a
specific Gi/SGi interfaces is made through the Access Point Name
(APN)::

  2. each private network manages its own addressing. In general this
     will result in different private networks having overlapping
     address ranges. A logically separate connection (e.g. an IP in IP
     tunnel or layer 2 virtual circuit) is used between the GGSN/P-GW
     and each private network.

     In this case the IP address alone is not necessarily unique.  The
     pair of values, Access Point Name (APN) and IPv4 address and/or
     IPv6 prefixes, is unique.

In order to support the overlapping address range use case, each APN
is mapped to a separate Gi/SGi interface (network device).

.. note::

   The Access Point Name is purely a control plane (GTP-C) concept.
   At the GTP-U level, only Tunnel Endpoint Identifiers are present in
   GTP-U packets and network devices are known

Therefore for a given UE the mapping in IP to PDN network is:

  * network device + MS IP -> Peer IP + Peer TEID,

and from PDN to IP network:

  * local GTP-U IP + TEID  -> network device

Furthermore, before a received T-PDU is injected into the network
device the MS IP is checked against the IP recorded in PDP context.