[tcmtf] TCM-TF and mobility

"Jose Saldana" <jsaldana@unizar.es> Thu, 04 July 2013 15:49 UTC

Return-Path: <jsaldana@unizar.es>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB98D21F9377 for <tcmtf@ietfa.amsl.com>; Thu, 4 Jul 2013 08:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.363
X-Spam-Level:
X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpvc7T+KaF6g for <tcmtf@ietfa.amsl.com>; Thu, 4 Jul 2013 08:49:36 -0700 (PDT)
Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 40F7821F92E3 for <tcmtf@ietf.org>; Thu, 4 Jul 2013 08:49:28 -0700 (PDT)
Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r64FnMO1009429; Thu, 4 Jul 2013 17:49:22 +0200
From: "Jose Saldana" <jsaldana@unizar.es>
To: <tcmtf@ietf.org>
Date: Thu, 4 Jul 2013 17:49:27 +0200
Organization: Universidad de Zaragoza
Message-ID: <001c01ce78ce$10ba6450$322f2cf0$@unizar.es>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01CE78DE.D443F7A0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac54yD46kc6esDuLRW2yf9vSBPgA9g==
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc: =?iso-8859-1?Q?Jos=E9_Ruiz_Mas?= <jruiz@unizar.es>
Subject: [tcmtf] TCM-TF and mobility
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: jsaldana@unizar.es
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2013 15:49:41 -0000

Hi all.

 

We are discussing a lot about security and TCM-TF. Why not talking a bit
about TCM-TF and mobility?

 

A) First question: How can user mobility and TCM-TF affect each other?

 

1- Residential scenario: I am a network operator, and I am TCM-optimizing a
number of real-time (VoIP, online games) flows which are present in my
access network. What happens if one of the users moves to another location?
Is there any difference between the case in which the traffic is
TCM-optimized and the non-TCM case?

 

In a first approach, I don’t think so. TCM is applied in a network segment.
The end hosts may not even notice that TCM is being used. It would be seen
as an additional network delay and jitter. Thus, if the user moves and a
flow disappears, nothing happens to the rest of the flows. And regarding the
flow of the mobile user, it will be managed by the mobility protocol in the
same way.

 

 

2-Corporate environment: I am using two network appliances in order to
create a VPN between two offices of my company. There is a TCM session
between the two appliances, optimizing a number of VoIP calls. If a user
gets out of the office and his/her VoIP call moves to a 3G data connection,
what happens? Is there any difference with respect to the non-TCM case?

 

I think the answer is the same as in 1.

 

 

3- Machine to machine scenario (sensors, industrial control): Does mobility
exist here? Any ideas?

 

 

B) Second question: Can any mobility protocol take advantage of TCM-TF?

 

Just an idea (suggested by Jose Ruiz) regarding *PMIPv6* (RFC5213,
<http://tools.ietf.org/html/rfc5213> http://tools.ietf.org/html/rfc5213):

 

This network-based mobility protocol creates a tunnel between the LMA
(similar to the HA in MIPv6) and the MAG (typically runs on the access
router).

 

This *tunnel is shared by all the flows* between the LMA and the MAG: 

“the bidirectional tunnel between the LMA and MAG is typically a shared
tunnel, and can be employed for routing traffic streams for different MNs
attached to the same MAG. It extends the 1:1 relation between a tunnel and
an MN’s binding cache entry to a 1:m relation, reflecting the shared nature
of the tunnel” [1]. The tunnel between LMA and MAG can be based on GRE or
IP-in-IP.

 

So we have a tunnel shared by a number of flows. Why not optimizing that
traffic? Instead of a tunnel including lots of small packets, can we
multiplex them and compress headers? Are these bandwidth and pps reductions
interesting?

 

 

Thanks,

 

Jose 

 

[1]  Ki-Sik Kong; Wonjun Lee; Youn-Hee Han; Myung-Ki Shin; HeungRyeol You,
"Mobility management for all-IP mobile networks: mobile IPv6 vs. proxy
mobile IPv6," Wireless Communications, IEEE , vol.15, no.2, pp.36,45, April
2008

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4492976&isnumber=44
92967> &arnumber=4492976&isnumber=4492967

 <http://voiplab.niu.edu.tw/ppt/ipv6/R9843011.pdf>
http://voiplab.niu.edu.tw/ppt/ipv6/R9843011.pdf

 

More info:

 <http://en.wikipedia.org/wiki/Proxy_Mobile_IPv6>
http://en.wikipedia.org/wiki/Proxy_Mobile_IPv6

http://www.cisco.com/en/US/docs/ios-xml/ios/mob_pmipv6/configuration/xe-3s/d
eployment/Proxy_Mobile_IPv6_Network-Based_Mobility.html