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]