RE: draft-ietf-v6ops-3gpp-analysis-09.txt / IESG comments on IMS Scenario 1

[<juha.wiljakka@nokia.com>]

 Hi, Allison and Pekka!

Firstly, thanks for making text suggestions for IMS scenario 1! I think we need some more discussion before we can close this issue and move forward with this document. I understand the concerns with rewriting SDP, but are there viable options for that in this case? Isn't there some contradiction, if there also is a recommendation that NAT-PT should not be used, and we should use a specialized translator instead of it?

However, it is clear that we cannot specify (and we will not specify) an exact solution in this document, and it is fine for me just to show the higher level details of a possible solution. Specification work is clearly needed in SIP wgs, no doubt about it.

Some comments (JW):

-----Original Message-----
From: ext Pekka Savola [mailto:pekkas@netcore.fi]
Sent: 30 April, 2004 15:21

(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

JW: We write in draft -09 "translators have to be used".  Could this be "some kind of translators are needed...", or "translators are most probably needed...", i.e. somewhat stronger statement

    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.

JW: => "The authors recommend that a detailed solution for the general SIP/SDP/media IPv4/IPv6 transition problem will be specified as soon as possible as a task within the SIP WGs in the IETF." ?
  
    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

JW: I suppose you are now referring to real time IMS services? I think NAT-PT does not make the situation worse compared to IPv4 NAT...

    translation (with the scalability concerns raised in Appendix A)
    may look simplest, but needs a skeptical look.  Alternatives 

JW: s/skeptical/sceptical


    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).
==============

JW: I would like also to hear what the others in the wg think about this text?

Cheers,
	 -Juha-