HUAWEI UGW9811 Unified Gateway V900R012C10 Feature Description (STO Optional Feature)
HUAWEI UGW9811 Unified Gateway V900R012C10 Feature Description (STO Optional Feature)
HUAWEI UGW9811 Unified Gateway V900R012C10 Feature Description (STO Optional Feature)
V900R012C10
Feature Description (STO
Optional Feature)
Issue 02
Date 2015-07-15
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Website: http://www.huawei.com
Email: [email protected]
Contents
Availability
Involved NEs
Table 1-1 NEs involved in implementing the TCP Optimization feature on GPRS/UMTS
networks
Table 1-2 NEs involved in implementing the TCP Optimization feature on EPC networks
UE eNodeB/eAN MME S-GW/HSGW P-GW
- - - - √
In the preceding table(s), √ indicates that the NE is required, and - indicates that the NE is not required.
License Requirements
This feature is optional and requires a license. The license control item for this feature is
"82203723 PDP Context Numbers of Supporting TCP Optimization".
Summary
As carriers provide an increasing number of mobile broadband services, the requirements for
transmission resources are constantly on the rise. When the available transmission resources
do not meet the service requirements, subscribers have poor service experience. Most
applications on mobile broadband networks are based on the Transmission Control Protocol
(TCP) and TCP has low transmission efficiency. Therefore, enhancing TCP transmission
efficiency is an effective means of improving subscriber experience.
The TCP Optimization feature uses a number of techniques, including TCP transparent proxy,
skipping slow-start, fast retransmission and fast recovery, and TCP sender algorithm
optimization, to improve the TCP transmission efficiency and provide better service
experience, such as faster web page loading, faster downloads, and smoother streaming video.
Benefits
For... Benefits
Carriers Increased profitability and enhanced customer loyalty
More efficient use of network resources, especially air interface
resources
Subscribers Better service experience with less transmission delay
Description
Application Scenario
GPRS/UMTS Standard Networking and Typical EPC Networking are supported.
The TCP Optimization feature is supported for subscribers of GPRS/UMTS, EPC, and
CDMA2000 eHRPD networks.
Application scenario 1: Out-of-order packets, error packets, packet loss, or congestion on
air interfaces are the common causes of poor user experience. To increase the TCP
transmission efficiency and improve service quality, enable TCP optimization if one of
the following conditions is true:
− The packet loss rate between MSs/UEs and the UGW9811 exceeds 0.5%.
− The round trip time (RTT) between MSs/UEs and the UGW9811 exceeds 100 ms and
the RTT between MSs/UEs and service providers (SPs) exceeds 150 ms.
Of the network elements (NEs) between an MS/UE and an SP, the UGW9811 is the best
point where TCP optimization is implemented because:
1. The UGW9811 is at the halfway point of traffic transmission between an MS/UE and an
SP. Therefore, implementing TCP optimization on the UGW9811 is the most effective
means of shortening the transmission delay.
2. The UGW9811 has powerful processing capabilities and can meet GPRS/UMTS/EPC
networks' service acceleration requirements.
3. The UGW9811 stores diverse subscriber service information that can be used to
implement TCP optimization.
Application scenario 2: Enable TCP optimization to increase the TCP transmission
efficiency for specific services, address ranges, or subscriber groups.
The UGW9811 uses the following techniques to implement TCP optimization:
Figure 1-1 UGW9811 functioning as a TCP transparent proxy between an MS/UE and a server
When the UGW9811 functions as a TCP transparent proxy, it implements connection setup,
data transmission, and connection release for the MS/UE and server both. The MS/UE and
server are unaware of the TCP transparent proxy.
MSS Processing
You can run the tcp-mss command to configure an appropriate maximum segment size (MSS)
option in data packets to maximize the length of a data packet that can be transmitted over the
TCP connection without packet fragmentation. This technique increases the TCP transmission
efficiency.
The formula for calculating the MSS is: MSS = MTU - Tunnel encapsulation overhead - IP
header - TCP header.
MTU: The MTU on an Ethernet is by default 1500 bytes, but the MTU for Ethernet jumbo frames
may reach 9000 bytes. Before calculating the MSS, check the MTU of the link in use.
IP header: includes the fixed packet header (20 bytes for an IPv4 packet and 40 bytes for an IPv6
packet) and options (for an IPv4 packet) or extension header (for an IPv6 packet).
TCP header: includes a 20-byte fixed packet header and options whose maximum length is 40 bytes.
A SYN packet transmitted during TCP connection setup may contain an MSS option. The
MSS option indicates the maximum length of TCP packets received from the peer device. If
TCP packets are not fragmented, a larger MSS value is used to enable the transmission of a
larger data packet, which improves network resource utilization.
1. The UGW9811 can change the MSS value in a SYN packet to a smaller value so that the
packet is not fragmented after the packet is encapsulated with an IP header during E2E
transmission. This improves the TCP transmission efficiency.
The default Ethernet maximum transmission unit (MTU) is 1500 bytes, and the lengths
of an IP header and a TCP header are both 20 bytes if the headers do not contain option
fields. Therefore, the appropriate MSS value is 1460 (1500 - 20 - 20) in bytes. See
Figure 1-3.
RFC879 defines a default MSS of 536 bytes for TCP packets. The UGW9811 allows carriers to
configure the insertion of the MSS option for compatibility with old devices that do not support the
MSS option.
By configuring the MSS option, you can specify the largest possible data packets the TCP
connection transmits without fragmenting the packets. This improves the TCP transmission
efficiency.
Skipping Slow-Start
Slow-start is part of the TCP congestion control strategy. Slow-start is used in conjunction
with other algorithms to prevent network overload. Slow-start works by increasing the TCP
congestion window each time an acknowledgment is received. It increases the window size by
the number of segments acknowledged. This continues until either no acknowledgment is
received for a segment or a predetermined threshold value is reached.
You can run the skip-slow-start command to configure an appropriate slow-start threshold
and set the initial send window size to the slow-start threshold value so that the UGW9811
directly enters the congestion avoidance phase. This configuration increases the throughput
during the initial phase of TCP data transmission.
Fast Retransmission and Fast Recovery
In compliance with RFC5681 and RFC3782, the UGW9811 supports fast retransmission and
fast recovery, which improve the TCP transmission efficiency during light congestion.
TCP requires that, if a receiver receives out-of-order packets during data transmission, the
receiver should immediately reply with an ACK packet to the sender to notify the sender of
the expected data packets. If the sender receives three duplicate ACK packets, it determines
that packet loss has occurred and retransmits the lost data. After the TCP receiver
acknowledges the receipt of the lost data, the TCP sender enters the congestion avoidance
phase, which increases the transmission efficiency.
Fast retransmission and fast recovery are the basic mechanisms TCP senders use to implement
congestion control. Fast retransmission and fast recovery are enabled by default and are not
configurable. For details, see RFC5681 and RFC3782.
The UGW9811 supports selective acknowledgment (SACK). This technique enables TCP senders to
retransmit only the lost data rather than all the subsequent data following the acknowledged one, which
improves data transmission efficiency.
Enhancement
Dependency
Application Limitations
Separate SPUfs/SPUf1s must be deployed to implement the TCP Optimization feature.
This feature can be deployed only on the common group of an SPUf/SPUf1 in the
UGW9811 subrack.
The UGW9811 does not support TCP optimization for IPv6.
If a CDMA2000 eHRPD subscriber accesses an EPC network through the P-GW, the
UGW9811 does not support TCP optimization based on cell load.
Interaction with Other Features
Table 1-4 Interaction between the TCP Optimization feature and other features
Feature Interaction
GWFD-110222 Wireless If TCP optimization based on cell load is required, the
Optimization Based on Wireless Optimization Based on Cell Load Reporting function
Cell Load Reporting must be enabled.
Availability
Involved NEs
Table 1-5 NEs involved in implementing the Service Push Based on Content Insertion feature on
GPRS/UMTS networks
- - - √ √ √
Table 1-6 NEs involved in implementing the Service Push Based on Content Insertion feature on
EPC networks
- - - - √ √ √
In the preceding table(s), √ indicates that the NE is required, and - indicates that the NE is not required.
Summary
The Service Push Based on Content Insertion feature provides an add-on toolbar on the web
pages accessed by subscribers without changing the original contents of the web pages.
Subscribers can use the toolbar to query their data usage, receive data usage alerts, and
subscribe to data plans. Carriers can use the toolbar to promote services and push
advertisements and notifications to subscribers.
Service push based on content insertion may insert specific subscriber identifier information (IMSI or
MSISDN), which is required for subscriber authentication or service subscription, into packets that are
sent to the toolbar server, without changing subscribers' communication contents or communication
paths. When deploying service push based on content insertion, make sure that the corresponding
functions, including service subscription and unsubscription, are provided in compliance with the local
laws to allow subscribers the freedom to decide whether to use or stop using the service.
Benefits
For... Benefits
Carriers This feature enables carriers to provide diverse value-added
services to subscribers, thereby increasing the customer stickiness.
The toolbar service does not require software installation and can
be easily rolled out to a wide range of subscribers.
Subscribers Subscribers can use the toolbar to query their data usage and receive
data usage alerts, thereby avoiding hefty bills due to excessive data
usage.
Description
Network Structure
Figure 1-5 Networking diagram for the Service Push Based on Content Insertion feature
Table 1-7 Interfaces involved in implementing the Service Push Based on Content Insertion
feature
System Implementation
When a terminal accesses an HTTP service, the UGW9811 blocks the HTTP Get request that
matches specified local rules. Then, the UGW9811 constructs an HTTP 200 OK response that
carries a Toolbar URL and the original URL requested by the terminal and returns the HTTP
200 OK response to the terminal. After receiving the HTTP 200 OK response from the
UGW9811, the terminal accesses both the original URL and the Toolbar URL. The UGW9811
transparently transmits packets for the terminal, thereby allowing the subscriber to use the
toolbar service while accessing HTTP services.
The UGW9811 manages Toolbar servers using the IP farm mechanism. On the UGW9811,
multiple Toolbar servers are configured into an IP farm. All the Toolbar servers in an IP farm
use the same heartbeat detection interface to exchange heartbeat packets with the UGW9811.
Toolbar Servers in an IP farm can be configured to work in load-balancing mode. Three
load-balancing modes are available: round-robin, least-load, and least-recently-used.
For details about the IP farm mechanism, see GWFD-110209 Captive Portal.
If one or more fields in subscriber information need to be added to the HTTP packet header
and transferred to the Toolbar server, the UGW9811 supports the following modes:
HTTP header enrichment: supports the function of carrying information including but
not limited to the subscriber's IMSI, MSISDN, IMEI, and IP address.
IP farm: runs the ip (IP farm view) command to configure a redirection URL to carry a
subscriber's IMSI, MSISDN, IMEI, and IP address. An HTTP response (carrying the
redirection URL) sent from the UGW9811 to the subscriber and an HTTP request
reinitiated by the subscriber carry the subscriber information. This increases the risk that
the subscriber information will be illegally obtained and tampered with. Therefore, the IP
farm mode is not recommended.
The mode in which the toolbar icon is presented on the terminal is determined by the toolbar
template. The UGW9811 supports the function of loading specified templates to adapt to
different subscribers' requirements on the toolbar icon presence modes. For detailed
operations, contact Huawei technical support engineers.
Service Flow
In this example, a PCRF is deployed for implementing the toolbar service. If no PCRF is
available, toolbar service policies can be configured on the UGW9811.
1. The PCRF receives toolbar service subscription information of a subscriber from the
Provisioning, and uses an Re-Auth-Request (RAR) message to deliver a toolbar service
policy for the subscriber to the UGW9811 based on user, user group, service, data usage,
and/or time.
2. The UGW9811 installs the toolbar service policy and returns an Re-Auth-Answer (RAA)
message.
3. The terminal accesses HTTP services by sending an HTTP Get request.
4. The UGW9811 parses data packets. If a packet meets all of the following conditions, the
UGW9811 will proceed to 5.
− The toolbar timer expires. (The timeout period can be configured using the
action-interval command.)
− The packet is an HTTP Get request.
− The length of the URL carried in the packet is larger than 0 bytes and smaller than or
equal to 106 bytes.
To prevent repeated toolbar redirections of the subscriber's original packets, the UGW9811 adds an
redirection identifier to the HTTP 200 OK response to indicate that toolbar redirection has been
performed on the original URL. When the UGW9811 receives another HTTP Get request carrying an
URL on which toolbar redirection has been performed, the UGW9811 directly forwards the HTTP Get
request.
To prevent degradation of user experience due to frequent toolbar push, you can run the action-interval
command to configure an interval between toolbar operations on the UGW9811.
7. The terminal receives the HTTP 200 OK response and sends another HTTP Get request
to access the original URL.
8. The UGW9811 receives the HTTP Get request, checks the URL carried in the request,
and finds that toolbar redirection has been performed for the URL.
9. The UGW9811 forwards the HTTP Get request to the SP/CP.
10. The SP/CP returns an HTTP 200 OK response to the terminal.
11. The terminal receives the HTTP 200 OK response and sends an HTTP Get request to
access the Toolbar URL.
Whether 7 or 11 occurs first depends on the network congestion status. Either the HTTP 200 OK
response from the Toolbar server or the HTTP 200 OK response from the server at the original URL may
be received by the terminal first.
12. The UGW9811 receives the HTTP Get request, checks the Toolbar URL carried in the
request, and determines that toolbar push operations are not required for the request.
(You can run the l7-filter-list-binding command to specify HTTP Get requests that do
not require toolbar push operations.)
13. The UGW9811 forwards the HTTP Get request to the Toolbar server to obtain toolbar
service contents.
14. The Toolbar server returns an HTTP 200 OK response to the terminal.
Besides the preceding service flow, the Service Push Based on Content Insertion feature also
involves several other service flows, for example, canceling the toolbar service and pushing
data usage alerts through the toolbar. In these service flows, the interactions between the
UGW9811 and PCRF are basically the same, except that the PCRF delivers different policies.
Feature Enhancement
Table 1-8 Release history of the Service Push Based on Content Insertion feature
Dependency
Application Limitations
The toolbar service is available only when subscribers access HTTP services using the
GET method. Non-HTTP services (for example, MMS services) and HTTP services
using other methods (for example, the POST method) are not supported.
The toolbar service is not available for all types of terminals and browsers. For detailed
information, refer to the service capability of the toolbar server.
A URL with more than 106 bytes do not support toolbar insertion.
Downlink fragments with HTTP header fields do not support toolbar insertion.
If the same data flow matches both toolbar and FUI or matches both toolbar and URL
redirection, toolbar does not tale effect.
If the same data flow matches both toolbar and smart HTTP redirection, toolbar is
performed if the toolbar timer length specified using the action-interval command
expires; smart HTTP redirection is performed if the toolbar timer length does not expire.
If the same data flow matches both toolbar and one-shot redirection, one-shot redirection
and toolbar are performed in sequence.
If the same data flow matches both toolbar and captive portal, captive portal is
performed if both the toolbar timer length specified using the action-interval command
and the captive portal timer length specified using the captive-mode-threshold
command expire, and toolbar is performed if the toolbar timer length expires again.
Interaction with Other Features
Table 1-9 Interaction between the Service Push Based on Content Insertion feature and other
features
Feature Interaction
GWFD-110030 The toolbar service is available only when subscribers access
SA-Basic HTTP services using the GET method. Therefore, the SA-Basic
GWFD-110017 and SA-Web Browsing features must be enabled on the UGW9811
SA-Web Browsing so that the UGW9811 can identify the protocols and methods used
in services.
GWFD-110206 PCC The PCC Basic Function feature must be enabled if a PCRF is used
Basic Function to implement the Service Push Based on Content Insertion feature.
GWFD-110302 The function is supported only when flow-based charging is
Basic Content Based enabled.
Charging
Feature Interaction
GWFD-110216 If subscriber information needs to be transferred to the Toolbar
HTTP Header server, the HTTP header enrichment function can be used.
Enrichment
1.3 Security
1.3.1 GWFD-111608 Personal Application Protection
Applicable NEs
GGSN and P-GW
Availability
Involved NEs
Table 1-10 NEs involved in implementing the Personal Application Protection feature on
GPRS/UMTS networks
- - - √ √ √
Table 1-11 NEs involved in implementing the Personal Application Protection feature on EPC
networks
- - - - √ √ √
Deploy a policy and charging rules function (PCRF) if a PCRF is required to deliver
multi-service (MSE) profiles for PAP.
Deploy an authentication, authorization and accounting (AAA) server if an AAA server
is required to deliver MSE profiles for PAP.
In the preceding table(s), √ indicates that the NE is required, and - indicates that the NE is not required.
Summary
The Personal Application Protection feature enables the UGW9811 to detect subscribers' data
packets and perform subscriber access control to prevent the subscribers from malicious
attacks and ensure Internet access security.
Benefits
For... Benefits
Carriers This feature protects carrier networks from malicious attacks,
enhances the network security, and helps improve carriers'
reputation.
This feature enables carriers to attract more subscribers and
increase user loyalty.
This feature enables carriers to reduce their capital expenditure
(CAPEX) and operating expense (OPEX) by integrating the
personal application protection (PAP) function on the UGW9811.
(Deploying a separate device with the PAP function involves
additional network planing, configuration, and maintenance, and
the separate device cannot well support inter-NE association.)
Subscribers This feature blocks connections initiated by unauthorized servers,
allows packets that comply with protocols and packets of
multi-channel protocols (such as FTP) to pass through, and prevents
unauthorized traffic from entering mobile stations (MSs) or UEs,
thereby protecting subscribers' network access security.
Description
Hardware Requirements
Networking Structure
System Implementation
Hardware Requirements
The PAP function of the UGW9811 can be deployed only on the SPUfs or SPUf1s. Only
the SPUfs or SPUf1s can be deployed on the UGW9811. The SPUs can work only in
1+1 active/standby mode. For details, see the attribute command help.
Deploying the integrated PAP function other than the only PAP function on the
UGW9811 is supported.
Networking Structure
An MSE profile specifies whether the PAP function is enabled. An MSE profile can be
delivered by the PCRF, delivered by the AAA server, or obtained from the configuration on
the UGW9811, and the priorities of these three types of MSE profiles are in descending order.
The PCRF includes the MSE-Profile-Name AVP in a CCA-I message over the Gx
interface, and the MSE-Profile-Name AVP matches the local PAP policy that has been
configured using the mse-profile command. Then the PCRF sends a CCA-U or RAR
message to dynamically update the PAP policy.
The AAA server includes the Charging-Rule-Base-Name AVP in an Access-Accept or
CoA message over the Gi or SGi interface, and the Charging-Rule-Base-Name AVP
matches the local PAP policy that has been configured using the mse-profile command.
Then the AAA server sends a CoA message to dynamically update the PAP policy.
A PAP policy is configured on the UGW9811 using the mse-profile command.
System Implementation
The UGW9811 performs stateless and stateful checks to implement the Personal Application
Protection feature.
Stateless checks
The UGW9811 checks the 5-tuple (source IP address, destination IP address, source port
number, destination port number, and VPN) in a data packet's header against the local
rule configured using the packet-policy command to determine whether to forward or
discard the packet. A data flow table is not established during stateless checks. The
UGW9811 checks each packet separately and does not associate the check result of a
packet with that of the previous packet.
The UGW9811 supports two methods for stateless checks: packet filtering and
malformed packet filtering.
Stateful checks
The UGW9811 establishes a data flow table for packets that pass stateless checks and
traces the data flow status information. The data flow status information includes the
5-tuple (source IP address, destination IP address, source port number, destination port
number, and protocol), virtual private network (VPN) ID, TCP/UDP connection status,
TCP/UDP flag, TCP sequence number, and TCP acknowledgement number. After a
packet arrives at the UGW9811, the UGW9811 checks the fields and payload in the
packet header (Layer 3 to Layer 7) and determines whether to allow the packet to pass
through based on the connection status recorded in the data flow table. This
implementation filters out certain attack packets and malformed packets. Once the
connection is disconnected or the timer expires, the UGW9811 releases the data flow
table.
The UGW9811 supports two methods for stateful checks: TCP/UDP/ICMP status
filtering and ASPF.
The detailed application description of stateless and stateful checks is as follows.
The methods for stateless checks are as follows:
Packet filtering
Packet filtering enables the UGW9811 to perform the action that matches a defined
Layer 3/Layer 4 filter (source/destination IP address, source/destination port number, or
IP protocol) on uplink and downlink packets. The permit action indicates that packets are
allowed to pass through the UGW9811, and the deny action indicates that the UGW9811
discards packets.
You can configure time-specific rules as required. For example, you can configure a rule
to enable the UGW9811 to discard point-to-point (P2P) packets during busy hours. If the
time is in the effective time range, a packet filtering policy configured using the
packet-policy command is used in the rule matching, and the UGW9811 performs the
action defined by the rule on the packets that match a time-specific rule. If the time is not
in the effective time range, a packet filtering policy configured using the packet-policy
command is not used in the rule matching.
Malformed packet filtering
The packet processing by packet receivers may be defective, or protocols have their own
defects. As a result, a packet sender can construct special packets and send these packets
to a packet receiver. Consequently, the packet receiver faces threats. The UGW9811
performs the validity check based on common protocol headers (such as IP, TCP, UDP,
and ICMP headers) and discards abnormal packets.
Table 1-12 lists the common methods of checking malformed packets.
− Layer 7 ASPF
Layer 7 ASPF applies to certain multi-channel control protocols (such as FTP, RTSP,
and SIP) and enables the UGW9811 to allow only a PDN to initiate a connection to a
port destined for an MS/UE after control channel negotiation and forbid downlink
traffic on other ports destined for the MS/UE to pass through.
Layer 7 ASPF enables the UGW9811 to establish session mapping entries based on
keywords, such as source and destination IP addresses, source and destination port
numbers, and protocols. When an MS/UE accesses a PDN, the UGW9811 performs
protocol identification and parsing. If the UGW9811 determines that Layer 7 ASPF
configured using the detect-protocol command has been enabled for the protocol of
the packets, the UGW9811 establishes a data plane channel based on the 5-tuple
information in the negotiated association data in the payload. When the MS/UE or
PDN initiates a data connection, the UGW9811 matches the packets with the 5-tuple
information in the data flow of the MS/UE. If the data connection is the one
negotiated after signaling channel negotiation, the UGW9811 allows the packets to
pass through and does not perform common packet filtering based on the packet
filtering policy configured using the packet-policy command. Otherwise, the
UGW9811 processes the packets as new common flow packets and performs packet
filtering. If the UGW9811 allows the packets to pass through, the UGW9811
establishes a flow table.
As shown in Figure 1-9, the UE-side data channel port running FTP in the TCP
connection establishment phase is port 2000, and the UGW9811 establishes a data
flow table for the port. The data plane port of new flow negotiation initiated by the
UE is port 2001. The UGW9811 performs protocol parsing on uplink traffic, obtains
new flow information, establishes a Layer 7 ASPF session table, and forwards the
packets to an FTP server. The FTP server initiates a downlink connection based on
the newly negotiated port. The UGW9811 matches downlink packets against the
Layer 7 ASPF session table. If the matching succeeds, the UGW9811 allows the
downlink packets to pass through. If the matching fails, the UGW9811 processes the
flow to which the downlink packets belong as a new common flow.
The combined use of the preceding PAP techniques on the UGW9811 ensures Internet access
security and prevents MSs/UEs from being attacked by malicious packets.
After a packet of an MS/UE arrives at the UGW9811, the UGW9811 matches the packet
against a policy. If the UGW9811 determines that the PAP function is enabled for the MS/UE,
the UGW9811 performs packet filtering detection and malformed packet check in turn on the
packet. The UGW9811 performs ASPF and the action specified in the policy on the packets
that do not match a packet filtering policy.
Feature Enhancement
Dependency
Application Limitations
The Personal Application Protection feature can be deployed only on the SPUfs or
SPUf1s.
The Personal Application Protection feature does not support charging compensation on
discarded packets. After this feature is activated, the UGW9811 discards certain packets,
such as malformed packets, but the discarded packets have been charged. This
processing is similar to the processing by an external firewall deployed on the Gi/SGi
interface side and does not support charging compensation on discarded packets.
Interaction with Other Features
Feature Interaction
Service Awareness When the UGW9811 performs application specific packet filter
(SA) (ASPF) on packets, the UGW9811 needs to identify service
protocols in the packets. Therefore, the service awareness (SA)
feature must be activated before the Personal Application
Protection feature is available.
GWFD-110206 PCC If a PCRF is used to deliver MSE profiles for PAP, the policy and
Basic Function charging control (PCC) function must be enabled.
GWFD-110307 If an AAA server is used to deliver MSE profiles for PAP, the
Support CoA change-of-authorization (CoA) function must be enabled.
GWFD-110603 Under the same access point name (APN), Layer 2 Tunneling
L2TP VPN Protocol (L2TP) and PAP services cannot coexist, and the
UGW9811 cannot process L2TP packets for the PAP service.
Availability
Involved NEs
Table 1-15 NEs involved in implementing the Support NAT Function feature on GPRS/UMTS
networks
- - - √ √ √ √
Table 1-16 NEs involved in implementing the Support NAT Function feature on EPC networks
- - - - √ √ √ √
In the preceding table(s), √ indicates that the NE is required, and - indicates that the NE is not required.
This feature is an optional feature and requires a license. The license control item for this
feature is "82205369 Throughput of NAT Function."
Summary
The Support NAT Function feature enables the UGW9811 to translate an IP address into
another IP address. With the Support NAT Function feature, the UGW9811 can perform
address translation to provide network access for subscribers who access a public network
from a private network.
The UGW9811 supports the network address translation (NAT) techniques: NAT No-PAT,
network address and port translation (NAPT), full-cone NAT, and NAT-ALG. (PAT: port
address translation; ALG: application level gateway)
The NAT technique described in this document indicates only NAT44, that is, the translation between an
IPv4 private address and an IPv4 public address.
Benefits
For... Benefits
Description
Hardware Requirements
Network Structure
NAT Source Tracing
NAT
Hardware Requirements
The NAT function of the UGW9811 can be deployed only on the SPUfs or SPUf1s. Only
the SPUfs or SPUf1s can be deployed on the UGW9811. The SPUs can work only in
1+1 active/standby mode. For details, see the attribute command help.
Deploying the integrated NAT function other than the only NAT function on the
UGW9811 is supported.
Network Structure
As shown in Figure 1-10, the UGW9811 connects a carrier's private network to the Internet.
The carrier assigns private IP addresses to subscribers. According to RFC 1918 and for
network security and internal test considerations, addresses in the following address segments
are reserved for use as private addresses:
Class A address segment: 10.0.0.0 to 10.255.255.255 (10.0.0.0/8)
Class B address segment: 172.16.0.0 to 172.31.255.255 (172.16.0.0/12)
Class C address segment: 192.168.0.0 to 192.168.255.255 (192.168.0.0/16)
The IP addresses in class A/B/C address segment are not assigned on the Internet and can be
used in intranets without application. However, these IP addresses cannot be used for Internet
access. The UGW9811 provides multiple NAT techniques to address this issue.
NAT No-PAT
NAPT
Full-cone NAT
NAT-ALG
STUN Poliby
NAT techniques are determined based on the modes (configured using the ip pool command)
of address pools bound to NAT policies. A NAT policy of the UGW9811 can be delivered by
the PCRF, delivered by the AAA server, or obtained from the configuration on the UGW9811,
and the priorities of these three types of NAT policies are in descending order.
The PCRF sends a CCA-I message that carries MSE-Profile-Name over the Gx interface,
matches the locally configured NAT policy that has been configured using the
mse-profile command, and then sends a CCA-U or RAR message to dynamically update
the NAT policy.
The AAA server sends an Access-Accept or CoA message that carries
Charging-Rule-Base-Name over the Gi or SGi interface, matches the locally configured
NAT policy using the mse-profile command, and then sends a CoA message to
dynamically update the NAT policy.
A NAT policy using the mse-profile command is configured on the UGW9811.
After a subscriber's data packet matches a NAT policy, the UGW9811 uses the NAT technique
(NAT No-PAT, NAPT, full-cone NAT, or NAT-ALG) defined in the NAT address pool bound
to NAT policy to translate the private IP address in the packet into a public IP address so that
the subscriber can access a public network from a private network. In addition, the UGW9811
generates a NAT log and reports the log to the eLog server.
NAT Source Tracing
To perform the NAT source tracing function, the eLog server must provide the NAT log
storage and query function and support Huawei proprietary Gnr interface and the Gi/SGi
interface. The eLog server receives logs over the Huawei proprietary Gnr interface and
transmits subscriber information (IMSI/MSISDN) over the Gi/SGi interface.
The Gi/SGi interface is the interface between the UGW9811 and AAA server, which is used
to transmit subscribers' authentication and accounting information and complies with the
RADIUS protocol. However, the Gnr interface does not support the IMSI/MSISDN field.
Therefore, when NAT source tracing is required, the eLog server should be configured as a
RADIUS accounting or RADIUS carbon-copy accounting server on the UGW9811 so that the
UGW9811 can transfer subscribers' IMSIs/MSISDNs to the eLog server over the Gi/SGi
interface.
NAT logs are transmitted between the UGW9811 and eLog server using UDP, and the eLog
server status is checked using heartbeat detection messages. Active and standby eLog server
groups can be configured to improve system reliability. Each server group includes multiple
servers that implement load sharing in polling mode. Active and standby eLog server groups
support the log carbon-copy function. Each NAT log will be sent to a server in the active
server group and carbon copied to a server in the standby server group.
NAT
NAT No-PAT
NAT No-PAT is also called one-to-one address translation. During address translation,
the source IP addresses in data packets are translated from private IP addresses into
public IP addresses, but port numbers are not translated. After NAT No-PAT is completed,
if a subscriber uses a service, the UGW9811 establishes a NAT session table to store the
mapping between the private IP address and public IP address. The public IP address can
be used only by the subscriber until the NAT session table ages out or the subscriber is
deactivated.
In NAT No-PAT mode, the UGW9811 establishes a NAT session table based on
subscribers' IP addresses. When a subscriber with a private IP address accesses the
Internet, the UGW9811 uses an idle public IP address to replace the private source IP
address in the packet and establishes a session entry to record the NAT address mapping.
As shown in Figure 1-11, when the UE accesses the Internet through the UGW9811,
address translation is performed twice. The address translation procedure is as follows:
1. Data packet A sent from the UE using a private IP address to the Internet arrives at the
UGW9811. The UGW9811 checks the packet header and finds that the packet is sent to
an external packet data network (PDN).
2. The UGW9811 queries the session in the local NAT session table.
− If the session is found, the UGW9811 replaces the UE's private IP address in the
packet with the public IP address in the local NAT session table and forwards the
packet to the Internet.
− If no session is found, the UGW9811 matches the APN used by the UE against the
local NAT No-PAT policy, selects a public IP address for the UE from the local NAT
No-PAT address pool, and replaces the UE's private IP address in the packet with the
public IP address. The UGW9811 creates a NAT No-PAT session table, records the
address translation in the NAT session table, and forwards the packet to the Internet.
3. The web server on the Internet receives the data packet sent by the UE and returns a
response packet to the UE. The destination address of the packet is the public IP address
that is obtained after NAT No-PAT is performed on the packet. The packet is routed to
the public IP address and forwarded to the UGW9811.
4. The UGW9811 receives the packet and checks the packet header. The UGW9811 detects
that the address is a public IP address and queries a NAT No-PAT session entry in the
NAT No-PAT session table.
− If the NAT No-PAT session entry is found, the UGW9811 changes the destination
address in the packet to the private IP address found in the NAT No-PAT session table
and forwards the packet to the UE.
− If no session entry is found, the UGW9811 discards the packet.
NAPT
NAT No-PAT is one-to-one mapping in which one private IP address is translated into
one public IP address after NAT No-PAT. This processing requires carriers to have
sufficient public IP addresses. NAPT are multiple-to-one, one-to-multiple, and
multiple-to-multiple mappings. Here takes multiple-to-one mapping for example,
multiple subscribers with private IP addresses can use the same public IP address and can
be identified by port numbers. Compared with NAT No-PAT, NAPT uses public IP
addresses more efficiently. NAPT enables a large number of subscribers to access the
Internet using a small number of public IP addresses.
In NAPT mode, the UGW9811 establishes a NAT session table based on subscribers'
data flows (quintuples), and flow table mappings are established when the same
subscriber accesses different data services or different subscribers simultaneously access
the same service. Therefore, NAPT applies to networks for which carriers have planned
sufficient interfaces. As shown in Figure 1-12, three data packets carrying private IP
addresses are sent to the Internet through the UGW9811. Data packets A and B have the
same private IP address but different source port numbers (one subscriber accessing
different services). Data packets B and C have different private IP addresses but the same
source port number (two subscribers accessing the same service).
After NAPT is performed by the UGW9811, the source private IP addresses and port
numbers of data packets A, B, and C are translated into the same public IP address and
different port numbers, thereby implementing packet flow differentiation.
After response packets from the Internet arrive at the UGW9811, the UGW9811 checks
the corresponding NAT flow table and changes the destination addresses and port
numbers in the packets to the private IP addresses and port numbers of the UEs and
forwards the packets to the UEs.
The NAPT procedure is similar to the NAT No-PAT procedure, but uses a different
address pool mode configured by ip pool command. When a packet matches a NAT
policy that specifies that the address pool mode is NAPT, the UGW9811 replaces the
UE's private IP address and port number in the packet header with a public IP address
and port number. With this processing, multiple private IP addresses can be mapped to
the same public IP address, and packets can be identified by port numbers.
In NAPT mode, the UGW9811 establishes a NAT session table based on subscribers'
data flows (quintuples) but is not allowed to establish a downlink flow table. By default,
the network side cannot proactively connect to MSs/UEs. If the network side is required
to initiate connections for MSs'/UEs' services, such as FaceTime, GoogleTalk, and P2P
download, define a STUN policy to ensure that the services are properly running. For
details about the user-defined STUN policy, see STUN Policy below.
Full-cone NAT
Full-cone NAT is performed based on keywords, such as the IP address, port number,
and protocol. If a subscriber with a private IP address accesses a public network service,
the UGW9811 translates the private IP address into a public IP address and provides the
mapping between the private IP address/port number/protocol and the public IP
address/port number/protocol to allow another subscriber with a public IP address to
send a service access request to a subscriber with a private IP address. Full-cone NAT is
usually used in file sharing, voice communication, and video transmission using P2P
techniques. As shown in Figure 1-13, when subscriber A with a private IP address has
established a connection to Internet server B, Internet server C can proactively initiate a
connection to subscriber A.
In NAT No-PAT mode, the UGW9811 establishes a NAT session table based on
subscribers' IP addresses. When the network side initiates a connection to the IP address
and port number of a subscriber, it can also send a service access request to a subscriber
with a private IP address.
In full-cone NAT mode, the UGW9811 establishes a NAT mapping table based on the
full-cone (IP address, port number, and protocol). As shown in Figure 1-13, when
subscriber A with a private IP address accesses Internet server B, the data packets
transmitted through the UGW9811 match the full-cone NAT address pool policy. In
addition, the UGW9811 replaces the source private IP address and port number in a
packet in a data flow with the public IP address and port number assigned by the
full-cone NAT address pool and establishes a full-cone NAT mapping table for the data
flow on the outbound interface.
After the UGW9811 receives a downlink packet from Internet server B, it checks the
full-cone NAT session table of the data flow and changes the destination address and port
number in the packet to the private IP address and port number of subscriber A and
forwards the packet to subscriber A.
Internet server C initiates a connection to subscriber A, with the destination address
being the public IP address and port number used in the connection between subscriber A
and Internet server B. After the UGW9811 receives a data packet, it queries an entry in
the full-cone NAT mapping table based on the IP address and port number.
− If the entry is found, the UGW9811 replaces the destination IP address and port
number in the packet with the private IP address and port number in the full-cone
NAT mapping table, forwards the packet to the UE, and accepts the service access
request.
− If no session entry is found, the UGW9811 discards the packet and rejects the service
access request.
The full-cone NAT procedure is similar to the NAT No-PAT procedure, but uses a
different address pool mode configured by ip pool.
In full-cone NAT mode, the network side can proactively connect to MSs/UEs, and there
is no restriction on the connections to specified MSs/UEs and service flows. Therefore,
MSs/UEs are vulnerable to attacks from the network side. In this situation, to prevent
excessive connections between MSs/UEs and the network side, set the maximum number
of quintuples allowed for each MS/UE to a proper value using the nap-flow-node-max
command.
NAT-ALG
NAT No-PAT, NAPT, and full-cone NAT can translate only IP addresses and port
numbers in packet headers. They cannot translate private IP addresses and port numbers
in the payload, which may carry private IP addresses and port numbers assigned by
carriers, in the packets of some multi-channel control protocols (such as FTP, RTSP, and
SIP). As a result, data access may fail.
For example, a UE with a private IP address accesses an FTP server on the Internet. The
payload in an FTP signaling packet carries the UE's private IP address and port number,
but NAT No-PAT, NAPT, and full-cone NAT cannot translate the UE's private IP address
in the payload. After the FTP server receives the FTP signaling packet, it initiates a data
connection to the IP address in the payload. As the IP address is a private IP address, the
FTP server fails to identify the IP address.
NAT-ALG is used to solve this problem. NAT-ALG is a translation agent for some
application layer protocols. On the basis of NAT No-PAT, NAPT, and full-cone NAT, the
UGW9811 performs protocol identification and parsing on data packets, determines that
NAT-ALG is enabled for the protocol of the packets (configured using the
detect-protocol command), translates IP addresses and port numbers in data packet
headers, and changes IP addresses and port numbers in the payload in the data packets so
that certain application layer protocols can work through NAT, as shown in Figure 1-14.
Table 1-17 shows the application layer protocols supported by the NAT-ALG function.
The NAT-ALG function can be used only when the following protocols use the NAT
function.
Item NAT-ALG
STUN Policy
In NAPT mode, the network side cannot proactively connect to MSs/UEs. If the network
side is required to initiate connections for MSs'/UEs' services, such as FaceTime,
GoogleTalk, and P2P download, use the detect-policy command to define a STUN
policy based on the Layer 3/Layer 4 information of these services, so as to ensure that
the services are running properly.
When an MS/UE accesses an external network, the UGW9811 performs protocol
identification and parsing. If the UGW9811 determines that the MS's/UE's packets are
STUN protocol packets or match a local user-defined STUN policy configured using the
detect-policy command, the UGW9811 translates the private IP address and port number
of STUN protocol packets to a public IP address and port number on the outbound
interface and establishes the mapping between the source private IP address/port
number/protocol and the public IP address/port number/protocol. When an external
network proactively connects to the public IP address and port number of the MS/UE, if
the UGW9811 detects that the protocol of packets is STUN, the UGW9811 searches for
the full-cone NAPT session table from local configurations.
− If the corresponding entry is found, the UGW9811 replaces the destination IP address
and port number in the MS'/UE' packets with the source private IP address and port
number, forwards the packets to the MS/UE, and allows the service access request.
− If no corresponding entry is found, the UGW9811 discards the packets and rejects the
service access request.
Table 1-18 describes the comparisons among NAT techniques. The NAT technique
deployment is based on the actual network situation.
In practical applications, NAT-ALG, NAT No-PAT, NAPT, and full-cone NAT are used together.
NAT-ALG implements the translation of IP addresses and port numbers in the payload. The translation
of IP addresses and port numbers in IP packet headers depends on NAT No-PAT, NAPT, and full-cone
NAT.
Feature Enhancement
Feature Version Product Version Details
Dependency
Application Limitations
The NAT function can be deployed only on the SPUfs or SPUf1s.
Huawei eLog server must be used in conjunction with the UGW9811 because the eLog
server receives NAT logs reported by the UGW9811 through proprietary interfaces.
The NAT function takes effect during subscriber activation. The NAT function
modification during subscribers' online period takes effect only for newly activated
subscribers.
The NAT function supports NAT only on a data flow that is firstly initiated at the user
side and does not support NAT on a data flow that is firstly initiated at the server side.
Interaction with Other Features
Feature Interaction
GWFD-110216 Header enrichment is completed before address translation using
HTTP Header NAT. The MS or UE IP address inserted into a packet header
Enrichment during header enrichment is different from that received by a
GWFD-110224 service server.
Basic RTSP Header
Enrichment
Feature Interaction
GWFD-010900 If the local address pool configured on the UGW9811 is a private
Routing Function address pool and the NAT function is enabled, the UGW9811
translates a private address assigned to a subscriber into a public
address.
If the UGW9811 advertises both a subscriber's private address and
a downlink route to a public address, the downlink route to the
private address will be unreachable and become an invalid route. In
this case, configure routing policies to disable the advertising of
routes to private addresses.
GWFD-110308 The Gnr logical interface between the UGW9811 and eLog server
RADIUS does not support the international mobile subscriber identity (IMSI)
Carbon-copy or mobile station international ISDN number (MSISDN) field. To
perform the NAT log source traceback function, enable the Remote
Authentication Dial In User Service (RADIUS) carbon-copy
function so that the UGW9811 can transfer the IMSIs and
MSISDNs of subscribers to the eLog server. The NAT log source
traceback function can be implemented for subscribers with IMSIs
or MSISDNs based on the IMSIs or MSISDNs of the subscribers
and the NAT logs reported by the UGW9811.
GWFD-110910 If NAT is performed on a UE enabled with the routing behind UE
Routing Behind MS function, a NAT log can be traced back only to the PDP context IP
address, IMSI, and MSISDN of the UE that functions as a router.
NAT log source traceback of devices connected to the UE can be
determined based on the address assignment policy for the UE
enabled with the routing behind UE function.
NOTE
Generally, the routing behind UE function is used to implement bidirectional
service access between the enterprise network and devices connected to the
UE, and these devices use private IP addresses. Therefore, NAT cannot be
performed. NAT is not performed for these devices based on the
configuration, access point name (APN), and NAT policy.
GWFD-110206 PCC If a PCRF is used to deliver MSE profiles for NAT, the policy and
Basic Function charging control (PCC) function must be enabled.
GWFD-110307 If an AAA server is used to deliver MSE profiles for NAT, the
Support CoA change-of-authorization (CoA) function must be enabled.