Pv4 and IPv6 Migration in IMS Environment

  In the original IP Multimedia Subsystem (IMS) specification[1] given by 3GPP, the IMS framework was envisioned to be operating on an IPv6 network. When the fixed network started to use IMS framework in the Next Generation Network (NGN) architecture[2-3], the issue of IPv4 and IPv6 interworking becomes more pronounced due to the widespread usage of the IPv4 network.
The central issue of IPv4 and IPv6 interworking is avoiding unnecessary Network Address and Port Translation Protocol Translation (NAPT-PT) operations inside the network. The major drawbacks of such operation are well understood and are listed as follows:

• Bottleneck location for media flows;
• Single point of failure at the NAPT-PT location;
• Breaks signaling protocols without Application Layer Gateway (ALG).

  In discussing the IPv4 and IPv6 interworking, there is a need to differentiate mobile terminals and fixed terminals. For mobile terminals, due to the restriction of Packet Data Protocol (PDP) type[4], a mobile terminal can only operate in IPv4 or IPv6 mode only. For fixed terminals, it would be relative easy to operate in both modes.

  Both the signaling pat hand media path will have IPv4 and IPv6 interworking issues. In this paper, the networking environment and architectural components are articulated in Section 2. In Section 3, the objectives of IPv4 and IPv6 interworking and the processing rules in various architectural components are given. Section 4 will perform extended scenario analysis to ensure that the operation rules given in Section 3 indeed satisfy the objectives outlined.

2 Networking Environment
Figure 1 outlines the networking environment which will be used as the base of the discussion.
In this network environment, the User Equipment (UE) can be both mobile and fixed. The mobile UE is assumed to be connected to a Universal Mobile Telecommunication System (UMTS) network, characterized by Serving GPRS Supporting Nodes (SGSNs) and Gateway GPRS Supporting Nodes (GGSNs). The mobile access network, which consists of GGSN and SGSN, is assumed dual stack (i.e. having both IPv4 and IPv6 capabilities). Furthermore, the mobile access network is not capable of performing NAPT-PT operations. If IPv4 is used, the IPv4 address realm will be the same as that of the provider’s core network, which is further assumed to be private (Note, it would be much simpler if it is public).

  The fixed UE is connected to the service provider’s network via a gateway, which is performing Network Address Translation (NAT) operation for IPv4 addresses to alleviate the IPv4 address space issues. As far as the network is concerned, the first entry point will be Resource Control Enforcement Function[5] (RCEF). The border control for the fixed network is located in Core Border Gateway Function (C-BGF) and it can perform the NAPT-PT operation. The fixed access network is assumed to be dual stack and, if IPv4 address is used, it is assumed to be private and every access network can have its specific, independent addressing plan. The NAPT-PT operation in the C-BGF is controlled by Access Resource Admission Control Function (A-RACF) and Proxy Call Control Function (P-CSCF) in the control plane.

  The provider’s core network connects both the mobile and fixed access network. The provider’s core network is also assumed to be dual stack with IPv4 operating in its private addressing realm. The provider’s core network is connected to the public network via Interconnect Border Gateway Function (I-BGF). I-BGF is capable of performing NAPT-PT operations, under the discretion of Interrogating Call Session Control Function (I-CSCF) or Interconnect Border Control Function (IBCF) in the control plane.

3 Objectives
The overall objective is to minimize the invocation of NAPT-PT or NAPT inside the provider’s network. The proposed solution, outlined by the processing rules contained in this document, will limit the NAPT-PT operation at most once inside the provider’s network under all the situations for the media path.

  This solution will also introduce the minimum required NAPT operations. If there is a required NAPT operation along the media path for IPv4 address realm mismatches, there will be no NAPT-PT operation for protocol conversion purpose only.

  The provider’s network is bordered by the IBGF, GGSN, and C-BGF at the transport and media layer. The overall, generic objectives can be further articulated into the following items, with consideration of minimum NAPT-PT/NAPT operation and also to minimize call processing requirements:

  （1） The solution will ensure that NAPT-PT will only be invoked once inside a single provider’s network for the media path.

  （2） NAPT operations will be combined with the NAPT-PT operations whenever it is possible.

  （3） The solution will cause detour of the media traffic due to NAPT-PT usage only when there is no NAPT-PT capable network elements along the normal media path.

  （4） The solution will be independent of network IPv4 addressing plans in the access network and the provider’s core network, while the IPv6 address is assumed to be global.

  （5） The solution will avoid unnecessary invocation of service logic in Serving Call Session Control Function (S-CSCF) because of recursion of the signaling path (e.g. using 305 Session Initiation Protocol (SIP) response from downstream nodes of S-CSCF).

4 NAPT-PT Location Determination
In this section, the NAPT-PT/NAPT related algorithms for determining where the operation is to be performed, if it will be performed at all. The NAPT-PT/NAPT processing algorithms will be imposed upon P-CSCF, Media Gateway Control Function (MGCF), Media Resource Function (MRF), Application Servers (AS), and the IBCF in a coordinated fashion.

4.1 Network Assumptions
It is assumed that the provider’s access address realm, the provider’s core address realm, and the public Internet are all distinct IP address realms for IPv4. If some of the abovementioned IP realms are shared, the processing rules discussed in next section can also be applied because the IPv4 address realms are only imposing NAPT requirements.

  In terms of NAPT-PT operations, the merging of those address realms will not affect the NAPT-PT locations in this solution while the current work assumption presents the most challenging situation. There will be no change of the processing rules due to the difference in network addressing plans for IPv4.

  It is assumed that all equipment along the signaling path is dual stack network elements supporting RFC 4092 and RFC 4091, i.e. Alternate Network Address Type (ANAT) functions. The network elements performing NAPT functions can also perform NAPT-PT functions.
It is further assumed that some border elements at the network edge are not capable of NAPT-PT/NAPT operation. Hence the network, on the access side, can be classified into two types:

  (1) Type A: This type of access network is capable of performing
NAPT-PT and NAPT operations (e.g. C-BGF).

  (2) Type B: This type of access network is not capable of performing NAPT-PT and NAPT operations (e.g. GGSN)

  The access network type designation will be used for presentation purposes only. Any decision regarding the type of the access network would be local (e.g. the P-CSCF knows if it has a corresponding SPDF and C-BGF in order to perform the NAPT-PT task).

  For the purpose of the presentation clarity, the border element C-BGF is assumed to be NAPT-PT and NAPT capable while the GGSN does not have NAPT-PT and NAPT functionalities.
In general, P-CSCF with corresponding SPDF and C-BGF are considered as Type A, and all the other types of network are considered to be Type B.

4.2 The Algorithms
The solution is based on the following processing algorithms at the P-CSCF, MGCF, Media Resource Function Controller (MRFC), AS, and IBCF.

4.2.1 P-CSCF/IBCF NAPT Processing Algorithm
The detection point for this operation is on the originating and terminating
P-CSCF or IBCF.

  This operation is outlined by Rule G1: NAPT invocation is performed whenever the address realm mismatch is detected for IPv4 traffic.

4.2.2 Originating P-CSCF/MGCF/AS/MRFC
The "originating" side means the side originates the initial SIP INVITE Request for the session.

  The following two rules outline the processing that shall be performed on forwarding SIP INVITE Request and 200 SIP Response.

  (1) Rule O1
  If there is only one address type in the Session Description Protocol (SDP) of the SIP INVITE Request, the P-CSCF in the Type A access network shall emulate a dual stack UE (Principal P2).

  The Dual Stack Emulation (DSE) for the UE by the P-CSCF reformats the SDP with ANAT groups to offer both address types to the termination side. The first group in ANAT shall be the IP address type of the UE.

  (2) Rule O2
  On receiving the 200 SIP Response, the network elements performed DSE shall be responsible to select the IP version in the response. If the answered address type contains the IP version used by the UE, the NAPT-PT operation shall not be performed on the originating side.

  Figure 2 shows the decision tree which precise the operation for the originating networking elements.

4.2.3 Terminating P-CSCF/MGCF/MRFC/AS
The detection point for this operation is on the termination side, where the SIP messages received would also be the SIP INVITE Request messages.

  Besides the forwarding of the message further on the termination side, this entity will also be responsible of selecting the IP version if both IP versions are provided in the SDP of the SIP INVITE Request while the UE is not a dual stack UE.

  The selected IP version would be send on the 200 SIP Response to the originating side.
The termination side would also be responsible to engage the IBCF if IP version incompatibility can not be resolved.

  This operation is outlined by the following four rules:
  (1) Rule T1
  On receiving the SDP INVITE Request without ANAT groups, if the UE version mismatch is detected, the termination side will perform the required NAPT-PT function if the access network is Type A.

  (2) Rule T2
  On receiving SDP INVITE Request without ANAT groups, if the UE version mismatch is detected, the termination side will invoke an IBCF to perform the required NAPT-PT function if such function can not be performed locally.

  This operation would stop the processing of the SIP INVITE Request, forward the SIP INVITE Request to an IBCF with top level route header set to the forwarding entity so that the request will be send back after the NAPT-PT invocation by the IBCF for further processing.

  (3) Rule T3
  On receiving SIP INVITE Request with ANAT group in SDP, if NAPT operation has to be performed at the termination side for IPv4 if selected or the termination UE is dual stack, the SIP INVITE Request to UE shall only contain the value of the first ANAT group. The corresponding 200 SIP Response to the S-CSCF shall respond with the first ANAT group valid and with the second ANAT group invalid.

  NAPT operation has to be performed if there is a difference between the provider’s access and core IPv4 address realm.

  (4) Rule T4
  On receiving SIP INVITE Request with ANAT group in SDP, if Rule T3 is not employed, the 200 SIP Response shall respond in accordance with the user terminal type. In this case, the SIP INVITE Request to UE shall only contain the address type of the UE.

  The termination side shall eliminate the ANAT groups in the SDP for the SIP INVITE Request to be forwarded in accordance to the selected IP address type.

  Figure 3 illustrates the decision tree for the termination side.

  On receiving 200 SIP Response from the UE, the termination phase of NAPT-PT or NAPT can be performed. The decision tree for termination side on receiving 200 SIP Response is not shown, which attempts to finish any pending NAPT-PT or NAPT operation if T1 or T3 in Figure 3 is performed when forwarding the SIP INVITE Request to the UE.

4.2.4 IBCF Processing Algorithm
The IBCF processing is outlined by the following six rules, and Figure 4 shows the decision making in the IBCF.

  (1) Rule I1
  IBCF shall invoke the NAPT-PT and ALG functions on receiving SIP INVITE Request from inside the network with the next hop also inside the same network.

  (2) Rule I2
  IBCF shall invoke the NAPT-PT and ALG functions on receiving SIP INVITE Request from inside the network which is deemed to go outside the provider’s network with addressing type mismatch un-resolvable by the previous hops along the media path.

  If the SDP in the SIP INVITE Request with ANAT groups, Rule I2 will not apply because the originator of the ANAT group can resolve the address type mismatch.

  (3) Rule I3
  On receiving SIP INVITE Request without ANAT group from outside the network, the IBCF shall emulate a dual stack originating UE by inserting the ANAT groups. The first ANAT group shall have the same IP version as that of SDP in the SIP INVITE Request.

  (4) Rule I4
  On receiving 200 SIP Response from inside the network, the IBCF shall select the IP version if a local NAPT-PT operation can be avoided, if the IBCF has performed ANAT group insertion (Per Rule I3).

  The IBCF has to make a selection if both versions of the IP address are valid in the 200 SIP Response, which also implies that the UE is a dual stack UE. A 200 SIP Response with a single valid IP version will be normally received.

  (5) Rule I5
  On receiving SDP INVITE Request with ANAT groups from inside the network, if NAPT operation has to be performed at the border point, the 200 SIP Response shall respond with the first ANAT group valid and with the second ANAT group invalid.

  The border point (IBCF) shall eliminate the ANAT groups in the SDP for the SIP INVITE Request to be forwarded in accordance to the selected IP address type.

  (6) Rule I6
  On receiving SDP INVITE Request with ANAT group from inside the network, if Rule I5 is not employed, the 200 SIP Response shall respond in accordance with the peering network’s IP address type.

  The border point (IBCF) shall eliminate the ANAT groups in the SDP for the SIP INVITE Request to be forwarded in accordance to the selected IP address type.

5 Conclusion
In this paper, a mechanism is derived to provide IPv4-v6 interworking with minimum NAPT-PT operations in the IMS environment. By utilizing standard existing protocols in a systematic fashion, it is possible to operate the network with minimum IPv4-v6 conversion under all the scenarios.

References
[1] 3GPP TS 23.002 V5. 3rd Generation Partnership Project: Technical Specification Group Services and Systems Aspects: Network Architecture Network Architecture: Release 5 [S]. 2003.
[2] ITU-T Y.2012 ERTA 1. Functional Requirements and Architecture of the NGN: Release 1 [S]. 2006.
[3] ETSI ES 282 001. Telecommunication and Internet Converged Services and Protocols for Advanced Networking (TISPAN): NGN Functional Architecture: Release 1 [S]. 2005.
[4] 3GPP TR 23.981 V5.0.0. 3rd Generation Partnership Project: Technical Specification Group Services and System Aspects: Interworking Aspects and Migration Scenarios for IPv4 Based IMS Implementation [S]. 2004.
[5] ITU-T Y.2111. Resource and Admission Control Functions in Next Generation Networks [S]. 2006.

[Abstract] The IP Multimedia Subsystem (IMS) framework was envisioned to be operating on an IPv6 network. However, when the fixed network started to use IMS framework in the Next Generation Network (NGN) architecture, the issue of IPv4 and IPv6 interworking becomes more pronounced due to the widespread usage of the IPv4 network. The overall objective of the solution proposed in this article is to minimize the invocation of Network Address and Port Translation Protocol Translation (NAPT-PT) or Network Address and Port Translation (NAPT) inside the provider’s network. The solution, outlined by the processing rules contained in this article, will limit the NAPT-PT operation at most once inside the provider’s network under all the situations for the media path. This solution will also introduce the minimum required NAPT operations.