[PATCH net-next v3 1/8] gtp: add documentation

The GTP-U implementation in not only driven by 3GPP TS 29.281, but also by the requirements of the 3GPP network entities that use it. This document tries to explain and clarify some design decision and their origins. Signed-off-by: Andreas Schultz <aschultz(a)tpip.net> --- Documentation/networking/gtp.txt | 112 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 Documentation/networking/gtp.txt diff --git a/Documentation/networking/gtp.txt b/Documentation/networking/gtp.txt new file mode 100644 index 0000000..cefd983 --- /dev/null +++ b/Documentation/networking/gtp.txt @@ -0,0 +1,112 @@ +Note: this document contain some forward looking statements and does + not (yet) reflect the implementation. This is done to motivate + and explain some of the changes to come. + + This note will be removed once the implementation matches this + document. + +General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTP-U) +========================================================================= + +The GTP-U protocol is a tunnelling protocol used in public land mobile networks +[PLMN]. It is always use together with a user space control instance implementing +a 3GPP network entity (e.g. GGSN, SGSN, PDN-GW, S-GW). + +The protocol is specified for version 0 in [GSM 09.60] and for version 1 in +[3GPP TS 29.281]. However, the functionality defined in those documents has +always to be taken in relation of the functional 3GPP entity that is using it. + +The rest of document is focusing on version 1 of the protocol. GTPv1 to GTPv0 +interworking and the use of GTPv0-U in general has be depreciated from 3GPP Rel8 +onward [3GPP TS 29.060]. + +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 therefor 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 TEID's from multiple or unknown peers. + +Therefor the receiving side only identifies tunnels based on TEID's, not based +on the source 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. + +References: +----------- + +[PLMN] https://en.wikipedia.org/wiki/Public_land_mobile_network +[3GPP TS 29.060] http://www.etsi.org/deliver/etsi_ts/129000_129099/129060/13.06.00_60/ts_129… +[3GPP TS 29.061] http://www.etsi.org/deliver/etsi_ts/129000_129099/129061/13.06.00_60/ts_129… +[3GPP TS 29.281] http://www.etsi.org/deliver/etsi_ts/129200_129299/129281/13.02.00_60/ts_129… +[GSM 09.60] http://www.etsi.org/deliver/etsi_ts/101300_101399/101347/06.13.00_60/ts_101… -- 2.10.2