Network Working Group D. Liu Internet-Draft China Mobile Intended status: Informational March 1, 2010 Expires: September 2, 2010 Distributed mobility management Problem Statement draft-liu-distributed-mobility-00 Abstract Current mobility solutions normally introduce an anchor point in the network, eg HA in MIPv6, LMA in PMIPv6, GGSN in 3GPP. The anchor point is used to maintain the mapping between the stable IP address (eg Home address in MIPv6) and the current routable IP address (eg CoA in MIPv6). In the hierarchical architecture, since the anchor point normally locates in the top of the hierarchical architecture, there will no scalability issue. But in the more flat architecture, the anchor point will be much lower compared with hierarchical architecture; this will introduce some issues if traditionally mobility protocol is used. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the Liu Expires September 2, 2010 [Page 1] Internet-Draft SIP ALG March 2010 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Overview of mobility problems in flat architecture . . . . . . 5 4. 4. Considerations of distributed mobility solutions . . . . . 7 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Liu Expires September 2, 2010 [Page 2] Internet-Draft SIP ALG March 2010 1. Introduction As the mobile network is evolving towards the more flat architecture, traditional mobility protocol is not suitable for this architecture. For example, in the LIPA/SIPTO architecture which is discussed in 3GPP, the gateway function is located near the base station. In this architecture, if the anchor point locates in the gateway, the frequently handover between base station may cause more signaling overhead compared with hierarchical architecture. The triangle routing issue will become more severe in flat architecture, since there will be many UE under one gateway roaming to other gateways. In this condition, the visiting gateway will need to establish the mobility tunnel back the original access gateway of the UE. Due to the triangle routing issue, the traffic could not break out locally. Liu Expires September 2, 2010 [Page 3] Internet-Draft SIP ALG March 2010 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Liu Expires September 2, 2010 [Page 4] Internet-Draft SIP ALG March 2010 3. Overview of mobility problems in flat architecture +----------------------------------------+ | Mobility tunnel | +-------+ +-------+ +-------+ +-------+ |L-GW | |L-GW | |L-GW | |L-GW | |MAG/LMA| |MAG/LMA| |MAG/LMA| |MAG/LMA| +-------+ +-------+ +-------+ +-------+ \ \ +-----+ | UE | +-----+ Figure 1 Flat network architecture 1) Signaling overhead As figure 1 illustrated, in the flat network architecture, the mobility anchor point may locates near the base station if traditional mobility protocol is used. The UE's handover between base stations may cause frequently handover between anchor points. 2) Triangle routing The triangle routing problem will become more severe in the flat architecture if traditional mobility protocol is used. The mobility tunnel needs to be connection back to the anchor point where the UE is first access to the network and get the IP address allocation. For example, if a user opens his mobile phone to see a video streaming program at office and then take a subway to get home. When the user gets back to home, the mobility tunnel still need to connect back to the anchor point where locates near his office. This will lead all the traffic goes back to the gateway near his office to access the Internet instead of locally break out from the base station which near his home. Local break out Liu Expires September 2, 2010 [Page 5] Internet-Draft SIP ALG March 2010 As the speed of wireless Internet access is increasing rapidly, if all the Internet traffic need to go through the core network, it will give much pressure to the mobile operator's core network and may decline the user experience due to the latency cause by the long route to the destination. It is preferred that the Internet access traffic could break out locally, it means that the Internet traffic beak out from a gateway which locates near the base station. To ensure the local break, the gateway should have the IP address allocation function. It is also preferred that the network should provide mobility in the local break out scenario, so the gateway should be the anchor point of mobility. It is preferred that when UE roams to other base station the traffic could break out locally and also maintain the session continuity. That will be a challenge if use traditional mobility protocols. Liu Expires September 2, 2010 [Page 6] Internet-Draft SIP ALG March 2010 4. 4. Considerations of distributed mobility solutions Based on the above analysis, there may be a need for developing new mobility solutions for the flat architecture, the solution may be called distributed mobility solutions since the mobility anchor function is distributed compared with the centralized mobility anchor point of traditional mobility protocol. The distributed mobility solutions should make less change to the existing network entity. It is preferred that there is no change requirement to the UE and transparent to the application layer. The details of distributed mobility solution requirements will be further identified. In the above figure, Phone A with UID:3100 initiates a session with B. NAT device's SIP ALG works as a SIP proxy, it behaves like SIP entity between the SIP servers in the private network and in the public network. The SIP ALG function in the NAT device translates the corresponding section of SIP message and creates an SIP-ALG mapping table. The SIP-ALG mapping table is used during the sip session and will be deleted when the session is terminated. The SIP-ALG mapping table uses Call-ID as index. The call-ID could remain unchanged or changed during the translation. The SIP-ALG mapping table contains the following section: Call-ID_IN Call_-D_OUT Vias.IN Vias.OUT From.IN From.OUT To.IN To.OUT Contact.IN Contact.OUT SDP.oField.IP_IN Liu Expires September 2, 2010 [Page 7] Internet-Draft SIP ALG March 2010 SDP.oField.IP.OUT SDP.cField.IP_IN SDP.cField.IP_OUT SDP.mField.port.IN SDP.mField.port.OUT Time_count The translation algorithm is as follows: When the SIP ALG function identifies the SIP messages that need to be translated, it performs the following function: Translate the IP address/domain name in the SIP request message into the SIP server's IP address that locates in the public network. Record the Via section to the SIP-ALG mapping table's Vias_IN entry and translates the proxy's private IP address and port number to its corresponding public IP address and port number. Record From section to the SIP-ALG mapping table's From_IN entry and translates the UE's private IP address and port number to its corresponding public IP address and port number. Record To section to the SIP-ALG mapping table's To_IN entry. Record Call-ID to the SIP-ALG mapping table's Call-ID_IN section and generates a new Call-ID and create a Call-ID_OUT entry in the mapping table. Record the Contact section to the SIP-ALG mapping table's Contact_IN entry and translates the UE's private IP address and port number to its corresponding public IP address and port number. Translates SDP section's o and c section's IP address into corresponding public IP address. m section's port number to public port number. Then creates SDP_oField_IP_IN, SDP_cField_IP_IN, SDP_mField_port_IN entries. NAT devices forwards the translated SIP message to the next SIP server. Clear the timeout_Count section of the SIP-ALG mapping table. Liu Expires September 2, 2010 [Page 8] Internet-Draft SIP ALG March 2010 When translates the incoming SIP message that comes from the public network. SIP-ALG function in the NAT device should first query the SIP-ALG mapping table using Call-ID as index to see if there is an mapping entry exists. If there is a mapping entry exists, then translates the Via/Contact section of the SIP message and the m section of the SDP message using the SIP-ALG mapping table. Then forward the translated SIP message to the corresponding SIP entity. As an example, the NAT device should create the following mapping information: Call_ID_IN 1234@192.168.139.100 Call_ID_OUT 5678@210.72.128.100 Vias_IN SIP/2.0/UDP 192.168.0.10:5060 SIP/2.0/UDP 192.168.139.100: 5060 VIas_OUT 192.168.139.100:5060 From_IN 3100@192.168.139.100:5060 From_OUT 0247654321@210.72.128.100:5061 To_IN 02412345678@192.168.0.10 To_OUT 02412345678@210.72.0.100:5060 Contact_IN 192.168.139.100:5060 Contact_OUT 02412345678@210.72.128.200 5060 SDP_oFiled_IP_IN 192.168.139.100 SDP_oFiled_IP_OUT 210.72.128.200 SDP_mField_port_IN: 3456 SDP_mFild_prot_OUT 7890 Timeout_Count 0 Liu Expires September 2, 2010 [Page 9] Internet-Draft SIP ALG March 2010 5. Deployment Considerations SIP ALG always located in the IP address translator. Most SIP networks deploy SBCs to assist with NAT traversal, SIP ALG functionality need to be implemented inside SBC. If there is no SBC present during SIP communication, NAT is the right position to implement ALG in the network side. If the host based translation is provided, ALG need to be implemented in the host side (SIP endpoint) if there is no other advanced NAT traversal solution support such as ICE. Liu Expires September 2, 2010 [Page 10] Internet-Draft SIP ALG March 2010 6. Security Considerations TBD Liu Expires September 2, 2010 [Page 11] Internet-Draft SIP ALG March 2010 7. IANA Considerations None Liu Expires September 2, 2010 [Page 12] Internet-Draft SIP ALG March 2010 8. Acknowledgments TBD Liu Expires September 2, 2010 [Page 13] Internet-Draft SIP ALG March 2010 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Liu Expires September 2, 2010 [Page 14] Internet-Draft SIP ALG March 2010 Author's Address Dapeng Liu China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: liudapeng@chinamobile.com Liu Expires September 2, 2010 [Page 15]