Internet DRAFT - draft-cheng-mobility-issues
draft-cheng-mobility-issues
NSIS Working Group
Internet Draft H. Cheng
K.H. Ling
Document: draft-cheng-mobility-issues-00.txt Panasonic Singapore Labs
Expires: August 2004 February 2004
Mobility related issues for the QoS NSLP
draft-cheng-mobility-issues-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
The draft listed out some of the issues related to IP mobility that
may have impact on the design and implementation of the NSIS
protocols. These issues, namely, the multiple flow support and the
ping-pong type of movement, needs to be considered in the context of
the QoS NSLP protocol design, so that the NSIS framework would not
break when they present.
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 RFC-2119 [2].
Table of Contents
Cheng Expires - August 2004 [Page 1]
Internet-Draft Mobility related Issues for QoS NSLP February 2004
1. Introduction...................................................2
2. Terminology....................................................3
3. Multiple flow support for QoS NSLP.............................3
3.1 Management of the state on old data path...................4
3.2 The solution for the multiple flow support.................4
4. Fast re-establishment of signaling path (with Ping Pong effect)5
4.1 Problem description........................................5
4.2 Solutions for the Ping-pong type of movement...............7
5. Security Considerations........................................7
6. Conclusions....................................................7
References........................................................7
Acknowledgments...................................................8
Author's Addresses................................................8
Intellectual Property.............................................9
Full Copyright Statement..........................................9
1. Introduction
In the defined NSIS framework [3], a two-layer architecture is used,
wherein the NSLP layer is the actual signaling application. The QoS
NSLP draft [4] specifies an instance of the NSLP signaling
application for the QoS provisioning and control. In the QoS NSLP
draft, some of the operation for the QoS signaling has been defined,
but the impacts of mobility are not considered in detail.
When the NSIS signaling involves the mobile nodes, there are
different requirements to be considered. Although the NSIS framework
depends on the existing mobility protocols to shield it from the
detail mobility management, some mobility related problems still
present to the NSLP layer in a different form.
This draft discussed in detail two of such problems, the multiple-
flow support, and the ping-pong type of movement, and their potential
impacts on the QoS NSLP. The QoS NSLP deals mainly with the state
management for the delivery of data flow. It is in charge of
providing necessary forwarding resources for the flow [4]. Therefore,
the two problems mentioned above have to be solved at the NSLP layer,
since they are related to resources management and require the state
information.
The discussion of the issues would benefit the design of the QoS NSLP
protocol. If these issues are not solved, they could break the normal
operation of the QoS signaling. For example, the QoS NSLP would not
be able to use with multi-homing devices if it could not support
simultaneous multiple flows. Similarly, the QoS NSLP would have a bad
performance in face of ping-pong type of movement of the mobile
terminal if no proper solution is incorporated into the QoS NSLP.
Cheng et al. Expires - August 2004 [Page 2]
Internet-Draft Mobility related Issues for QoS NSLP February 2004
2. Terminology
The Terminology defined in [4] applies to this draft. In addition,
the following terms are used:
CRN: Crossover Node
NAR: New Access Router
OAR: Old Access Router
3. Multiple flow support for QoS NSLP
In the NSIS signaling environment, there could be situations that one
session contains multiple flows simultaneously. It could be caused by
one or a combination of the following reasons:
1. One application session may have several sub flows, and they
could go via different data path and owns different QoS
requirements. The different data path for the flows could be due
to load balancing reasons, or performance optimization reasons.
For example, in the Audio-Visual communication, there could be
several flows for different media streaming. One session may have
several sub-sessions, e.g. sub-layers of the MPEG4 content could
be sent over with different flows. Another example is that the
FTP session could be using several streaming channels/ports for
downloading the same file in order to boost the speed.
2. Multiple access interface for one network node (multi-homing).
For example, in the dual/multi mode Mobile Node (MN), there may
be more than one interface involved in the communication, both
WLAN and UMTS. Some service session would be across both of the
interface which could use different IP address. In the 3GPP WLAN
interworking specification [3GPP TR22.934] requires the
interworking terminal to be able to support simultaneous
connections over its WLAN and UMTS interface for scenario 3.
3. When the mobile terminal experiencing a soft handover. During the
handover time, the QoS reservation for the new connection would
need to be set up, before the QoS reservation for the old
connection being torn down. So, there would be multiple flows
belonging to the same session co-exists for the transition time.
In NSIS, the flow-ID is used to represent the flow information. In
most of the mobility discussions, the flow-ID is used to detect the
Cheng et al. Expires - August 2004 [Page 3]
Internet-Draft Mobility related Issues for QoS NSLP February 2004
movement of the mobile terminal and discover of the Crossover Node
(CRN). Therefore, if a signaling message with the same Session ID but
different flow-ID reaches a NSIS node, it would be deemed as a route
change or mobility event. According to the discussion above, this
conclusion is not necessary correct, since it could simply be a
multi-homing device utilizing another interface. Therefore, the QoS
NSLP should be designed to distinguish the actual route change and a
multiple flow case.
3.1 Management of the state on old data path
In most of mobility discussions, it is assumed that when the re-
establishment of the NSIS state along the new path is finished, the
NSIS state along the old path should be removed since it waste of
resources. In certain proposals, the CRN could initiate the teardown
of the old state.
As described above, this kind of assumption may cause problem for the
QoS NSLP operation. In certain cases, the MN may want to keep the
state along the old path even though the state along new path is set
up. For example, a multi-homing MN may want to use multiple
interfaces for the same session simultaneously. Also, if a dual mode
MN is in a make-before-break handover, the reservation on the old
path should be kept until the data traffic is actually switched to
the new path. If the CRN initiated the teardown of the reservation on
the old path immediately, it would affect the service for the MN.
But for most mobility events, the state on the old path is desired to
be removed, e.g. a MN did make a movement, or connection to the old
path was lost. Fail to immediate initiate the removing of the state
on old path would result in resource waste.
Therefore, it is desirable for the network or the CRN to obtain
information or intension of the MN before initiate the teardown of
the state of old path.
3.2 The solution for the multiple flow support
Solution to the above problems would not be a simple QoS NSLP issue.
It requires coordination between the different layers of the NSIS
framework, and possibly the mobility protocols. The general principle
for solving the problem is to involve the MN in the state management
decision, because it is the node that has the best information about
the application session. This would also require the QoS NSLP at the
MN to maintain interaction with its lower layers, e.g. obtaining the
link status information.
Cheng et al. Expires - August 2004 [Page 4]
Internet-Draft Mobility related Issues for QoS NSLP February 2004
4. Fast re-establishment of signaling path (with Ping Pong effect)
4.1 Problem description
When a MN moves from one access network to another, a handover
require the MN to register with the new access network and to
establish a new path from the New Access Router (NAR) to the
Correspondent Node (CN). Usually, a MN will try to perform a make-
before-break handover to achieve minimum service disruption.
+--+ +---+ new flow
new | |<<<<<<<<<<| |<<<<<<<<<<<<<^
address |MN| |NAR| ^
| |>>>>>>>>>>| |>>>>>>>>>>>v ^
+--+ +---+ v ^
^| +---+ +--+
|| | |<<<<<<<<<<| |
||ping-pong |COR| |CN|
||type of movement | |>>>>>>>>>>| |
|| +---+ +--+
|v+--+ +---+ v ^ shared
original | |<<<<<<<<<<| |<<<<<<<<<<<v ^ segment
address |MN| |OAR| ^
| |>>>>>>>>>>| |>>>>>>>>>>>>>^
+--+ +---+ original
flow
Figure A:
Figure A shows the interactions between the MN and the CN. During a
handover, the MN tries to establish the new path either from the NAR
or the OAR. A mobile handover requires several cumbersome procedures
such as CT/CARD, end-to-end path setup, CRN discovery, etc. A
handover requires end-to-end signaling and a fair amount of control
load overhead. If the time took for setting up the new state is
longer than actual handover process, disruption in services QoS is
unavoidable.
In the case of a ping-pong type of movement, the MN may moves from
one access network to another, and returns to the previous access
network in a very short duration. This would most likely happen in a
wireless network, where the location change of the MN would cause the
data route adjustment.
Cheng et al. Expires - August 2004 [Page 5]
Internet-Draft Mobility related Issues for QoS NSLP February 2004
-----------------------------
/ \ +----+
| NETWORK |---| CN |
\ / +----+
-----------------------------
| |
+-----+ +-----+
| AR1 | | AR2 |
+-----+ +-----+
|subnet 1 |subnet 2
+-----+ +-----+
| AP1 | | AP2 |
+-----+ +-----+
^ ^
\ /
--------- -------
\ /
v v
+-----+
| MN |
+-----+
....
....
Figure B:
Figure B shows the movement of a MN between two access networks. The
problem can be very prominent in a wireless environment when the MN
moves along the boundary of two access networks. The movement of the
MN may cause frequent switches between the access networks and thus
resulting in multiple handovers in a very short duration.
Performance of the network can be severely hampered.
Typically during a handover, the states of the old path are
immediately released after the installation of states in the new
path. This is usually for preventing the waste of resources. But
this is not desirable when a ping-pong type of movement is involved.
If the state is removed before the MN moves back to the old path, the
MN needs to re-establish the state along the path again, which would
be time consuming.
It has been proposed in some draft that the old path can be retained
for the remaining refresh period. Typically, the changed path is
located inside an access network, where resources are relatively
expensive, thus it might be inefficient to wait for typical soft-
state timeouts. In the event that the mobile node does not move back
to the old path within the refresh period, resources are wasted. For
Cheng et al. Expires - August 2004 [Page 6]
Internet-Draft Mobility related Issues for QoS NSLP February 2004
example, the normal refresh period is 30 sec, and the MNÆs ping-pong
cycle is 40 sec, the solution would not work.
This raises the issue of how should this duration be optimized such
that it will strike a balance between resource wastage and fast path
re-establishment. The problem for this solution is the randomness of
the MN movement.
4.2 Solutions for the Ping-pong type of movement
As mentioned above, the solution to this problem would always be a
tradeoff between the resource wastage and re-establishment
performance. A combination of different methods could be used to
solve the problem. The general principle is to reuse the old state
while reduce the resources wastage. Similar to the multiple flow
problem, MN should also be involved in the management decision in
solving the problem.
5. Security Considerations
Security should be considered in the QoS NSLP as an integrated part.
Usually mobility events would complicate the security relationships.
For example, the teardown of the old state, reuse of old state in
ping-pong type of MN movement all require extra security relationship
to be established between signaling peers. Otherwise, any solution
would be subject to attacks from the network.
Future version of the draft would discuss the relevant security
requirements for the solutions in detail.
6. Conclusions
This draft discussed two issues, multiple flow support and Ping-pong
type of movement, for the QoS NSLP when Mobile Nodes are involved in
the signaling. These issues present serious problems for the QoS
NSLP. If not properly address, these problems would hamper the
correct operation of the NSIS framework.
In the draft, some principles for developing the solutions for these
problems are discussed. More details on the possible solutions is
expected to be available in further version of the draft.
References
1. "The Internet Standards Process -- Revision 3", BCP 9, October
1996, <RFC 2026>
Cheng et al. Expires - August 2004 [Page 7]
Internet-Draft Mobility related Issues for QoS NSLP February 2004
2. "Key words for use in RFCs to Indicate Requirement Levels", BCP
14, March 1997, <RFC 2119>
3. R. Hancock, et. al. ôNext Steps in Signaling: Frameworkö draft-
ietf-nsis-fw-05.txt, October 2003
4. Sven Van den Bosch, "NSLP for Quality-of-Service Signalingö,
draft-ietf-nsis-qos-nslp-01.txt, October 2003.
Acknowledgments
This section will contain acknowledgements.
Author's Addresses
Hong Cheng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #04-3530
Tai Seng Industrial Estate
Singapore 534415
Phone: (+65) 6554 5477
Email: hcheng@psl.com.sg
Kim Hui Ling
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #04-3530
Tai Seng Industrial Estate
Singapore 534415
Phone: (+65) 6554 5418
Email: khling@psl.com.sg
Cheng et al. Expires - August 2004 [Page 8]
Internet-Draft Mobility related Issues for QoS NSLP February 2004
Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
Cheng et al. Expires - August 2004 [Page 9]
Internet-Draft Mobility related Issues for QoS NSLP February 2004
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Cheng et al. Expires - August 2004 [Page 10]
