12. GTP
12.1. GTP Uplink
SR OS supports subscriber traffic forwarding over an uplink GTP tunnel towards a GGSN or P-GW. This requires a per-subscriber GTP tunnel based on authentication to be configured. Each subscriber may access only a single APN. Both GTPv1 (Gn) and GTPv2 (S2a/S2b) are supported. A single primary PDP context per subscriber is supported on the Gn interface (3GPP TS 29.060 Release 8) from SR OS to the GGSN. A single default-bearer per subscriber is supported on the S2b interface (3GPPTS 29.274 Release 10), and S2a interface (3GPP TS 29.274 Release 11) from SR OS to the P-GW.
12.1.1. Identification Attributes
GTP requires at least an IMSI and an APN to set up a connection. The IMSI is required to identify the user, and the APN is required to identify the network the user is connecting to.
There is a 1:1 relationship between IMSI and subscriber ID. It is possible to provision only one of these and the other will be accepted as the same value. If both are provisioned, they must be equal. Therefore, it is not possible to set up more than one GTP tunnel per subscriber.
APN can be provisioned explicitly per subscriber, or a default APN can be provisioned per VRF. If this APN does not contain an Operator Identifier (OI), it will be added automatically based on the IMSI.
12.1.2. P-GW/GGSN Selection
The initial address of the P-GW or GGSN can either be provided during authentication, or, in absence of authentication, resolved dynamically via DNS. For DNS, a FQDN is generated based on the APN as specified in 3GPP 29.303. This FQDN always consists of both the Network-ID (NI) portion and the OI portion, and is formatted as NI.apn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org. The system will perform an S-NAPTR lookup with this FQDN.
When multiple GW addresses are returned as part of this lookup, load-balancing is performed according to regular NAPTR and SRV rules. If no addresses are returned, or the S-NAPTR lookup failed, the system tries a regular A host lookup with the same FQDN. In this case, SR OS load-balances over multiple GW addresses using a round-robin mechanism. DNS servers can be configured per VPRN, except for the base router where the servers defined in the BOF are used.
After initial GTP setup, it is possible for the P-GW or GGSN to return another address as a GTP-C or GTP-U destination. All data plane traffic is sent using the signaled GTP-U address. All subsequent control plane traffic is forwarded to the new GTP-C address.
The VRF used for GTP tunneling can be selected via provisioning a retain service ID for the subscriber. The source IP for GTP tunneling is taken from a loopback interface with the name system in that VRF. If no such interface is present, the tunnel setup fails.
12.1.3. Configuration
Profiles with signaling-related configuration per mobile gateway can be created locally on the SR OS router. These profiles include configuration for the interface type used between the router and the mobile gateway, path management parameters, retransmission parameters, and default values for GTP information elements such as AMBR. Each profile can be mapped to a specific GW IP address or subnet per VRF. Most of the per-session/context parameters can be overridden via RADIUS authentication. Refer to the 7750 SR and VSR RADIUS Attributes Reference Guide for more information.
12.1.4. QoS Support
SR OS provides appropriate traffic treatment and remarking based on DSCP bits in the outer and inner header in GTP packets.
Downstream from PGW/GGSN, the DSCP bits from the outer header in a GTP packet can be mapped to a forwarding class on network ingress, which can be preserved through the chassis as the packet passes to the egress IOM. On egress, reclassification can be done based on either the inner or outer DSCP bits, depending on the configuration value of the use-ingress-l2tp-dscp option in the SLA profile.
In the upstream direction, regular ESM FC classification is used. This FC is carried through the IOM to the egress complex. In the egress complex, this FC can be used for remarking of the outer DSCP values.
DSCP and default FC values for egress GTP-C packets can be configured under sgt-qos.
It is possible to signal the subscriber’s aggregate rate or the rate of a specific scheduler in the downlink AMBR IE in both GTPv1-C and GTPv2-C. This uses the report-rate configuration of the SLA profile; the pppoe-actual-rate and rfc5515-actual-rate values are not applicable for GTP. This value can be subtracted with a value signaled during authentication to take into account an average use for selective breakout.
Other signed QoS IE values are taken from static configuration or values signaled in authentication.
12.1.5. GTP Session Hold
Deletion of an IPoE or PPPoE session also triggers deletion of any corresponding GTP sessions. This deletion is subject to a configurable hold time. When the subscriber returns with the same GGSN/P-GW parameters within the hold time, the GTP connection will not be re-signaled. This avoids releasing resources (such as IP addresses) too quickly on the GGSN/P-GW. This is useful in the following cases:
- Non-seamless control plane mobility with WLAN-GW. Due to SHCV usage, the UE will be completely removed, but should reconnect quickly, preferably with the same IP address. Having a short hold time avoids the P-GW releasing the IP address.
- IP handover from WiFi-GW to RAN. In some cases, WiFi connectivity is lost before wireless data connectivity is established. By holding the GTP session active on the WLAN-GW, the IP address is also held on the GGSN/P-GW until the RAN connection is complete.
While a GTP session is in hold, all downstream traffic is dropped, but no error indication messages are sent.
12.1.6. Selective Breakout
This feature adds support for selecting a subset of traffic from a host (via IP filter) for local forwarding, while tunneling the remaining traffic to GGSN/PGW. This allows selected traffic to bypass the mobile packet core. The IP address for the host still comes from the GGSN/PGW during GTP session setup. Therefore, the selected traffic for local breakout from SR OS requires NAT functionality in order to draw the return traffic back to the router. To support address overlap within GTP, the NAT functionality is L2-aware. The selection of traffic for local breakout (local forwarding and NAT) is based on a net action in an upstream Ip filter applied to the host.
Selective breakout can be enabled on a per-host basis via RADIUS VSA (Alc-GTP-Local-Breakout) in access-accept. It is not possible to change this during a host’s lifetime, such as via CoA. AA functionality is supported for local breakout traffic. Also, LI (after NAT) is supported for local breakout traffic, and is enabled via existing secure CLI, as stated in the OAM and Diagnostics Guide.
On traffic ingress from the host UE, normal ESM host lookup and CAM lookup with the ingress host filter is performed. If there is a match in the filter indicating “gtp-local-breakout”, the traffic is forwarded within the chassis to an ISA-BB, where is it subjected to L2-aware NAT function, and afterwards is forwarded using regular routing in the NAT outside VRF. The inside IP address is the address returned in GTP, and may not match a NAT L2-aware inside prefix. The outside IP is an address belonging to the NAT outside IP address range on the ISA. If the filter action results in a “forward” action (default), the traffic is GTP-tunneled without performing NAT functionality. The traffic received from the network can be a normal L3 packet or a GTP encapsulated packet. The normal Layer 3 packet is expected to be destined to the NAT outside IP and is normally routed to the NAT ISA.
By default, per-host accounting includes counters that are aggregated across GTP and local breakout traffic. Separate counters can be obtained by directing the GTP and local breakout traffic into different queues associated with the corresponding ESM host based on QoS IP classification. NAT information (outside IP and port range) associated with an ESM host subjected to selective breakout is included in accounting-updates.
Selective breakout is supported for IPv4 only.
12.1.7. IPoE Support
A GTPv2 session or GTPv1 PDP context is set up when IPoE session authentication includes any GTP parameters. The GTP session provides the IPv4 and IPv6 address used for the connecting host. Currently only DHCPv4 and SLAAC are supported to deliver these addresses back to the client. If DHCP is used, SR OS automatically derives a standards-compliant subnet mask and default GW from the signaled IP address. It is important that all GTP subscribers are in a shared split-horizon domain and that there is no Layer 2 switching between GTP subscribers. Only a single IPoE session is supported per GTP subscriber. Additionally, DNS and NBNS can be signaled via GTP (A)PCO and reflected in DHCP, SLAAC, and stateless DHCPv6. Control plane packets such as DHCP and ICMPv6 RS are always terminated on the BNG and are not forwarded over GTP.
Figure 189 shows a sample IPoE session for GTP.
Figure 189: IPoE Session
GTP without an IPoE session is available for IPv4 DHCP leases only for backwards compatibility. It may not be used for new deployments; existing deployments should move to the IPoE session concept.
12.1.8. PPPoE Support
A GTPv2 session or GTPv1 PDP context is set up when PPPoE session authentication includes any GTP parameters. The GTP session provides the IPv4 and IPv6 address to be used for the connecting host. IPCP and IPv6CP with SLAAC are supported to signal these addresses to the client. Only a single PPPoE session is supported per GTP subscriber. Additionally, DNS and NBNS can be signaled via GTP (A)PCO and reflected in IPCP, SLAAC, and stateless DHCPv6. Control plane packets such as ICMPv6 RS are always terminated on the BNG and are not forwarded over GTP.
12.2. GTP Access
SR OS supports TPSDA functionality over GTP access funnels towards eNodeBs using the S11 (GTPv2-C) and S1-U (GTP-U) interfaces toward MME and eNodeB. In this setup, the SR OS router performs the roles of BNG, SGW, and PGW. Both IPv4 and IPv6 connectivity over GTP is supported. GTP session authentication can be performed using LUDB, RADIUS, or NASREQ. GTP access termination is built on top of forwarding path extensions.
Figure 190: GTP Access
12.2.1. GTP Termination
GTP S11 termination can be enabled on interfaces in the base router and VPRNs. The configuration is linked to an APN policy that lists all supported APNs and the authentication mechanism (for example, LUDB or RADIUS) to be used per APN. The configured APN string should match the value signaled in GTP; however, fallback configuration is supported for any unknown APNs.
A GTP peer profile defines certain signaling parameters such as TTL values, keepalive timers, retransmit timers, and default values for certain information elements. By default, an automatically-created profile with the name “default_s11” is used. A more specific profile can be configured and mapped to a peer by a per-VRT mapping of IP address or prefix to that profile.To map all peers within the same VRF to the same profile, it is possible to use prefix 0.0.0.0/0.
When an S11 session is set up, the accompanying S1-U bearer is terminated in the same VRF, but it is directly linked to a group interface in either the same or a different VRF. A default group interface can be configured per APN, which can be overridden during S11 session authentication. The used group interfaces are of type gtp and require an FPE construct to operate. The traffic takes two passes through the forwarding plane. For upstream data, the GTP-U header is stripped in the first pass and inserted into the group interface for regular ESM processing, based on existing IPoE functionality, in the second pass. For downstream data, regular ESM processing is performed in the first pass, then the traffic egresses over the group interface and GTP-U encapsulation occurs in the second pass.
12.2.1.1. Multiple APNs
SR OS supports multiple APN connectivity for the same IMSI. When an additional session setup with a different APN is triggered, the system will treat this as a completely new session that goes through APN selection and authentication again. PDN session user plane can be instantiated in the same VRF as previous sessions or in different VRFs. Sessions for the same IMSI can belong to the same ESM subscriber by using the same subscriber-id, but are not required to do so. S11 messages defined with UE granularity in 3GPP TS 29.274 will apply to all sessions of the same IMSI.
12.2.2. GTP Session Setup
When a GTPv2 Create Session Request message arrives, SR OS looks up the required authentication mechanism in the applicable APN policy. To aid in the identification process, both RADIUS and NASREQ can be configured with GTP specific include attributes such as IMSI, MSISDN, and IMEI. If a PAP message is present in the PCO IE of the Create Session request, that username and password is used for authentication; otherwise the system falls back to IMSI as the username and password configured in the policy.For LUDB-based authentication, it is recommended to use derived-id for identification values.
Authentication is performed per GTP session and not per IP stack (host). Therefore, the initial authentication returns parameters for all stacks that need to be set up.
After a successful authentication, a Create Session Response message is sent, which includes all relevant parameters including assigned addresses, DNS servers, and applicable QoS values. The Create Session Response message is followed by an initial Modify Bearer Request message. When the host setup is completed with a Modify Bearer Response message, downstream data can then flow towards the eNodeB. If IPv6 is enabled, an unsolicited RA is sent.
Figure 191 shows a high-level overview of the setup call flow using RADIUS authentication.
Figure 191: High-level Example of GTP Access Setup
12.2.2.1. Supported IP Stacks
IPv4 and IPv6 SLAAC are supported via dual-stack bearers. IP addresses can be provisioned during authentication or through Local Address Assignment. Any DNS (IPv4 and IPv6) and NBNS (IPv4 only) addresses are signaled in the PCO IE. An unsolicited RA is sent after the first Modify Bearer Request message is received. An RS-triggered RA is also supported and either RA can be configured to contain DNS servers. Stateless DHCPv6 can also be used to retrieve the DNS configuration.
12.2.3. QoS
ESM QoS using subscriber and SLA profiles also applies to GTP hosts. To align with 3GPP signaling, it is possible to enable the ingress or egress report-rate in the SLA profile. When specified, the signaled UL/DL APN-AMBR values are taken from the referenced report rate object (that is, the scheduler or subscriber aggregate rate). If this mechanism is not used, these values can be taken from AAA signaling (VSA 3GPP-GPRS-Negotiated-QoS-Profile in RADIUS). As a last resort, default values can be found in the peer profile. Similarly, QCI and ARP values can be retrieved from AAA and have default values in the peer profile.
SR OS maintains the FC classification and in- and out-of-profile markings consistent over the two dataplane passes. The egress and ingress QoS policies in the SLA profile should be configured with the following considerations.
- Enable de-mark for access egress and map each FC to the dot1p as defined in Table 166, thus ensuring that the GTP-U encapsulated packet uses the same classification as the ESM context.
- Perform classification for access ingress based on dot1p as defined in Table 166 and enable in-profile and de-1-out-of-profile for each FC, thus ensuring that the ESM context uses the same classification as determined for the GTP-U packet. However, a different classification scheme can be used, if required; for example, based on DSCP or IP criteria.
Table 166: FC to dot1p Mapping
FC | dot1p |
be | 0 |
l2 | 1 |
af | 2 |
l1 | 3 |
h2 | 4 |
ef | 5 |
h1 | 6 |
nc | 7 |
12.2.4. Multicast
GTP supports the reception of MLD and IGMP, with either a redirect-interface or per-host replication enabled. Per-SAP replication is not applicable and is ignored.
12.3. DHCP over GTP-u
A routed gateway (RG) with a fixed-wireless WAN link can get an IPv4 address and an IPv6 /128 address using DHCPv4 and DHCPv6 IA_NA, respectively. The RG can also get an IPv6 prefix using DHCPv6 PD for it's LAN. A fixed-wireless RG can be an RG with integrated LTE or 5G modem, or connected to an external 5G modem using Ethernet or WLAN. Once the default bearer and PDU session is created using NAS signaling, DHCP messages can be forwarded by the RG (with integrated modem), or the standalone modem (referred to as user equipment (UE)), over the default bearer towards the BNG, which functions as fixed-wireless gateway and terminates the GTP tunnel. DHCP messages are received and sent by the BNG over the GTP tunnel.
12.3.1. Address Management Related PCOs
Without DHCPv4, the fixed-wireless RG can only get an IPv4 address during initial attach using NAS SM (session management) procedures. As part of NAS signaling, the BNG acting as a fixed-wireless gateway allocates an IPv4 address and returns it in a PDN address allocation (PAA) IE in the GTP session creation response.
- If an RG requires IPv4 address allocation using DHCPv4 instead of address allocation during initial attach using NAS signaling, then it can signal a PCO "deferred address allocation" (value 0x000b) in GTP session setup. If this PCO is present in GTP setup request, then the BNG will not allocate an IPv4 address during GTP session setup. The GTP setup will complete with IPv4 address of 0.0.0.0 returned in a PAA to the RG. The BNG will only allocate and assign an IPv4 address using subsequent DHCPv4 from the RG, which is received over the GTP-u tunnel (S1-U interface) on the BNG.
- If PCO "allocation via NAS" (value 0x000a) is present in a GTP setup request, then the IPv4 address is allocated during GTP setup and returned in a GTP session creation response.
- If neither PCO is present, then by default, anIPv4 address is allocated on the GTP setup, and returned in the GTP session creation response. This can be overridden using the skip-gtp-ipv4-alloc CLI command. In this case, no IPv4 address is allocated during GTP setup and is only allocated using a subsequent DHCPv4 exchange.
The skip-gtp-ipv4-alloc configuration is a per-APN configuration. This can be overridden on a per-subscriber basis using a RADIUS VSA (Alc-Gtp-Skip-Ipv4-Alloc-Override).
12.3.2. Address Allocation Modes
DHCPv6 IA_NA can be used for IPv6 WAN address assignment. IPv6 WAN prefix can also be supported using SLAAC.
For DHCPv4, the following address allocation modes are supported.
- DHCPv4 proxy. The IPv4 address offered in DHCPv4 from the RG can be provided from AAA during initial authentication in the framed-IP-address RADIUS attribute.
- DHCPv4 relay to a local or external DHCPv4 server for IPv4 address allocation. The pool can be provided from AAA during initial authentication in the framed-pool RADIUS attribute, and can be added in the relayed DHCP packets with a DHCP Option 82 vendor-specific sub-option.
For DHCPv6, the following address allocation modes are supported.
- DHCPv6 proxy. The /128 IPv6 address for RG WAN using DHCPv6 IA_NA can be provided from AAA during initial authentication in Alc-IPv6-address VSA. The PD prefix requested by RG using DHCPv6 IA_PD can be provided from AAA in the Delegated-IPv6-Prefix RADIUS attribute.
- DHCPv6 relay to a local or external DHCPv6 server for IPv6 address and prefix allocation. The pool for /128 IPv6 address allocation for DHCPv6 IA_NA can be provided by AAA during initial authentication in the framed-ipv6-pool attribute. Pool for PD prefix can be provided by AAA during initial authentication in the Alc-Delegated-IPv6-Pool VSA. These are signaled by DHCPv6 relay to the server.
Authentication is performed only during GTP session setup. All the RADIUS attributes related to DHCP and IP stack (host) setup are received during this authentication. No subsequent authentication is performed on the receiving DHCP. A single IPoE session containing all the hosts (DHCPv4, DHCPv6 IA_NA, and SLAAC) are created per GTP session. PD prefix should be configured to be added as a managed-route if both DHCPv6 IA_NA and SLAAC are in use and creating respective hosts.
Figure 192 shows the call flow for GTP session setup, subsequent DHCP exchange, and host creation in case of RG with a standalone modem (user equipment is noted as UE in the diagram).
Figure 192: Call Flow for GTP Session Setup
DHCP over GTP-u tunnel is not supported in conjunction with bonding (hybrid-access).
DHCP over GTP-u tunnel is supported in conjunction with multiple APNs. The APNs can have different address management (for example, in case of two APNs). It is possible to use WAN address assignment using NAS for one APN and DHCPv4 for another APN.
Broadcast flag should not be set in DHCP messages from the client.
12.4. GTP Peering
SR OS tracks each GTP-C peer for which it has at least a single GTP session or PDP context active. It tracks the peer’s operational state with the following mechanisms:
- Regular GTP echo messages and parameters are configurable on a per-mgw-profile basis. When the echo mechanism fails, the peer is considered down.
- Active route entries towards the peer are monitored. If no route towards the peer is available, the peer is considered down.
- The Restart counter value of the peer is monitored. This is initially learned when the first active session or context is created. If the value is not available in regular messaging, an echo request is sent out immediately to learn the correct value. If the Restart counter is incremented during any later messaging exchange, the peer is considered rebooted.
When a peer is considered down or rebooted, all active GTP sessions and PDP contexts are forcefully removed.
SR OS also keeps a recovery counter in a persistent state, and increments this value on every reboot. This value is kept in the restcntr.txt file on CF3 and may not be modified or removed. This value is included in every control plane message.
SR OS responds to GTP echo messages for both active peers and unknown sources. This can be restricted using CPM filters if required. An incoming echo request from an unknown source will not create a peer; this can only be done by setting up GTP sessions or PDP contexts.