Ericssonwide Internal INTERFACE DESCRIPTION 1 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003

Gi Interface in GGSN 4.0 and CGSN G 3.0 Ericssonwide Internal INTERFACE DESCRIPTION 2 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 Contents 1General............................................................................................................... 4 1.1Purpose............................................................................................................... 4 1.2Revision History ................................................................................................ 5 2Description......................................................................................................... 7 2.1Summary............................................................................................................ 7 2.2Data Model ........................................................................................................ 9 2.3Physical Layer and Link Layer Protocols........................................................ 11 2.3.1Ethernet Interface............................................................................................. 11 2.3.2ATM Interface ................................................................................................. 11 2.4Node specific IP-addresses .............................................................................. 13 2.4.1MS APN network............................................................................................. 13 2.4.2GGSN IP address ............................................................................................. 13 2.4.3Gi IPsec VIP address ....................................................................................... 13 2.4.4GiR external IP addresses ................................................................................ 13 2.4.5Gi GRE VIP address ........................................................................................ 13 2.4.6External Protocol IP address............................................................................ 14 2.4.7RADIUS External Protocol IP address............................................................ 14 2.5IP Functionality................................................................................................ 14 2.5.1Normal IP Routing and APN Routing ............................................................. 14 2.5.2Overlapping Private IP-addresses.................................................................... 18 2.5.3RADIUS Client Support .................................................................................. 18 2.5.4DHCP Relay Agent Support ............................................................................ 33 2.5.5ICMP................................................................................................................ 37 2.5.6Packet Filtering................................................................................................ 38 2.5.7IPsec................................................................................................................. 39 2.5.8GRE ................................................................................................................. 41 2.5.9Redundancy ..................................................................................................... 42 2.5.10Load-sharing .................................................................................................... 43 2.5.11Use of GTP PCO.............................................................................................. 43 2.5.12Gi ISP Load Distribution ................................................................................. 45 2.5.13The GGSN IP-address Pool ............................................................................. 46 2.6Use Cases......................................................................................................... 47 2.6.1Create Link ...................................................................................................... 47 2.6.2Remove Link.................................................................................................... 47 2.6.3Create APN / Create RADIUS APN/ Create UBS APN................................. 47 2.6.4Modify APN .................................................................................................... 48 2.6.5Remove APN................................................................................................... 49 Ericssonwide Internal INTERFACE DESCRIPTION 3 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.6.6Create PDP Context ......................................................................................... 49 2.6.7Delete PDP Context ......................................................................................... 49 2.6.8Payload Towards external PDN....................................................................... 50 2.6.9Payload Towards MS....................................................................................... 50 2.7Limitations ....................................................................................................... 51 2.7.1Internal Addresses............................................................................................ 51 2.7.2Ethernet and APN Routing .............................................................................. 51 2.7.3Quality of Service ............................................................................................ 51 2.8APN Handling and Configuration ................................................................... 52 2.8.1APN size .......................................................................................................... 52 2.8.2APN admission control .................................................................................... 52 2.8.3Username Based Selection of APN................................................................. 52 2.8.4Packet Inspection and Service Classification .................................................. 53 2.8.5Real-Time Charging ........................................................................................ 53 3Operational Conditions .................................................................................... 54 3.1Application Choices......................................................................................... 54 3.1.1The GGSN Internal IP Network ...................................................................... 54 3.2Operation and Maintenance ............................................................................. 54 3.2.1APN Parameters............................................................................................... 55 3.2.2RADIUS Parameters........................................................................................ 55 3.2.3Security Parameters ......................................................................................... 56 3.2.4IP Parameters ................................................................................................... 56 3.2.5Alarm and Counters ......................................................................................... 56 3.2.6DHCP Parameters ............................................................................................ 56 3.2.7Global Properties ............................................................................................. 57 3.3Characteristics.................................................................................................. 57 3.4Licensing and Installation................................................................................ 57 4Concepts and Abbreviations ............................................................................ 58 4.1Concepts........................................................................................................... 58 4.2Abbreviations................................................................................................... 59 5References........................................................................................................ 61 Ericssonwide Internal INTERFACE DESCRIPTION 4 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 1General When in this document the term GGSN is used, it is to be understood as either the stand-alone node GGSN 4.0 or the GGSN-part of the combined node CGSN G 3.0 1.1Purpose The Gi interface connects the GPRS system to an external PDN, enabling the MS to exchange IPv4 packets with an external PDN. The external PDN may be an ISP and/or a Corporate Network and it is identified by an Access Point Name (APN) in the GGSN. This document gives an overview of when and how the GGSN uses the Gi interface, and what services the GGSN offers to the external PDN. This document is written for design, product management and marketing usage. Its information class shows that it may contain more sensitive information than the corresponding customer product information document Ref [11]. Ericssonwide Internal INTERFACE DESCRIPTION 5 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 1.2Revision History RevDatePreparedDescription A2001-07-02EED/S/P Juan-Antonio IbanezFirst revision B2002-01-14ERV/K/PKent Eriksson New revision after formal review C2002-07-08EAB/UFK/P Kent Eriksson -Added proprietary RADIUS-attribute no. 230, GGSN-GTP-IP-Address -Added RADIUS-attribute no. 30, Called-Station-Id -Changed RADIUS NAS-Port configuration to a node property -Description of UDP Source Port in RADIUS -Clarified DHCP-use -Added description of Gi ISP load distribution -Added Default APN and change of Selection Mode for UBS APN. -GGSN 4.0 supports ITU-T I.361 1995 and 1999 -Updated after review meeting June 26, 2002 -Removed incorrect description of DHCPRELEASE at restart -References updated -Corrected description of RADIUS retransmission strategy -Corrected incorrect use of GGSN IP address as IPsec VIP D2002-08-27EAB/UFK/P Kent Eriksson -Added description of RADIUS-attribute Acct-Session-Id -New UBS solution.E2002-09-12EAB/UFK/P Kent Eriksson -Description of flexible bearer charging -Updated description of APN-routing vs. IP-routing -Updated restrictions on external routers for APN-routing -Corrected DHCP-description -Minor corrections to UBS-description. -Added requirement on virtual links for GiR redundancy F2002-11-20EAB/UFK/N Kent Eriksson -Updated with additional PSC-functionality G2003-02-12EAB/UFG/N Kent Eriksson -Released for ACA05 -Added information on CGSN G 3.0 -Added information on internal IP-address pool -Added change of UDP Source ports for RADIUS -Added clarifications on error messages at Context setup -Added references to useful information in CPI Gi IFD -Added that term GiA includes merged GnA/GiA PIU Ericssonwide Internal INTERFACE DESCRIPTION 6 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 RevDatePreparedDescription H2003-10-02EAB/UFG/N Kent Eriksson -Updates for AC-A07 -RTC added -CR 79: Three more RADIUS-parameters configurable -Replaced most of UBS-description (2.8.3) by references -Username for UBS-APN truncated in Access-Request -Clarified that MS IP-address is included in Accounting-Request, even if RADIUS-authentication is combined with another method of IP-address allocation. -OSPF v2 according to RFC 2328 Ericssonwide Internal INTERFACE DESCRIPTION 7 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2Description The below Figure 1 describes the location of the GGSN and the Gi interface within the GPRS framework. The box labeled GGSN in the figure can be either a stand-alone GGSN 4.0 or a CGSN G 3.0 A Combined GPRS Support Node (CGSN) is a packaging of SGSN and GGSN services into one physical node. From the GPRS point of view, the CGSN is equivalent to one SGSN and one GGSN. An external SGSN or GGSN will see the CGSN as one SGSN and one GGSN. However, from an O&M point of view the CGSN functions as a single node, with respect to configuration, alarms, counters, logs etc. 2.1Summary RadioNetworkGPRS backbone(IP)ISP network(IP)Corporatenetwork (IP)Internet (IP)GGSN MSSGSN WSGSN GGn IuGn GiGb Figure 1: GPRS overview The Gi interface of GGSN complies with version 3.5.0 of 3G TS 29.061 (Ref [1]) but not fully with version 3.7.0 of the same standard (Ref [2]). Consult Ref [3] for full compliance information.The Gi interface enables the MS to exchange IPv4 packets with an external PDN (ISP and/or Corporate Network) using public or private, dynamic or static IP-addresses. Each external PDN connected to the GGSN is uniquely identified by an Access Point Name (APN). The IP packets will be routed to the external PDN via normal IP routing or via the APN routing mechanism, see 2.5.1 on page 14. Normal IP routing uses static routes or a routing protocol. Supported routing protocols are OSPFv2, BGPv4, or RIPv2.The APN routing mechanism uses point-to-point connections and the IP packet forwarding decision is based on which external PDN the MS belongs to. This mechanism allows for overlapping private IP-addresses between APNs to be supported by the GGSN. This can be achieved between GGSN and the external PDNs with either IPsec tunneling, GRE tunneling or ATM PVC.IPsec tunnels and packet filtering are supported in order to provide security to the external connections of the GGSN node. Use of APN routing will add an extra level of security for the external Ericssonwide Internal INTERFACE DESCRIPTION 8 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 connections. A GPRS specific ingress filtering, see section 2.6.8 on page 50, may also be performed before packets are sent towards the external PDN. RADIUS may be used for subscriber authentication (username/password sent using either PAP or CHAP, or IMSI, or MSISDN). Both Inband and Outband RADIUS-servers are supported. The IP-address used by an MS may be static or dynamic. Dynamic IP-addresses can be allocated by a RADIUS-server (inband or outband), by an inband DHCP-server, or by a GGSN-internal IP-address pool. A static IP-address can be submitted by the subscriber or retrieved from HLR by SGSN. Ericssonwide Internal INTERFACE DESCRIPTION 9 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.2Data Model For each PDP Context, the context data of Table 1 below is stored in the GGSN. For Release 99, refer to Ref [36], section 13.3, and the IE descriptions in Ref [35], section 7.7. For Release 97, refer to the IE descriptions of Ref [34], section 7.9. Note that each active PDP Context requires its own IP-address; secondary PDP Context is not supported. A subscriber may have up to 11 PDP Contexts, each with its own IP-address, active simultaneously.FieldDescriptionComments IMSIInternational Mobile Subscriber Identity of MS NSAPINetwork layer Service Access Point ID.MSISDNMobile Station ISDN/PSTN number PDP TypeIPv4Only IPv4 is supported. PDP AddressThe IPv4 address allocated to the MS Dynamic AddressIndicates whether PDP address is dynamic or static. APNAPN of the PDP ContextTEIDTunnel Endpoint Identifier for DataOnly in GTP v1, release '99 In GTPv0, this is IMSI + NSAPI QoS ProfileNegotiated profileOnly class Best Effort is supportedSGSN AddressIP-address of SGSN handling this PDP Context. RecoveryIndicates if SGSN is performing recovery Charging IDIdentifies the PDP Context for charging purposes Charging CharacteristicsE.g. normal, prepaid, flat-rate, hot billing Selection Mode UsedWhether APN was selected by MS, SGSN, or Subscription. Table 1: PDP Context Data stored on GGSNSince the Secondary PDP Context Activation procedure is not supported, the TFT IE is not stored. Since Network Requested PDP Context Activation is not supported, the MNRG IE is not stored. Since sequence numbering is not supported, the GTP-SND and GTP-SNU IEs are not stored. Since subscriber/equipment trace is not supported, the following IEs are not stored: Trace reference, Trace type, Trigger Id, and OMC Identity. Ericssonwide Internal INTERFACE DESCRIPTION 10 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 For each APN the following data is stored in the GGSN and used by the Gi interface: FieldDescription APN NameCf. APN in Table 1 above. MS APN networkThis is given by the First Supported IP-address and Netmask. GGSN IP AddressSee section 2.4 on page 13. Routing MethodThis can be set to normal IP Routing or APN routing. When APN routing is used, one or several Link Name(s) must be entered. A VC Metric is given for each Link Name to indicate the priority of the link. MS IP Address OriginThe method for allocating the PDP Address on the MS APN. Can be Static, RADIUS, DHCP, or GGSN provided. Cf. section 3.2.4.1 below Ingress Filtering IndicatorThis indicates whether to check that the MS uses the allocated IP-address when sending IP packets. IP packets having a faulty source address are silently discarded when the ingress filtering function is activated. DNS Server IP AddressIt is possible to configure both a Primary DNS Server IP address and a Secondary DNS Server IP address, but the Primary one must be configured in order to configure the Secondary. These DNS Server IP addresses are sent to the MS, see section 2.5.11 on page 43.RADIUSSeveral parameters. See section 3.2.2 below. External Protocol IP addressWhen the GGSN uses DHCP, this address is used as the Relay Agent IP address towards the external server. DHCP Server IP addressIf DHCP is used, this is the IP-address of the DHCP-server on the external PDN. Selection ModesThe GGSN uses Selection Mode when deciding whether to accept or reject the PDP Context activation. Three Boolean values, specifying whether APN can be selected by MS, SGSN, or Subscription.User-Name based selectionBoolean. Cf. section 2.8.3 below Default APN for UBSIf the APN is a UBS APN, this APN will be selected if the Create_PDP_Context-request contains no @-sign in the User-name. Allowed APNs for UBSA list of APNs, which can be UBS-selected via this APN. Valid only for UBS APNs.MaxContextsThe maximum number of PDP Contexts allowed for the APN. Cf. section 2.8.2. IP-filtersIP-addresses subject to PISC URI-filtersURIs subject to PISC WAP-signaling filtersIP-addresses where WAP-signaling is subject to PISC IMSI-analysisBoolean. Use IMSI-filtering and charging characteristics defined by node property Ch-GGSN-Imsi-Filters RTCSeveral parameters. See Ref [77] Table 2: APN Data Ericssonwide Internal INTERFACE DESCRIPTION 11 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.3Physical Layer and Link Layer Protocols The GiR used are IBASv2 or IBAMv2 in GGSN 4.0. CGSN G 3.0 supports only IBASv2. See Ref [45] and Ref [46], respectively. In addition to the ATM interface of section 2.3.2 below, these PIUs also include an Ethernet port. Cf. section 2.3.1 below. The Ethernet port and the ATM interface can be used in parallel, but this will not increase total throughput. 2.3.1Ethernet Interface IP LLC MAC 10Base-T100Base-Tx Figure 2: Ethernet Interface The Ethernet interface supports 10Base-T according to Ref [8] and 100Base-Tx according to Ref [9]. Transfer Rates are: Half- and full duplex 10 Mbits/s for 10Base-T, and full duplex 100 Mbits/s for 100Base-Tx. The Medium Access Control layer, MAC, conforms to Ref [8] and Ref [9]. The Logical Link Control layer, LLC, conforms to Ref [7]. IP is carried over Ethernet according to Ref [40]. 2.3.2ATM Interface IP AAL5 ATM STM-1/OC-3Single-mode fiber optical STM-1/OC-3Multi-mode fiber optical (available only for GGSN 4.0) Figure 3: ATM Interface The physical layer is either SDH STM-1 or SONET OC-3. SDH STM-1 conforms to Ref [12], Ref [13], Ref [14], and Ref [16]. SONET OC-3c conforms to Ref [19] and Ref [20]. The transfer rate is 155 Mbits/s. Each 155 Mbits/s link supports 256 ATM PVCs.UNI-mode (user side) is supported according to Ref [29], Ref [30], and Ref [31]. ATM is supported according to Ref [21], Ref [22], Ref [23], and Ref [24]. Ericssonwide Internal INTERFACE DESCRIPTION 12 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 AAL5 is supported according to Ref [25], Ref [26], and Ref [27]. IP is carried over AAL5 according to Ref [41], Ref [43], and Ref [44]. Point-to-point IP connections over ATM PVCs are supported. Supported service categories are non-realtime VBR (Variable Bit Rate) and UBR (Unspecified bit rate).Loopback timing is available on the SDH/SONET level, in addition to the default internal timing. PCR (Peak Cell Rate), SCR (Sustained Cell Rate), and MBS (Maximum Burst Size) are configurable. ILMI or ATMARP are not supported in the GGSN. There is no SVC support. FunctionIBAMv2 (available for only GGSN 4.0)IBASv2 Maximum bit rate155 Mbits/s155 Mbits/sPhysical layerSDH STM-1 (default) or SONET OC-3SDH STM-1 S1.1 (default) or SONET OC-3 IR-1 Physical layer alarmsLine and path RDI alarm is sent on the physical layer upon detection of LOS, LOF and Line/path AIS Line and path RDI alarm is sent on the physical layer upon detection of LOS, LOF and Line/path AIS TimingInternal (default) or loopbackInternal (default) or loopback PVC failure detectionF4 and F5 OAM cells, i.e. AIS, RDI, and LB cells are supported. VP and VC RDI cells are sent upon reception of VP and VC AIS. Received LB cells are returned to the sender. F4 and F5 OAM cells, i.e. AIS, RDI, and LB cells are supported. VP and VC RDI cells are sent upon reception of VP and VC AIS. Received LB cells are returned to the sender. Connector on PIUMulti-mode Duplex SCSingle-mode Duplex SC Connectors on delivered cableMulti-mode Duplex SC at both endsSingle-mode Duplex SC at both ends Cable typeMulti-mode optical fiberSingle-mode optical fiber Verified fiber range60 m60 m Theoretical fiber range2 km15 km Table 3: Technical data for the ATM physical interfaces 2.3.2.1ATM PVC failure detection Failure detection for ATM PVCs is supported.The OAM cells Alarm Indication Signal (AIS)/Remote Defect Indication (RDI) and Loopback according to Ref [28] are implemented. AIS/RDI can be used to discover HW interface or fiber/cable errors. In addition, the configurable Loopback OAM cell can be used to detect misconfigurations in the ATM network, and can also be used for diagnostics. Ericssonwide Internal INTERFACE DESCRIPTION 13 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.4Node specific IP-addresses The IP-addresses used by the GGSN node, and visible on the network connected to the Gi interface of the node, are listed in this section. These IP-addresses are configured through the O&M function of the GPRS application. Consult Ref [10] or Ref [42] for further descriptions. 2.4.1MS APN network The IP-address of an MS handled by a GGSN belongs to an MS APN network that can consist of one or more IP sub-networks. When an IP-address is allocated for the MS, it is taken from the MS APNs IP-address range. One of the IP-addresses on the MS APN network is the GGSN IP address (described below). The MS APN network belongs to an external PDN, identified by its Access Point Name (APN), which is the access point for the MS APN network. There is one MS APN network for each APN. A GGSN can handle several MS APN networks. The MS APN has one or more IP-address ranges. Each such range is defined by its first IP-address and its netmask. For more details, consult the configuration instruction Ref [6]. 2.4.2GGSN IP address There is one GGSN IP address per APN and it is defined when configuring the APN. This IP-address must be within the IP-address range of the MS APN. The GGSN IP address is used as source address for ICMP messages and it is also used as Default Gateway address in IPCP requests. Cf. section 2.5.11 below. It must be different from External Protocol IP address. In some documents, this IP-address is called the Appendix IP-address.This GGSN IP address must not be mixed up with the reserved GTP VIP used for identifying the GGSN on the Gn interface. Cf. the Gn interface description Ref [72]. Note that the GTP VIP is the address sent in the proprietary RADIUS-attribute GGSN-GTP-IP-Address (attribute ID 230). Cf. section 2.5.3.6 below. 2.4.3Gi IPsec VIP address The IPsec functionality on the GiR router PIUs uses one IPsec tunnel IP-address for each IPsec tunnel. Several IPsec tunnels can use the same Gi IPsec VIP address. A VIP address is needed to cope with GiR failure. For configuration of the Gi IPsec VIP address, consult section 3.6 of Ref [10], or Ref [42]. 2.4.4GiR external IP addressesThe GGSNs GiR router PIUs' external interfaces are configured with IP-addresses. The GiR uses one external IP-address for Ethernet on the Gi interface. ATM may use other configurations.2.4.5Gi GRE VIP addressThe Gi GRE VIP address is used as the destination address for GRE tunnels on the Gi interface. Several GRE tunnels can use the same destination address as they can be separated by Session Keys (see Ref [60]). A VIP address is needed to cope with GiR failure. It is configured in a similar manner as for IPsec. GRE can be used for APN routing (see section 3.2). Ericssonwide Internal INTERFACE DESCRIPTION 14 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.4.6External Protocol IP address This IP-address is used as the source (client) IP-address when the GGSN communicates with a DHCP-server. This IP-address must be within the IP-address range of the MS APN. It must be different from GGSN IP address (described above). If the APN also uses an inband RADIUS-server, the External Protocol IP Address must be the same as the RADIUS External Protocol IP Address. 2.4.7RADIUS External Protocol IP address This IP-address is used as the client-address (NAS-IP-Address) by the GGSN, when it communicates with a RADIUS-server. This IP-address must be within the IP-address range of the MS APN. It must be different from the GGSN IP address (described above). If the APN also uses a DHCP-server, the RADIUS External Protocol IP Address must be the same as the External Protocol IP Address. 2.5IP Functionality Consult Ref. [10] for more detailed descriptions. The GiR PIUs handle routing functionality of the Gi interface. The GiA PIUs have no external routing functionality, but they can forward packets on the node internal IP network For improved security, IP source routing is by default disabled on all GiR PIUs.2.5.1Normal IP Routing and APN Routing All Mobile Stations that are in active state, i.e., for which a PDP Context is activated, belong to an MS APN network. The MS APN network should be seen as part of the external PDN. Routing of IP packets between the GGSN and an external PDN can be done in two different ways: ! APN routing, also referred to as the Link Layer Forwarding (LLF) method,! Normal IP routing Ericssonwide Internal INTERFACE DESCRIPTION 15 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.5.1.1Example to illustrate APN Routing and Normal IP routing Figure 4 below illustrates an example, which is described below to show the difference between APN routing and normal IP routing. ISP 3 network (IP)APN 3ISP 1 network (IP)APN 1Internet (IP)GbGiMS belonging to APN 3:7.58.15.4MS belonging to APN1:160.1.1.3MSAPN subnetwork for APN 3:7.58.15.0/255.255.255.0GGSN IP addr:7.58.15.1 MS APN subnetwork for APN 1:160.1.1.0/255.255.255.0GGSN IP addr:160.1.1.1 8.2.0.0/255.255.0.0 7.58.14.0/255.255.0.0Internet host:187.14.5.7GnGnIu SGSNSGSNMS1MS3R3R1HGPRSbackbone (IP)GGSN RadioNetwork Figure 4: Example of APN Routing and Normal IP Routing In Figure 4, a GPRS operator has one GGSN and two SGSNs. The operator provides GPRS-service to two ISPs (ISP 1 and ISP 3). ISP 3 has an MS APN network, which is 7.58.15.0/255.255.255.0, and ISP 1 has an MS APN network which is 160.1.1.0/255.255.255.0. In this example, MS3 sends an IP packet to the Internet host H (the destination IP-address is set to the IP-address of the Internet host H.). The IP packet travels from MS3 via the SGSN to the GGSN that handles the MS APN network to which MS3 belongs. The GGSN now has to make a decision which way to forward the packet. The GGSN can either forward the packet to R3 or R1 depending on the selected routing method, which is set up during PDP Context activation procedure. If normal IP routing is used for this APN, the GGSN will use the normal IP forwarding policy. The GGSN looks at the destination IP-address in the packet, and forwards the packet to the router, which has the lowest cost towards the Internet host H. In our example, this means that the packet might be forwarded to R1 through the ISP 1 network to Internet host H, even though MS3 actually belongs to ISP 3. If APN routing is used for this APN, then the GGSN will base the forwarding decision upon which APN the MS belongs to. In our example, the IP packets from MS3 will always be forwarded to R3 through ISP 3 to the Internet host H. An MS APN network is configured to use either APN routing or normal IP routing. The external interfaces on the GiR PIUs must also be configured to support either normal IP routing or APN routing.Each MS APN network configured requires a GGSN IP address, which must be unique in the GGSN. For traffic from the external PDN towards the MS, see section 2.6.9 on page 50. Ericssonwide Internal INTERFACE DESCRIPTION 16 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.5.1.2Normal IP Routing The following routing mechanisms for normal IP routing are supported: ! Static routes ! Dynamic routing protocols The following dynamic routing protocols are supported: ! OSPFv2 according to Ref [39] ! BGPv4 according to Ref [37] ! RIPv2 according to Ref [38] For details on import/export policies between different routing protocols, consult section 9.7 of Ref [11]. Use of normal IP-routing requires the following: ! The IP-address range of the MS APN must be unique within the GGSN. ! The IP-addresses on the external interfaces that participate in normal IP routing must be unique within the GGSN. ! The IP-addresses on the interface routers connected to the external links must be unique. The GGSN cannot act as a transit router on the Gi interface. This implies that if GGSN runs EBGP, it cannot act as a multihomed border router. Use of normal IP routing allows for dynamic routing protocols between the GGSN process handling the MS APN network and the external PDN. When a new MS APN network, with normal IP routing, is added to GGSN, the IP-address range of this MS APN will automatically be announced to the external PDN. Likewise, this IP-address range will be announced not-supported, if the MS APN is removed from the GGSN.If an external PDN is accessed via IP-routing, the corresponding MS APNs in the GGSNs must be subnets of the external PDN. This means that in Figure 4 above, only APN3 can be IP-routed. 2.5.1.3APN Routing APN routing means there is a point-to-point connection between a GiR in GGSN and a router in the external PDN. Routing is based on which external PDN the MS belongs to. This is similar to link-layer switching, since the decision to which interface a packet shall be routed is not based on the destination IP-address in the IP protocol (network-layer), but on static information provided at APN configuration.The point-to-point connection between the GiR and the external PDN must be one of the following: ! ATM VC. Cf. section 2.5.1.4 below ! IPsec SA. Cf. section 2.5.7.2 below. ! GRE tunnel. Cf. section 2.5.8.1 below APN routing also allows different external PDNs to use overlapping IP-addresses. All MSs belong to an MS APN network, which is assigned to one or several specific GGSNs. The IP-addresses in an MS APN can either be public or private. A public MS IP-address is simple to handle, since it is unique. A private MS IP-address, however, can be unique within its external PDN, but there may be other external PDNs using the same private MS IP-address. In this latter case, the GiRs cannot determine which external PDN the MS belongs to. APN routing removes this problem, since routing is not based on IP-addresses, but on associated link names. Ericssonwide Internal INTERFACE DESCRIPTION 17 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 It is recommended to use APN routing for both public and private IP-addresses. APN routing improves the security in an MS APN, since its IP-addresses are accessible only from the external PDN. The tunnel achieved by APN-routing provides an extra level of security. APN routing provides efficient implementation of VPNs, which is why it is used when corporate networks are connected to GGSN. In addition to separating networks with overlapping IP-addresses, APN routing can be used to branch out traffic to two different ISPs. This avoids the problem where packets from a mobile subscriber of ISP A, connected to a certain GGSN, are actually routed through the interface to ISP B, connected to the very same GGSN.The IP-addresses used for external routers handling ordinary IP-routing protocols on the Internet must be unique. However, there may exist local routers in a corporate network, which is accessed via APN-routing. For GRE and IPsec, these local routers can have arbitrary IP-addresses. For example, GRE-tunnels are transported over IP. This means that they pass through IP-routers with unique addresses. For APN-routing over ATM PVC, the following limitation applies: The IP-addresses on an external router must be unique within the corresponding GiR PIU. For APN-routing using IPsec or GRE, the IP-addresses used on the GiR PIU can be arbitrary. For APN-routing over ATM PVC, the following limitation applies: The IP-addresses on one GiR PIU must be unique within that particular PIU. When a new MS APN with APN routing is added to GGSN, the point-to-point connection must be manually configured, both on the GGSN side and on the external PDN side. The point-to-point connection can be realized by two separate links to provide redundancy. One GiR should handle each link. Cf. section 2.5.9 below. Each link is assigned a VC metric, a priority measure. The GiA will always select the available link with the highest priority. If these links are given the same VC-metric, payload will be load-shared over the links, as described in section 2.5.10 below. Consult Ref [6] for more configuration details. On the GiR, a GGSN-internal link-layer tunnel from a GiA is connected to the point-to-point interface.Note that, for the underlying routing of IPsec tunnels and GRE tunnels, Normal IP routing can be used. If an external PDN is accessed via APN-routing, the corresponding MS APNs in the GGSNs need not be subnets of the external PDN. Cf. APN 1 in Figure 4 above. 2.5.1.4APN routing with ATM VC A GGSN-internal link-layer tunnel between a GiA and a GiR can be connected to an ATM VC defined at the GiR. This enables APN routing to the external PDN connected to the ATM VC. Each physical ATM interface can be configured with several VCs. Each VC is treated as a unique IP interface. Consult System Characteristics, Ref [63], for figures on how many ATM VCs can be defined for each GiR on GGSN 4.0. The corresponding document for CGSN G 3.0 is Ref [76]. Ericssonwide Internal INTERFACE DESCRIPTION 18 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.5.2Overlapping Private IP-addresses When a Corporate Network assigns dynamic or static IP-addresses to its MSs, it may use private IP-addresses. This method may be used by several Corporate Networks independently of each other. The packet forwarding and routing mechanism must be able to handle this overlapping situation. As described in section 2.5.1.3 above, the GGSN supports this function by using the APN routing mechanism. The APN routing will base the forwarding decision upon which Corporate Network the MS belongs to, and not on the lowest cost as in normal IP routing. 2.5.3RADIUS Client Support RADIUS can provide user authentication, IP-address allocation, and accounting for the MS. The RADIUS Client support in GGSN is based on RFC 2865 (Ref [47) and RFC 2866 (Ref [48]). This section 2.5.3 describes the full RADIUS-support in GGSN. All supported RADIUS-attributes are listed here. RADIUS-attributes not listed below are not supported. If received by the GGSN, unsupported RADIUS-attributes will be ignored (See section 2.5.3.2 below for the sole exception.) Note especially that the Gi interface of GGSN complies with version 3.5.0 of 3G TS 29.061 (Ref [1]) but not fully with version 3.7.0 of the same standard (Ref [2]). The latter version includes a list of RADIUS-attributes. These attributes are NOT supported in the way they are described in Ref [2]. Nevertheless, several of these standardized RADIUS-attributes do exist in GGSN, but as proprietary attributes. Cf. section 2.5.3.5 below. In case no user name is received from the MS, the string "void" will be sent towards the RADIUS Server as user name and password, indicating PAP as authentication protocol. Cf. Table 6 below. Accounting-Requests are primarily used to indicate that an IP-address is in use. Accounting-Request (Start) indicates that the IP-address is in use by the MS. Similarly, Accounting-Request (Stop) indicates that the IP-address can be allocated to another MS. Accounting-Requests (Start) and (Stop) are sent automatically, if a RADIUS-server is used for IP-address allocation for the APN. This pair of messages is sent also if the APN is configured to send Accounting-Requests. This means that Accounting-Requests can be sent even if the IP-address is static or allocated by GGSN or by DHCP. This allows Accounting-Requests to be used for other purposes than just for RADIUS IP-address allocation. For example, an Accounting-Request can be used to forward the MSISDN/IP-address combination to a WAP Gateway, if a different IP-address allocation method is used. GGSN does not use asynchronous accounting. I.e. when an APN uses RADIUS-accounting, the RADIUS-client will always wait for an Accounting-Response, before a Create_PDP_Context-Response can be generated. The same RADIUS-server IP-address must be used for both Access-Requests and for Accounting-Requests. If different RADIUS-servers are to be used for authentication and for accounting, a proxy-server is necessary.Upon a restart, the GGSN sends an Accounting-Request (Accounting-On) to all configured RADIUS Servers. This message is sent for all APNs, which use a RADIUS-server. The RADIUS-attribute settings depend on configuration options in the GGSN, and on information elements provided by the MS in the Create_PDP_Context-request. See the configuration description Ref [6] for details on the former case and the GTP-standard (Ref [34] and Ref [35]) for details on the latter. Ericssonwide Internal INTERFACE DESCRIPTION 19 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 An APN may use either Outband or Inband RADIUS. Use of Outband RADIUS requires that a RADIUS APN be first configured for the RADIUS-server. To configure an APN with Outband RADIUS, the operator can choose the desired Outband APN from a list. The configuration details are automatically read into the regular APN configuration. See the configuration description Ref [6] for details. Except for configuration, there is no difference between the use of Outband and Inband RADIUS. Below are given typical examples of RADIUS-messages processed by the GGSN RADIUS-client. The 20-byte RADIUS-header, including message authenticator, is not included in the below descriptions. Refer to the standards RFC 2865 (Ref [47) and RFC 2866 (Ref [48]) for this.Symbols used in the tables of sections 2.5.3.1, 2.5.3.2, and 2.5.3.3 #Attribute type number, according to RFCs 2865 or 2866 M Mandatory. Always present in the message from/to GGSN CConditional in the message from/to GGSN. The condition is given in the text. O Optional in the message from/to GGSN. Part of the APN configuration options. Cf. section 3.2.2 below and the configuration description, Ref [6]. 2.5.3.1RADIUS Access-Request messages Below are three examples of possible RADIUS Access-Request messages from GGSN. PAP used If PAP is used for authentication of the MS, the Access-Request will include the following attributes. Attribute nameDescription # User-namePAP Username.1M User-PasswordPAP password2M NAS-IP-AddressIP-address of GGSN, to be used by the RADIUS server. This is the RADIUS External Protocol IP address of section 2.4. 4M NAS-PortAlways set to 1, if included.5O Service-TypeAlways set to 2 (Framed).6M Framed-ProtocolAlways set to 1 (PPP).7M Called-Station-IdAPN string, e.g. domain name30M Calling-Station-IDMSISDN, if configured to be included for this APN. Otherwise, not sent. 31O NAS-IdentifierAPN string, e.g. domain name32M IMSIIMSI of MS224O Charging-IdCharging Identifier used for charging of the PDP Context225O IMSI-MCC-MNCMCC and MNC-parts of IMSI of MS226O Selection ModeAPN Selection Mode. User-, SGSN-, or Subscription-selected229O GGSN-GTP-IP-AddressThe reserved GTP VIP identifying the GGSN230O Table 4: RADIUS-Access-Request with PAP-authentication Ericssonwide Internal INTERFACE DESCRIPTION 20 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 CHAP used If CHAP is used for authentication of the MS, the Access-Request will include the following attributes. Attribute nameDescription # User-nameCHAP Username1M CHAP-PasswordCHAP Password3M NAS-IP-AddressIP-address of GGSN, to be used by the RADIUS server. This is the RADIUS External Protocol IP address of section 2.4. 4M NAS-PortAlways set to 1, if included.5O Service-TypeAlways set to 2 (Framed).6M Framed-ProtocolAlways set to 1 (PPP).7M Called-Station-IdAPN string, e.g. domain name30M Calling-Station-IDMSISDN, if configured to be included for this APN. Otherwise, not sent. 31O NAS-IdentifierAPN string, e.g. domain name32M CHAP-ChallengeValue provided by MS. 60M IMSIIMSI of MS224O Charging-IdCharging Identifier used for charging of the PDP Context225O IMSI-MCC-MNCMCC and MNC-parts of IMSI of MS226O Selection ModeAPN Selection Mode. User-, SGSN-, or Subscription-selected229O GGSN-GTP-IP-AddressThe reserved GTP VIP identifying the GGSN230O Table 5: RADIUS-Access-Request with CHAP-authentication Ericssonwide Internal INTERFACE DESCRIPTION 21 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 Neither CHAP nor PAP used This message can be used, if RADIUS is to be used only for allocation of an IP-address to the MS but not for authentication of the MS.This message can also be used when a RADIUS proxy-server is used. The proxy takes care of the Access-Request and allows only the Accounting-Request to reach the final destination, normally a WAP Gateway. Attribute nameDescription # User-nameThe string void1M User-PasswordThe string void2M NAS-IP-AddressIP-address of GGSN, to be used by the RADIUS server. This is the RADIUS External Protocol IP address of section 2.4. 4M NAS-PortAlways set to 1, if included.5O Service-TypeAlways set to 2 (Framed).6M Framed-ProtocolAlways set to 1 (PPP).7M Called-Station-IdAPN string, e.g. domain name30M Calling-Station-IDMSISDN, if configured to be included for this APN. Otherwise, not sent. 31O NAS-IdentifierAPN string, e.g. domain name32M IMSIIMSI of MS224O Charging-IdCharging Identifier used for charging of the PDP Context225O IMSI-MCC-MNCMCC and MNC-parts of IMSI of MS226O Selection ModeAPN Selection Mode. User-, SGSN-, or Subscription-selected229O GGSN-GTP-IP-AddressThe reserved GTP VIP identifying the GGSN230O Table 6: RADIUS-Access-Request with no authentication Ericssonwide Internal INTERFACE DESCRIPTION 22 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.5.3.2RADIUS Access-Accept messages A RADIUS-server must be set up either to provide or not to provide IP-addresses for MS. The Access-Accept message is allowed to contain almost any attribute. However, only those listed below will be interpreted by the GGSN RADIUS-client. RADIUS-attribute number 6, Service-Type, is a special case. GGSN does not require that this attribute be included in an Access-Accept. However, if the attribute is included, it MUST have the value 2 (Framed). Otherwise, the Access-Accept will be interpreted as an Access-Reject, resulting in a Create_PDP_Context-Response with Cause set to "User Authentication Failed".If there is a Class attribute in Access-Accept, this is sent unmodified as the Class-attribute of the Accounting-Request (start/stop) messages. The Class-attribute is never parsed or interpreted.RADIUS-server set up to provide IP-address Attribute nameDescription # Framed-IP-AddressThe IP-address provided by the RADIUS server for the MS8M ClassTo be used in Accounting-Request (Start)25O Primary DNS ServerProprietary attribute, returned from some RADIUS-servers only135O Secondary DNS Server Proprietary attribute, returned from some RADIUS-servers only136O Table 7: RADIUS-Access-Accept with IP-address If no IP-address is received, an error message will be generated by the RADIUS-client. PDP Context setup will fail with cause value "System Failure". The RADIUS-client will check that the received Framed-IP-Address is within the range of the given APN. If it is not, an error message will be generated. PDP Context setup will fail with cause value "System Failure". Access-Reject and Access-Challenge The RADIUS-server may reply to an Access-Request by an Access-Reject or by an Access-Challenge. The GGSN RADIUS-client will interpret an Access-Reject as an authentication failure. No RADIUS-attributes will be interpreted. PDP Context setup will fail with cause value "User authentication failed". The GGSN RADIUS-client will interpret an Access-Challenge as an Access-Reject. Ericssonwide Internal INTERFACE DESCRIPTION 23 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 RADIUS-server not set up to provide IP-address Attribute nameDescription # Framed-IP-AddressIP-address provided by the RADIUS server for the MS Note: If included, this address MUST be either 255.255.255.255 or 255.255.255.254 8O ClassTo be used in Accounting-Request (Start)25O Primary DNS ServerProprietary attribute, returned from some RADIUS-servers only135O Secondary DNS Server Proprietary attribute, returned from some RADIUS-servers only136O Table 8: RADIUS-Access-Accept without IP-address The RADIUS-server may include an IP-address, even though the GGSN is not expecting it. However, such a dummy address must have either of the values 255.255.255.255 or 255.255.255.254. Otherwise, an error message will be generated by the RADIUS-client. PDP Context setup will fail with cause value "System Failure". Ericssonwide Internal INTERFACE DESCRIPTION 24 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.5.3.3RADIUS Accounting Messages Accounting-Request [Start] for IP-address Allocation Accounting-Request is sent to the RADIUS-server with parameter Acct-Status-Type set to Start. This signals to the RADIUS-server that the IP-address allocated by the preceding Access-Accept will be used. The allocated IP-address is included in this message as parameter Framed-IP-Address. Attribute nameDescription # User-nameCHAP Username, PAP Username, or if no User-name provided by MS, the string void. 1M NAS-IP-AddressIP-address of GGSN, to be used by the RADIUS-server. This is the RADIUS External Protocol IP address of section 2.4. 4M NAS-PortAlways set to 1, if included.5O Service-TypeAlways set to 2 (Framed).6M Framed-ProtocolAlways set to 1 (PPP).7M Framed-IP-AddressIP-address allocated to subscriber by RADIUS-server8M ClassIncluded, if value provided by RADIUS-server in Access-Accept25C Called-Station-IdAPN string, e.g. domain name30M Calling-Station-IDMSISDN, if APN is configured to include it. Otherwise not sent31O NAS-IdentifierAPN string, e.g. domain name 32M Acct-Status-TypeAlways 1 (Start)40M Acct-Session-IDAccounting session ID. To be included in Accounting (Stop)44M Acct-AuthenticAuthentication method. Always 1 (RADIUS)45M IMSIIMSI of MS224O Charging-IdCharging Identifier used for charging of the PDP Context225O IMSI-MCC-MNCMCC and MNC-parts of IMSI of MS226O SGSN-IP-AddressIP-address of SGSN from which the PDP Context originated228O Selection ModeAPN Selection Mode. User-, SGSN-, or Subscription-selected229O GGSN-GTP-IP-AddressThe reserved GTP VIP identifying the GGSN230O Table 9: RADIUS-Accounting-Request (Start) for IP-addressThe attribute Acct-Session-Id is generated by a global counter. The Acct-Session-Id is 14 characters long, of which the first four are a restart counter, and the last ten are a session counter. So the first few session-ids (for a certain network) may be: 00010000000001, 00010000000002 .... After a large restart it will look like this: 00020000000001, 00020000000002, 00020000000003, .... Assuming constant activation rate of 192 contexts/second, and no restarts, the value of the Acct-Session-Id will toggle after 602 days. Under realistic conditions, it should not run out during the lifetime of the GGSN. Note that if RADIUS Access-Request is used for authentication, but the MS IP-address is not allocated by the RADIUS-server, the RADIUS Accounting-Request (Start) will still have the above format, with the attribute Class included, if provided in the Access-Accept. Ericssonwide Internal INTERFACE DESCRIPTION 25 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 Accounting-Response The RADIUS-server records the request and sends an Accounting-Response to the GGSN. The Accounting-Response is not expected to contain any attributes. Reception of a valid Accounting-Response will thus be interpreted by the GGSN as a positive reply.If no valid Accounting-Response is received within a configurable number of retransmissions, the RADIUS-client will return an error to the GGSN-application, causing the PDP-activation to be rejected. Accounting-Request [Stop] for IP-address De-Allocation Upon PDP Context deactivation, the GGSN will send to the RADIUS-server an Accounting-Request, with parameter Acct-Status-Type set to Stop. This signals to the RADIUS-server that the allocated IP-address will no more be used, and that it may be made available for allocation to another entity. Attribute nameDescription # User-nameCHAP Username, PAP Username, or if no User-name provided by MS, the string void. 1M NAS-IP-AddressIP-address of GGSN, to be used by the RADIUS-server. This is the RADIUS External Protocol IP address of section 2.4. 4M NAS-PortAlways set to 1, if included.5O Framed-IP-AddressIP-address allocated to subscriber by RADIUS-server8M ClassIncluded, if value provided by RADIUS-server in Access-Accept25C Called-Station-IdAPN string, e.g. domain name30M Calling-Station-IDMSISDN, if APN is configured to include it. Otherwise not sent31O NAS-IdentifierAPN string, e.g. domain name32M Acct-Status-TypeAlways 2 (Stop)40M Acct-Session-IDAccounting session ID. Same value as in corresponding Start.44M Acct-AuthenticAuthentication method. Always 1 (RADIUS)45M IMSIIMSI of MS224O Charging-IdCharging Identifier used for charging of the PDP Context225O IMSI-MCC-MNCMCC and MNC-parts of IMSI of MS226O SGSN-IP-AddressIP-address of SGSN from which the PDP Context originated228O Selection ModeAPN Selection Mode. User-, SGSN-, or Subscription-selected229O GGSN-GTP-IP-AddressThe reserved GTP VIP identifying the GGSN230O Table 10: RADIUS-Accounting-Request (Stop) for IP-address de-allocation The RADIUS-server records the request and sends an Accounting-Response to the GGSN. Ericssonwide Internal INTERFACE DESCRIPTION 26 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 Accounting-Request [Accounting-On] This message is sent at GGSN node restart and at large restart. It signals to the RADIUS-server that all IP-addresses reserved for this APN can be released, i.e. made free for allocation. Note that this message will be sent once for each one of the GGSNs APNs, which is configured to access this RADIUS-server. This is the case, irrespectively of whether the APN receives its IP-addresses from the RADIUS-server or in any other way. Neither does it depend on whether the APN has been configured to send Accounting-Requests. This message is also sent whenever a new APN that uses a RADIUS-server is configured.If such an APN is re-configured, this message will be sent, if the modification necessitates removal of all active PDP Contexts belonging to the APN. Cf. section 2.6.4 below. Attribute nameDescription # NAS-IP-AddressIP-address of GGSN, to be used by the RADIUS-server. This is the RADIUS External Protocol IP address of section 2.4. 4M NAS-PortAlways set to 1, if included.5O Called-Station-IdAPN string, e.g. domain name30M NAS-IdentifierAPN string, e.g. domain name32M Acct-Status-TypeAlways 7 (Accounting-On)40M Acct-Session-IDAlways 044M Table 11: RADIUS-Accounting-Request (Accounting-On) The RADIUS-server records the request and sends an Accounting-Response to the GGSN. Ericssonwide Internal INTERFACE DESCRIPTION 27 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 Accounting-Request [Start] for Charging (Not preceded by Access-Request) This type of Accounting-Request is used for forwarding the MSISDN of the MS to a server, which can receive a RADIUS Accounting-Request, but cannot handle a RADIUS Access-Request. In the usual case, this server is a WAP Gateway. In the earliest GGSN-releases, the Accounting-Request must always be preceded by an Access-Request. Thus, a proxy server had to be installed for handling the RADIUS Access-Request. Cf. the treatment of the case neither PAP nor CHAP in section 2.5.3.1 above. Note that the purpose of this message is to forward the pair MSISDN / IP-address to the WAP Gateway. Thus, the IP-address must be included in this message. The APN must be configured to include the MSISDN in the Accounting-Request. Accounting-Request is sent to the RADIUS-server, with parameter Acct-Status-Type set to Start. The messages below have NOT been preceded by an Access-Request. Thus, the attribute Class is never present.Attribute nameDescription # User-nameCHAP Username, PAP Username, or if no User-name provided by MS, the string Void. 1M NAS-IP-AddressIP-address of GGSN, to be used by the RADIUS-server. This is the RADIUS External Protocol IP address of section 2.4. 4M NAS-PortAlways set to 1, if included.5O Service-TypeAlways set to 2 (Framed).6M Framed-ProtocolAlways set to 1 (PPP).7M Framed-IP-AddressIP-address allocated to MS by DHCP, GGSN, or static8M Called-Station-IdAPN string, e.g. domain name30M Calling-Station-IDMSISDN31M NAS-IdentifierAPN string, e.g. domain name 32M Acct-Status-TypeAlways 1 (Start)40M Acct-Session-IDAccounting session ID44M IMSIIMSI of MS224O Charging-IdCharging Identifier used for charging of the PDP Context225O IMSI-MCC-MNCMCC and MNC-parts of IMSI of MS226O SGSN-IP-AddressIP-address of SGSN from which the PDP Context originated228O Selection ModeAPN Selection Mode. User-, SGSN-, or Subscription-selected229O GGSN-GTP-IP-AddressThe reserved GTP VIP identifying the GGSN230O Table 12: RADIUS-Accounting-Request (Start) for charging The RADIUS-server records the request and sends an Accounting-Response to the GGSN. The Accounting-Response is not expected to contain any attributes. Reception of a valid Accounting-Response will thus be interpreted by the GGSN as a positive reply.If no valid Accounting-Response is received within a configurable number of retransmissions, the RADIUS-client will return an error to the GGSN-application, causing the PDP-activation to be rejected. Ericssonwide Internal INTERFACE DESCRIPTION 28 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 Accounting-Request [Stop] for Charging (not preceded by Access-Request) Upon PDP Context deactivation, the GGSN will send to the RADIUS-server / WAP Gateway an Accounting-Request, with parameter Acct-Status-Type set to Stop.Attribute nameDescription# User-nameCHAP Username, PAP Username, or if no User-name provided by MS, the string void. 1M NAS-IP-AddressIP-address of GGSN, to be used by the RADIUS-server. This is the RADIUS External Protocol IP address of section 2.4. 4M NAS-PortAlways set to 1, if included.5O Framed-IP-AddressIP-address allocated to MS by DHCP, GGSN, or static8M Called-Station-IdAPN string, e.g. domain name30M Calling-Station-IDMSISDN 31M NAS-IdentifierAPN string, e.g. domain name32M Acct-Status-TypeAlways 2 (Stop)40M Acct-Session-IDAccounting session ID. Same value as in corresponding Start.44M IMSIIMSI of MS224O Charging-IdCharging Identifier used for charging of the PDP Context225O IMSI-MCC-MNCMCC and MNC-parts of IMSI of MS226O SGSN-IP-AddressIP-address of SGSN from which the PDP Context originated228O Selection ModeAPN Selection Mode. User-, SGSN-, or Subscription-selected229O GGSN-GTP-IP-AddressThe reserved GTP VIP identifying the GGSN230O Table 13: RADIUS-Accounting-Request (Stop) for Charging The RADIUS-server records the request and sends an Accounting-Response to the GGSN. Ericssonwide Internal INTERFACE DESCRIPTION 29 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.5.3.4RADIUS-Client Retransmission Strategy The GGSN RADIUS-client never tries to connect to the secondary RADIUS-server first by default. It will always try the primary RADIUS-server first, when sending Access-Request or Accounting-Request (start). No changeover is made for Accounting-Request (Accounting-On), since the message is sent to both the primary and secondary RADIUS-server.Cf. the configuration instruction Ref [6] for a description of how to set the retransmission parameters. The number of tries is configurable per server. Call it N1 for the primary server and N2 for the secondary.IP-address not allocated by a RADIUS-server If the RADIUS-server is not used for allocating the IP-address, there is a simple per-message retry strategy. First N1 tries are made against the primary server. If that does not work, N2 tries will be made against the secondary server. If the secondary server does not respond, an error message will be generated, resulting in a Create_PDP_Context-Response with cause value "System Failure". Otherwise, context setup proceeds. IP-address allocated by a RADIUS-server If the RADIUS-server allocates IP-addresses, the retry strategy is context-based. The reason is that it must be made certain that the Accounting-Request (Start) is sent to the same RADIUS-server that allocated the IP-address in the Access-Accept. Case 1: Primary server up This is the usual case. Requires no comments. Case 2: Primary server definitely down First N1 attempts are made to send an Access-Request to the primary server. As this does not work, N2 attempts will be made to send Access-Requests to the secondary server. If this is unsuccessful, an error message will be generated. If an Access-Accept is received from the secondary server, N2 attempts will be made to send an Accounting-Request (Start) to the secondary server. If this is unsuccessful, an error message will be generated, resulting in a Create_PDP_Context-Response with cause value "System Failure". Otherwise, context setup proceeds. Case 3: Primary server fails during context setup First N1 attempts are made to send an Access-Request to the primary server. An Access-Accept is eventually received. Following this, N1 attempts will be made to send an Accounting-Request (Start) to the primary server. If this is unsuccessful, N2 attempts will be made to send an Access-Request (not Accounting-Request) to the secondary server. If this is unsuccessful, an error message will be generated, resulting in a Create_PDP_Context-Response with cause value "System Failure". If an Access-Accept is received from the secondary server, N2 attempts will be made to send an Accounting-Request (Start) to the secondary server. If this is unsuccessful, an error message will be Ericssonwide Internal INTERFACE DESCRIPTION 30 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 generated, resulting in a Create_PDP_Context-Response with cause value "System Failure". Otherwise, context setup proceeds. An Accounting-Request(stop) is sent ONLY to the RADIUS-server that replied to the corresponding Accounting-Request(start). I.e. if the primary RADIUS-server disconnects after the Access-Accept, no Accounting-Request(stop) will be sent to it. Not even if the secondary RADIUS-server disconnects. 2.5.3.5Proprietary RADIUS Attributes The RADIUS-attributes listed in Table 14 below are proprietary for the Ericsson GGSN RADIUS-client. Several of these attributes are included in Ref [2], but with different Attribute type numbers.The Attribute lengths given are in octets. The length does not include the type and the length octets. String = ASCII = UTF-8, not hexadecimal Attribute NameAttribute type number LengthValue type Primary DNS-server 1354Address Secondary DNS-server1364Address IMSI224VariableString Charging-Id2254Long Integer IMSI-MCC-MNC2266String SGSN-IP-Address2284Address Selection-Mode2291String GGSN-GTP-IP-Address2304Address Table 14: Proprietary RADIUS Attributes 2.5.3.6Descriptions of proprietary RADIUS attributesIMSIThe GGSN can provide the full IMSI and/or the MCC and MNC parts of the IMSI in the RADIUS messages. Enabling delivery of the full IMSI and/or the MCC and MNC parts of the IMSI in the RADIUS messages is independently configurable on both a per message type and a per APN basis.The format of the IMSI attribute is a decimal-coded ASCII-string of variable length. The format of the IMSI-MCC-MNC attribute is a decimal-coded ASCII-string of 6-octet length. The first 3 digits are the MCC. The last three digits are the MNC. If the length of the MNC is 2, the fourth digit of the attribute is set to zero. These attributes make it possible for operators to charge visiting subscribers for content-charged services. This also makes it possible to control access to a non-content-charged service on the basis of a visiting subscribers home network identity. Ericssonwide Internal INTERFACE DESCRIPTION 31 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 Selection-Mode The GGSN can include in the RADIUS Access-Request and Accounting-Request messages the APN Selection Mode. Enabling delivery of the Selection-Mode is independently configurable on both a per message type and a per APN basis.The format of this attribute is a 1-digit string, mapping from the binary value of the selection mode in the Create PDP Context message. Cf. section 7.9.13 of Ref [34] and section 7.7.12 of Ref [35]. When the references provide for interpretation of the value, e.g. map 3 to 2, this is done by GGSN. This attribute allows control of access to public APNs for the operators subscribers who may use public APNs when roaming. This provides an additional security feature in GGSN. Charging-ID The attribute Charging-Id can be configured to be included in the RADIUS- messages Accounting-Request (Start), Accounting-Request (Stop), and in Access-Request.This attribute provides PDP Context identification even for a WAP GW. This way, correlation between the Service Data Record and the network CDRs can be achieved. Inclusion of the attributes Charging-Id and GGSN-GTP-IP-Address provides support for MMS in GGSN. SGSN-IP-Address This proprietary attribute is the IP-address of the SGSN from which the PDP Context originated. It is by default always included in the RADIUS-messages Accounting-Request (Start) and Accounting-Request (Stop). However, it can be configured not to be included. GGSN-GTP-IP-Address This proprietary attribute is the reserved GTP VIP that identifies the GGSN on the GPRS backbone network. Cf. the Gn interface description Ref [72]. This attribute can be configured to be included in Access-Requests, in Accounting-Requests (start), and in Accounting-Requests (stop).Inclusion of the attributes GGSN-GTP-IP-Address and Charging-Id provides support for MMS in GGSN. This IP-address must not be mixed up with the GGSN IP-address used for identifying the APN. Cf. section 2.4.2 above. Ericssonwide Internal INTERFACE DESCRIPTION 32 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.5.3.7Enhancements to MSISDN It is possible to deliver to the RADIUS-server any of: ! no MSISDN! the actual MSISDN ! a preconfigured dummy MSISDN Consistent with Ref [48], it is possible to configure the dummy MSISDN as an arbitrary string of printing characters. Separate values of the dummy MSISDN are configurable for each type of RADIUS-message on a per APN basis. This flexibility greatly simplifies interworking between the GGSN and certain types of RADIUS servers and WAP Gateways. It also provides the subscriber with a choice between customized access (using the actual MSISDN) and anonymous access (using the dummy MSISDN). 2.5.3.8Use of UDP Source Ports RADIUS messages are sent in UDP frames. The UDP header contains a destination port and a source port. The destination port MUST be the standard-port for the RADIUS-message, i.e. 1812 for Access-Request and 1813 for Accounting-Request. According to the UDP-standard (Ref [74], page 1) the source port can be selected randomly from a valid port-domain by GGSN.The problem with using a fix value for the UDP source port is that the number of simultaneous RADIUS-sessions thereby is restricted to 256, which is the maximum number of identifiers (only one octet; the second octet in the RADIUS header). In this case, heavy signaling (many activations per second) may result in discarded packages. From section 2.5 of RFC 2865, it follows that packets arriving at a RADIUS-server within a short time span with the same NAS IP Address, same NAS UDP source port, plus same RADIUS Request ID will probably be discarded by the RADIUS server. The RADIUS-server will interpret the later packets as retransmissions of a previous one. In order to solve this problem, GGSN is able to change the value of the UDP source port, and keep track of identifiers per port. As UDP source port, a value between 40001 and 40040 is used for Access-Request, and a value between 40101 and 40140 for Accounting-Request. The RADIUS-session is then identified by the pair {Source port, Id}. For each ID (0 - 255), the UDP source port of Access-Requests will be sequentially incremented from 40 001 to 40 040. Then the ID will be incremented and the UDP source port value will start from 40 001 again. This allows for 40 256 concurrent communications instead of just 256. Not all RADIUS-servers are able to handle this use of the UDP source port. A RADIUS-server, which does not differentiate on port-numbers, will interpret two messages with the same RADIUS message Identifier and different UDP source ports, as the latter message being a retransmission of the former. To avoid this, it is possible to use one UDP source port only for communicating with such a RADIUS-server. This is part of the APN Configuration (Ref [6]), and the parameters are called Primary Use Single Source Port and Secondary Use Single Source Port, respectively. Cf. Table 22 below. The default values of these two parameters are No. I.e. by default, GGSN will use multiple UDP source ports Ericssonwide Internal INTERFACE DESCRIPTION 33 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.5.4DHCP Relay Agent Support GGSN includes a subset of the DHCP Relay agent functionality. Only the subpart necessary for dynamic allocation of IP-addresses has been implemented. There is no support for the full DHCP-functionality mentioned in section 13 of Ref [1] and Ref [2]. The DHCP Relay Agent is based on the DHCP-standards Ref [57] and Ref [58].The DHCP Relay Agent in GGSN leases IP-addresses from a DHCP-server in an external PDN. When a Create_PDP_Context-Request request arrives at the GGSN, the DHCP Relay Agent sends a DHCPDISCOVER message to a pre-configured DHCP-server. This message is unicast, not broadcast. The IP-address of this DHCP-server is part of the APN configuration data.If the DHCP-server does not reply to the DHCPDISCOVER within 4 seconds, the DHCP Relay Agent will retransmit the message. There is no limit on the number of retransmissions. The DHCP Relay Agent relies on a timer set for the PDP Context to determine when to abort. I.e. it is not the DHCP Relay Agent itself that aborts, but the GGSN-application. The GGSN-application will abort DHCP communication after 5 seconds. When the DHCP-server replies with a DHCPOFFER to the DHCP Relay Agent, one of the DHCP options sent is lease time, option 51. The lease time tells the DHCP Relay Agent how long it can use the IP-address. The lease time shall be at least 60 seconds. A timer set to the lease time is started in GGSN, when it receives the DHCPOFFER. The DHCP Relay agent reserves the offered IP-address by sending a DHCPREQUEST to the DHCP-server. The server replies with a DHCPACK. After this, the GGSN can assemble a Create_PDP_Context-response. Should the DHCP-server not reply, or if its reply contains no IP-address or an IP-address not within the range of the APN, PDP Context setup will fail. The Cause value in the Create_PDP_Context-Response will then be "System failure".Before the lease time expires, and the PDP Context is still active, the DHCP Relay Agent sends a lease renewal request to the DHCP-server. A DHCPRENEW message (section 2.5.4.7 below) is used for this purpose. If the DHCP-server is reachable and allows an extension of the lease, the DHCP-server replies with a DHCPACK, confirming a renewal of the lease and providing a new lease time.When a PDP Context is deactivated, the DHCP relay agent sends a DHCPRELEASE to the DHCP-server, which ends the lease in the DHCP-server. The lease timer for the leased IP-address in the GGSN is removed. If the DHCP-server does not reply to a DHCPREQUEST/DHCPRENEW message with a DHCPACK within 4 seconds, the message will be retransmitted, as described in the third paragraph (on DHCPDISCOVER) above.Should a DHCP-server become unreachable from GGSN, the DHCP Relay Agent will not be able to renew any leases of IP-addresses. In this case, the DHCP Relay Agent will cease to use these IP-addresses as their respective lease times expire. When an IP-address lease time expires for this reason, a PDP Context deactivation will be initiated; immediately disconnecting the MS from the network.When the GGSN restarts, all PDP Context data is removed. The GGSN does not keep track of DHCP-allocated IP-addresses in use. Thus, no DHCPRELEASE is sent for those addresses after restart. The option field in the DHCP-messages is padded to a minimum length of 312 bytes. There can be no more than one DHCP-server per APN. Redundancy must thus be handled at the DHCP-server. The configured DHCP-server must be inband, i.e. located in the network that receives the payload traffic of the APN. Ericssonwide Internal INTERFACE DESCRIPTION 34 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.5.4.1DHCPDISCOVER message When an IP-address is requested, the DHCPDISCOVER is unicast to the DHCP-server configured for the APN. Broadcast is not used. The following attributes are supported: Field Description Value ciaddrEnd user address 0.0.0.0 giaddrRelay agent IP address External Protocol IP address of section 2.4 yiaddr End user address 0.0.0.0 option 53 DHCP Message type 1 option 61 Client-identifier Unique identifier for the PDP Context Table 15: Options for DHCPDISCOVER message 2.5.4.2DHCPOFFER message The following attributes are supported: Field Description Value yiaddrEnd user address The offered IP-address option 6 DNS server addresses option 51 IP address lease time Must be at least 60 seconds option 53 DHCP Message Type 2 Table 16: Options for DHCPOFFER message Ericssonwide Internal INTERFACE DESCRIPTION 35 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.5.4.3DHCPREQUEST message The following attributes are supported Field Description Value ciaddrClient IP address 0.0.0.0 giaddrRelay agent IP address External Protocol IP address of section 2.4 option 50 Requested IP address The offered IP-address option 51 IP address lease time option 53 DHCP Message Type 3 option 54 DHCP Server address option 61 Client-identifier Unique identifier for the PDP Context Table 17: Options for DHCPREQUEST message 2.5.4.4DHCPACK message The following attributes are supported: Field Description Value yiaddrEnd user address The offered IP-address option 51 IP address lease time Must be at least 60 seconds Table 18: Options for DHCPACK message Option 51 is considered only in case of renewal of a leased IP-address. I.e. as a reply to DHCPRENEW. 2.5.4.5DHCPRELEASE message The following attributes are supported: Field Description Value giaddrRelay agent IP address External Protocol IP address of section 2.4 yiaddrEnd user address The offered IP-address option 53 DHCP Message Type 7 option 54 DHCP Server address option 61 Client-identifier Unique identifier for the PDP Context Table 19: Options for DHCPRELEASE message 2.5.4.6DHCPNACK message No attributes are expected. Ericssonwide Internal INTERFACE DESCRIPTION 36 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.5.4.7DHCPRENEW message The DHCPRENEW message is simply a variant of the DHCPREQUEST message. It is used by the DHCP Relay Agent for extending the lease of an already allocated IP-address.The following attributes are supported: Field Description Value yiaddrEnd user address The offered IP-address giaddrRelay agent IP address External Protocol IP address of section 2.4 option 53 DHCP Message Type 3 option 61 Client-identifier Unique identifier for the PDP Context Table 20: Options for DHCPRENEW message 2.5.4.8Restricting PDP Context Lifetime with DHCP Using DHCP for IP-address allocation allows the MS to use the IP-address allocated by the DHCP-server for a period of time. When an IP-address lease expires, the DHCP Relay Agent must request continued use of the IP-address. Otherwise, the IP-address will be de-allocated. By refusing the GGSN Relay Agent's renewal request, the DHCP-server thus sets the lifetime of the PDP Context. 2.5.4.9Use of Client-identifier In DHCPDISCOVER, the option 61, Client-identifier, includes a unique identifier for the PDP Context. The same identifier is included in all Relay_Agent-to-Server DHCP-messages.The Client-identifier is never included in the Server-to-Relay_Agent DHCP-messages. However, according to Ref [57], section 2, the xid, transaction ID is always included in a DHCP-message. The xid is a unique, random number, which connects a client-request to a server-response. This way, the subscriber is always identified in each DHCP-message. Ericssonwide Internal INTERFACE DESCRIPTION 37 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.5.5ICMP The following ICMP messages are supported when using APN routing mechanism: ICMP Time Exceeded: This message is sent back to the source of the IP packet if the TTL field becomes less or equal to one, after the GGSN has decremented the field. ICMP Destination Unreachable code 4: This message is sent back to the source of the IP packet, if the packet is larger than the MTU and the "Dont Fragment" bit in the IP header is set. ICMP Echo Reply: This message is sent back to the source of the IP packet if the received IP packet was an ICMP Echo Request. This is only sent for the GGSN IP address. For Normal IP-routing, all ICMP messages in Ref [33] are supported by GGSN. However, GGSN does not support the ICMP-extensions ICMP Address Mask Request and ICMP Address Mask Reply, as listed in RFC 950, Ref [67]. The operator may configure which ICMP messages the GGSN shall support by the packet filtering function. Ericssonwide Internal INTERFACE DESCRIPTION 38 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.5.6Packet Filtering The purpose of IP packet filtering is to provide security to the external connections of the GGSN node. There is one IP packet filter for every external interface on the GiR PIUs. Each filter has one or more filter rules. The filter rules apply to either inbound or outbound IP traffic on the interface. Rules for inbound traffic specify the set of IP packets, which are allowed or not allowed to enter the GGSN node on this interface. Rules for outbound traffic specify the set of IP packets, which are allowed or not allowed to leave the GGSN through this interface. Logging should generally be set to false (the default setting) on all interfaces since it affects performance. Valid IP packets will pass through the interface as if there was no filter. IP packets that are not allowed are silently discarded. GGSN supports packet filters for the IP-, TCP-, UDP-, and ICMP-headers. The filtering may be based on a combination of the parameters listed in Table 21 below. ParameterFilter functionHeader Source IP-addressMasking of addressIP, TCP, UDP, and ICMP Destination IP-addressMasking of addressIP, TCP, UDP, and ICMP IP optionsAllowed or disallowedIP, TCP, UDP, and ICMP Next protocolComparison with the field specifying the protocol after the IP header IP Source portComparison of valueTCP and UDP Destination portComparison of valueTCP and UDP TCP flagMasking of flagTCP ICMP message typeComparison of valueICMP Table 21: Packet Filter Rules Large IP-packets are occasionally transferred in several fragments. GGSN applies the filter rules on all fragments of an IP packet and removes all fragments, if any filter rule is applicable on the IP packet. In some situations, the fragments of an IP packet may be received in switched order. Since the packet filtering is based on the information in the header, GGSN cannot handle filtering of IPsec packets with the fragments in switched order. In case of IPsec in tunnel mode, the packet is exposed to a two-stage filtering policy. One filter examines the outer IP header, whereas the second filter tries to find a match against the inner IP header. As the second header is encrypted, the second filter has to be applied before encryption (outgoing packet) or after decryption (incoming packet) The filter policies are kept in a Security Policy Database (SPD) in the GGSN node. The SPD is set up and maintained via the O&M function of the GPRS application. In addition to these configurable IP packet filters, GGSN has hard coded filters, which protect against: ! too large IP packets, e.g. malformed ICMP packets such as "ping-of-death" ! too small fragmented packets, e.g. TCP flag masquerading Under some circumstances, operators may desire to prevent direct MS-to-MS communication, e.g. pinging. If APN-routing is used, the packets are always sent to the external PDN (ISP or corporate), Ericssonwide Internal INTERFACE DESCRIPTION 39 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 where appropriate filtering is possible. However, if an APN is using IP-routing, there is no way to prevent two MSs from pinging each other. The reason is that the packets never reach the Gi-interface, why no filtering is possible.For further details, see Ref [11], Ref [17], Ref [18], and Ref [62]. 2.5.7IPsec IPsec is a network layer protocol standard for secure transfer of packets across insecure external IP PDNs.IPsec can be used in transport mode or in tunnel mode. For the Gi interface, only tunnel mode is relevant. A tunnel is a fixed path between two peers in which packets are sent without regards to the addresses or headers of the original packets. On the Gi interface, tunneling is primary used for sending IP packets over networks with conflicting or overlapping address ranges. This is done by creating a new data packet with the original packet as payload. That means that a new IP header and the tunneling protocol header are added at the front of the original packet. The two principal IPsec protocols are: ! Authentication Header (AH), which provides data origin authentication and data integrity. ! Encapsulating Security Payload (ESP), which provides data confidentiality, data origin authentication, and data integrity IPsec tunnels are created by configuring Security Associations, SA, between the GGSN node and an external router/host. The Security Association contains for example an SPI (Security Parameter Index), the protocol used, the GGSNs IPsec tunnel VIP-address, the remote IPsec tunnel IP-address, the key, and information whether the SA is inbound or outbound. SAs are unidirectional. This means that there must exist two SAs, one for inbound and one for outbound traffic, to enable two-way communication. The values for an SA depend on the end-points of the IPsec connection. Both end-points of the IPsec connection must have the same values for the SA; only the directions are different.An SA is set up and maintained via the O&M function in the GSN. Consult Ref [6] and Ref [61]. Packet filtering detects what packets are to be handled with IPsec functionality. Each GiR PIU has a subboard called the Security Gateway, which stores information about SAs. The Security Gateway adds or removes the IPsec header and encrypts or decrypts the IPsec packet.In order to inject outbound IP packets into an IPsec tunnel, packet filters are used. Filters are used also for capturing inbound IPsec packets and passing these to the Security Gateway for decryption or authentication. Another filter can be applied to decapsulated IP packets. This means that there are two levels of filtering applied on incoming IPsec packets. First, the filter of the interface that the IPsec packets arrive at is applied on the header. Second, another filter is applied to the decapsulated IP packet.IPsec tunnels can be used with APN routing towards Corporate, RADIUS APN, or ISP, to provide VPNs. IPsec functions are also supported without SA configuration, i.e. a pure tunnel mechanism between the GGSN node and an external router/host. Ericssonwide Internal INTERFACE DESCRIPTION 40 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 IPsec functions according to Ref [49], Ref [50], Ref [51], Ref [52], Ref [53], Ref [54], Ref [55], and Ref [56] are supported on the Gi interface. For further details regarding the use of IPsec, see Ref [17] and Ref [18]. For configuration information, consult Ref [6] and Ref [61]. Protocols like Internet Key Exchange (IKE) which allow the automated setup of Security Associations and the negotiation and exchange of security protocols and keys are not supported. 2.5.7.1IPsec Key Agility The IPsec implementation of GGSN has perfect key agility. This means that consecutive IP packets may belong to different SAs without loss of forwarding capacity. I.e. the number of SAs defined will not affect performance. 2.5.7.2APN Routing with IPsec A GGSN-internal link-layer tunnel between a GiA and a GiR can be connected to an IPsec tunnel defined by a pair of SAs at the GiR. This enables APN routing to the external PDN connected to the IPsec-tunnel. The IPsec SA contains information on which protocols are used, direction of traffic and IP-addresses. Since the SAs are unidirectional, an IPsec tunnel requires two SAs, one for each direction. A Gi IPsec VIP should be configured for terminating an IPsec-tunnel. The same Gi IPsec VIP can be used to terminate several IPsec-tunnels, since they are separated by an ID based on destination address, SPI, and algorithm, as defined in the IPsec standards.Consult the System Characteristics document, Ref [63], for figures on how many IPsec-tunnels can be defined in GGSN 4.0 and the corresponding document for CGSN G 3.0, Ref [76] 2.5.7.3IPsec Redundancy An important part of GSN security is GGSN availability. To ensure IPsec redundancy, all SAs for a specific interface exist on all Security Gateways connected to that interface. This also means that there is no replay protection. When defining an SA, the configuration is set for both GiRs automatically. This way, the IPsec tunnels are not isolated to a single GiR PIU. If a GiR PIU goes down, the IPsec tunnels on the Gi interface will remain available, as long as another GiR PIU is up and running. A criterion for the redundancy is that an IPsec SA does not use the external interface IP-address of a GiR as termination address for its IPsec-tunnel. Instead, it should use a Gi IPsec VIP-address. A VIP can be defined by configuring a static route for the VIP towards a loopback interface on the GiR PIUs. The static routes are then exported so that external routers receive routing information about the VIP. Redundancy for the external PDN can be solved in a corresponding way by configuring two routers containing the same information. Ericssonwide Internal INTERFACE DESCRIPTION 41 (64)Prepared (also subject responsible if other)No. EAB/UFG/N Kent Eriksson21/1056 - CSA 250 11 Uen ApprovedCheckedDateRevReference EAB/UFG/NC Patrik Gustafson2003-10-02H Ericsson AB 2003 2.