[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-v6ops-3gpp-analysis-09.txt / IESG comments on IMS Scenario 1
(co-chair hat on)
There were no replies to this query for preferences how to solve this,
so let's consider the following, slightly modified, text proposed by
Allison.
If you have objections/enhancements to this, please comment on Monday
5th April at the latest so that we could move on with this. Thanks!
(Based on this proposal, I'm confident that addressing Jon's issues
with SDP editing could be settled easily.)
======
4.1 UE Connecting to a Node in an IPv4 Network through IMS
This scenario occurs when an IMS UE (IPv6) connects to a node in
the IPv4 Internet through the IMS, or vice versa. This happens when
the other node is a part of a different system than 3GPP, e.g. a
fixed PC, with only IPv4 capabilities.
The first priority is to upgrade the legacy IPv4 nodes to dual-
stack, eliminating this particular problem in that specific
deployment.
Still, it is difficult to estimate how many non-upgradeable legacy
IPv4 nodes need to communicate with the IMS UEs. It is assumed that
the solution described here is used for limited cases, in which
communications with a small number of legacy IPv4 SIP equipment are
needed.
[these first three paragraphs were unmodified]
As the IMS is exclusively IPv6 [3GPP 23.221], for many of the
applications in the IMS, some kind of translators may need to
be used in the communication between the IPv6 IMS and the
legacy IPv4 hosts in cases where these legacy IPv4 hosts cannot
be upgraded to IPv6.
This section gives a brief analysis of the IMS interworking
issues, and presents a high level view of SIP within the IMS.
The authors recommend that the IETF specify a detailed solution
of the general SIP/SDP/media IPv4/IPv6 transition problem as
a task within the SIP WGs as soon as possible.
As control (or signaling) and user (or data) traffic are separated
in SIP calls, and thus, the IMS, the transition of IMS traffic
from IPv6 to IPv4 must be handled at two levels:
1)Session Initiation Protocol (SIP) [RFC3261], and
Session Description Protocol (SDP) [RFC2327] [RFC3266]
(Mm-interface)
2)the user data traffic (Mb-interface)
SIP carries an SDP body containing the addressing and other
parameters for establishing the user data traffic (the media).
Figure 1 shows a signaling edge for SIP and SDP, a dual stack SIP
proxy at the border between the 3GPP IPv6-only IMS network and the
IPv4 systems.
In a possible approach to communicating, this edge could contain a SIP
ALG, which would change the IP addresses transported in the SIP
messages and the SDP payload of those messages to the appropriate
version. This approach would have the drawback (like other SDP
rewriting solutions) of impacting authentication mechanisms that
may be needed for other purposes. Moreover, this approach would
not take advantage of SIP's ability to use proxy routing, nor of SDP's
ability to carry multiple alternative addresses. These intrinsic
features of SIP and SDP require a more detailed analysis, but they
would yield benefits. The SIP ALG approach requires NAT-PT
(with the issues described in appendix A), because the IMS-side
IPv6 addresses must be assigned IPv4 addresses for reachability
from the legacy IPv4 side shown in Figure 1. The approach based
on intrinsic SIP proxy routing would not require assignment of
temporary IPv4 addresses to the IPv6 IMS endpoints; instead they
would be reached via an IPv4-side address of a SIP proxy
acting for them. This SIP proxy would be doing normal SIP
processing; it would be as scalable as any SIP proxy.
On the user data transport level, the analysis raises other issues:
the IMS data is time-sensitive, so NAT-PT IPv6-IPv4 protocol
translation (with the scalability concerns raised in Appendix A)
may look simplest, but needs a skeptical look. Alternatives
include routing to a transcoder, whose task is to terminate an
IPv6 stream and start an IPv4 stream. Again, this requires
a more detailed analysis.
For each of the protocols, there has to be interoperability
for DNS queries; see section 2.4 for details.
+-------------------------------+ +------------+
| +------+ | | +--------+ |
| |S-CSCF|---| |SIP edge| |\
| | +------+ | | +--------+ | \ --------
+-|+ | / | | | | | |
| | | +------+ +------+ | | + | -| |-
| |-|-|P-CSCF|--------|I-CSCF| | | | | | () |
| | +------+ +------+ | |+----------+| / ------
| |-----------------------------------||[ALG?] ||/
+--+ | IPv6 | |+----------+| IPv4
UE | | |Interworking|
| IP Multimedia CN Subsystem | |Unit |
+-------------------------------+ +------------+
Figure 1: UE using IMS to contact a legacy phone
Figure 1 shows a generic SIP signaling edge - a ALG-like replacement
of the IPv6 addresses with IPv4 addresses using limited subsets of
NAT-PT [RFC2766] is a possible approach, but exploiting SIP's proxy
routing to allow the dual homed SIP edge to make the address change
without a translator is a promising alternative without the scaling
problems of NAT-PT (appendix A).
==============