One document matched: draft-shen-nsis-mobility-fw-00.txt
Internet Engineering Task Force Charles Qi Shen
Internet Draft ICR
draft-shen-nsis-mobility-fw-00.txt
July 12, 2002
Expires: January 2003
Several Framework Issues Regarding NSIS and Mobility
<draft-shen-nsis-mobility-fw-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.
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".
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
1 Abstract
This memo discusses several framework issues related to Next Step In
Signaling (NSIS) and mobility interaction. The first issue is related
to handoff impact on NSIS operation. We present several general
requirements for NSIS and mobility, followed by evaluation of how
specific approaches using Mobile IP or other mechanisms might fit
into the picture. Other issues covered include NSIS and mobility
signaling layering and soft-state management.
2 Introduction
The IETF Next Step In Signaling (NSIS) WG is currently looking at
requirements and framework issues for a general resource signaling
protocol. It is expected that the interaction between such a protocol
(or protocol suite) and general mobility mechanisms is an important
part of the overall framework.
This memo presents our view on several framework issues concerning
NSIS and Mobility interaction. The discussions here are largely
Charles Qi Shen [Page 1]
Internet Draft NSIS Mobility Framework Issues July 12, 2002
driven by our experience in designing and prototyping an RSVP-Mobile
IPv6 interoperation framework [1,2] as well as by some good coverage
on the same topic in existing NSIS framework proposals such as [3].
The first issue is related to impact of handoff on NSIS operation.
Since NSIS is expected to be interacting with general mobility
mechanisms, we take the approach of analyzing some general
requirements concerning NSIS and general mobility problem first. Then
we use Mobile IPv6 and other mobility mechanisms as examples, to show
how they may fit into these requirements when applied. The important
point is to show how distinct features of specific mobility
mechanisms make them distinct in their ability to meet the given
requirements. After the handoff issue, we also talked about issues
such as Signaling Layering and Soft-State management.
Our basic assumption in this memo is in-band signaling with a one-
sender and one-receiver scenario.
3 Issues about Handoff Impact on NSIS Protocol Operation
3.1 The Need for a Separate View on Data and Control Plane Identifiers
In exsiting signaling protocol such as RSVP, resource reservation is
usually done for a flow from a Sender to a Receiver. Typically a flow
is identified by the IP 5-tuple (Src, Dst address, protocol id and
port number) or in IPv6 by the IP 3-tuple (Src, Dst address and Flow
Label). This flow identifier basically serves two purposes in two
planes:
o Data Plane: it is used by packet classification mechanism for
filtering the data packets that are entitled to the reserved
resources.
o Control Plane: it is used by the state management entity in
locating the specific state maintained for the specific flow.
The flow identifier can actually be seen as a reservation
identifier in this sense.
Although it is fine to have a single identifier used in both Data and
Control plane as in the traditional case, problems arises due to
mobility may require two different identifiers to be used in
respective planes, although they should still keep associated with
each other.
3.2 Handoff Problem Statement and Basic Requirements
Handoff is the major cause for the complexity in NSIS and mobility
interaction. Handoff basically results in the original flow path
Charles Qi Shen [Page 2]
Internet Draft NSIS Mobility Framework Issues July 12, 2002
between a sender and a receiver being split into three portions, all
of which intersects at a cross-over router: The unchanged (common to
old and new) portion, the newly added portion and the obsoleted
portion. To simplify, we will denote the three as: Common path, new
path, obsoleted path respectively.
The ideal requirements for NSIS and mobility interaction, looking
from two different planes respectively, could be:
o Control Plane: During handoff signaling phase, routers within
the common path should be kept transparent to mobility;
routers within the new path should establish corresponding
states as soon as possible, and routers within the old path
should delete corresponding states as soon as possible.
o Data Plane: The Data Plane should be transparent to mobility
if possible.
Fulfillment of the Control Plane requirement ensures minimized impact
caused by handoff on state management. Otherwise, it is likely that
handoff signaling will have to be propagated along the common path to
update state information in routers there and additional mechanism is
also required to ensure no duplication of states/reservations is
created for the same flow due to handoff.
Fulfillment of the Data Plane requirement ensures a seamless service
for data packets belong to the flow. Otherwise it is likely that
service disruption will be perceived due to handoff. Note that unable
to fulfill the Data Plane requirement potentially excludes the
possibility of complete fulfillment of Control Plane requirement, as
will be shown below.
3.3 Evaluation of Existing Framework Proposals using Mobile IP Against
Requirements
Mobile IP is likely to be one of the pre-dominant mechanism used for
IP mobility. With Mobile IP, MN is assigned HA and CoAs. The former
keeps constant while the latter changes during handoff. So whether
and how these addresses are used to form Data Plane/ Control Plane
identifier will have important impact on how the proposal will meet
the above stated requirements.
3.3.1 Approach I
Approach I: In [1], it is proposed that MNs' HAs instead of CoAs are
used in the 3-tuple Data Plane flow identifier for packet
classification. Furthermore HAs are also used to identify
corresponding reservation states, thus it is used as Control Plane
Charles Qi Shen [Page 3]
Internet Draft NSIS Mobility Framework Issues July 12, 2002
reservation identifier as well.
It can be seen that in this approach, Data Plane identifier and
Control Plane identifier share the same information, which is HA.
Both of them are kept constant as well. Thus both Data Plane and
Control Plane requirements are met.
However, it is understood that an additional issue with this approach
is: the placement of MNs' HA in IP header as specified in current
Mobile IPv6 makes it necessary to complicate the packet
classification engine if HAs are used as Data Plane flow identifier.
3.3.2 Approach II
Approach II: The alternative to using MN's HA as Data Plane flow
identifier is naturally the use of MN's CoA, such as in [4].
It can be seen that with this approach, the Data Plane requirement
can not be met because the flow identifier changes during handoff.
The changed flow identifier will have to be propagated along the
common path, in addition to the new path. Thus the first part of
Control Plane requirement, which states routers in common path be
kept transparent to handoff, can not be met as well. The rest part of
the Control Plane requirement however, can be met by using separate
reservation identifiers. Example could be the session identifier as
in [4]. By comparing the previous QoS session identifiers and new QoS
session identifiers in the signaling packet and state information,
the cross-over router could be identified and duplication of
reservation for the same flow may be avoided.
3.3.3 Approach III
Approach III: Based on the above analysis, a third approach is also
possible: to combine the above approach II for Data Plane and
approach I for Control Plane. That is, use CoAs for flow identifier
thus relieves the concern on packet classification, while use HAs to
form a unique identifier in the Control Plane. The use of HAs for
unique identifier in Control planes seems to be natural for a
protocol like Mobile IP. This is also in line with what is mentioned
in [5], flow state establishment methods SHOULD include the Mobile IP
HAs if available, to avoid state duplication on fixed portions of the
path when either end changes its Care-of Address. This approach can
be seen as one step further from [1,2] and is currently under study.
3.3.4 Summary Notes
In summary, the following are the possibilities that can happen when
matching an existing solution with the two requirements:
Charles Qi Shen [Page 4]
Internet Draft NSIS Mobility Framework Issues July 12, 2002
o Both requirements are met, such as approach I. (Although
additional concern with Packet Classification could present.)
o The Data Plane requirement is not met, then the Control Plane
requirement can at most be partially met, such as approach II
and III.
o The Control Plane requirement is not met. It is still possible
to meet the Data Plane requirement although this kind of
approaches seem less attractive. The reason is when Data Plain
requirement can be fulfilled, it is usually not difficult to
meet the Control Plane requirement at the same time.
o Neither of the requirements are met. This is likely when the
resource signaling and mobility mechanism are completely
unaware of each other.
3.4 Evaluation with Other Possible Mobility Mechanisms Against
Requirements
According to the above analysis, how a given mobility mechanism can
fulfill the requirements when interact with NSIS is largely dependent
on the mechanism feature itself. In the case of Mobile IPv6, it seems
difficult to achieve the Data plane requirement without complicating
the packet classification engine. Other mobility mechanisms, or
optimization schemes to Mobile IPv6, however, might make it possible
in certain situations, for example in the case of Local mobility
management [6].
As in local mobility management, when the mobile node is moving
within a Local Coverage Area (LCA), its change of IP address is not
seen by nodes beyond that area. It may be preferable to look at the
flow path in two segments, one from the border of LCA to CN and the
other within LCA. For the first segment, the Data Plane requirement
can be easily fulfilled as long as MN is within the LCA, hence it is
also not difficult to meet the Control Plane requirement for that
part. A both-requirement-met approach can be applied in this
situation.
It should be noted that within LCA or when the MN moves out of LCA,
the situation is quite different since there are IP address changes.
Approaches similar to what has been discussed above for Mobile IPv6
may be applied. This example implies that there might be a
requirement for NSIS to interact with LMM, similar to the requirement
for it to interact with Fast handoff and Context Transfer, if
applicable.
4 Issues on Signaling Layering Between NSIS and Mobility
Charles Qi Shen [Page 5]
Internet Draft NSIS Mobility Framework Issues July 12, 2002
It is expected that NSIS would use a multi-level architecture. In
most of existing NSIS framework proposals (e.g., [7,3]) it is assumed
that there exists a NSIS protocol transport level. This raises a
possible problem of additional signaling layering issue as far as
mobility is concerned. Specifically, NSIS's general protocol
transport should be properly and efficiently layered with the
mobility signaling transport, if such a need for a mixed resource and
mobility signaling is present (similar to what is mentioned in [3] as
tight integration). Some existing work has already lead to the
question of whether resource signaling should be layered on top of
mobility signaling or should it be the other way around. The first
approach is taken by [8,9,10]. And as stated in [3], this is
considered as a special case of NSIS layering, with the mobility
protocol playing the role of the signaling transport. The second
approach is taken by [1] which puts mobility related information into
resource signaling messages transported by resource signaling
protocols' own mechanism.
It in fact seems pre-mature to answer the question of which is better
at this time, when the exact nature of a generic transport layer for
NSIS has not even been clearly defined. However, considering the
general purpose of NSIS and the requirement that NSIS - mobility
should be considered without assuming any specific mobility, it seems
more appropriate at least initially, not to layer resource signaling
messages on any particular mobility mechanism. Rather we suggest
that it may be preferable to define some common interface between
NSIS and (any) mobility mechanisms, probably by putting a mobility
adaptation level(layer) in the overall NSIS framework. Specific
parameters passed into the adaptation layer can be mobility mechanism
dependent if required. Ultimately these signaling could still be
supported by the NSIS signaling transport itself. For this kind of
framework, [2] might serve as one possible starting point.
5 Issue on Soft-State Management in NSIS and Mobility Interaction
When soft-state mechanism is used for the NSIS protocol, how the
refresh is done could have important implications when NSIS and
mobility is concerned. If the NSIS refresh message is issued end to
end and processed and forwarded by each intermediate routers similar
to, e.g the RSVP Path refresh case, this implies: First, in order to
route the refresh message correctly, the sender may have to know the
receiver's new location. Second, intermediate routers also need to
maintain its own copy of the receiver's new loaction before it can
forward the refresh to the next hop, this is required if the
signaling mechanism in the router do not want to rely on IP header of
the received Refresh message to construct the Refresh message that is
sent out to next hop (to maintain a clear interface between the
signaling protocol and IP layer). This means the handoff signaling
Charles Qi Shen [Page 6]
Internet Draft NSIS Mobility Framework Issues July 12, 2002
message will always have to go beyond the cross-over router even
though a unique reservation identifier may be used. This has been
shown in [1,2]. Note that this problem is present for all three
approaches mentioned in the first section of this memo. The problem
might be partially relieved if a direct neighbor to neighbor refresh
mechanism were used.
6 Bibliography
[1] C. Q. Shen, W. Seah, A. Lo, H. Zheng, and M. Greis, "An
Interoperation Framework for Using RSVP in Mobile IPv6 Networks,"
draft-shen-rsvp-mobileipv6-interop-00.txt , July 2001. Work in
Progress.
[2] C. Q. Shen et.al., "Mobility Extensions to RSVP in an RSVP-Mobile
IPv6 Framework," draft-shen-nsis-rsvp-mobileipv6-00.txt , July 2002.
Work in Progress.
[3] R. Hancock et.al., "Next Steps in Signaling: A Framework
Proposal," draft-hancock-nsis-fw-00.txt , June 2002. Work in
Progress.
[4] C. Westphal and H. Chaskar, "QoS Signaling Framework for Mobile
IP," draft-westphal-nsis-qos-mobileip-00.txt , June 2002. Work in
Progress.
[5] J. Rajahalme et. al., "IPv6 Flow Label Specification," draft-
ietf-ipv6-flow-label-02.txt , June 2002. Work in Progress.
[6] C. Williams, "Localized Mobility Management Requirements,"
draft-ietf-mobileip-lmm-requirements-02.txt , June 2002. Work in
Progress.
[7] R. Braden and B. Lindell, "A Two-Level Architecture for Internet
Signaling," draft-braden-2level-signal-arch-00.txt , November 2001.
Work in Progress.
[8] H. Chaskar and R. Koodli, "A Framework for QoS Support in Mobile
IPv6," draft-chaskar-mobileip-qos-01.txt , March 2001. Work in
Progress.
[9] X. Fu and et al., "QoS-Conditionalized Binding Update in Mobile
IPv6," draft-tkn-nsis-qosbinding-mipv6-00.txt , January 2002. Work
in Progress.
[10] Z. Kan, "Two-plane and Three-tier QoS Framework for Mobile IPv6
Networks," draft-kan-qos-framework-00.txt , April 2002. Work in
Progress.
Charles Qi Shen [Page 7]
Internet Draft NSIS Mobility Framework Issues July 12, 2002
7 Authors' addresses
Charles Qi Shen
Institute for Communications Research (ICR)
20 Science Park Road
#02-34/37, TeleTech Park
Singapore Science Park II
Singapore 117674
Phone: +65 6870-9358
Email: shenqi@icr.a-star.edu.sg
8 Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 assigns. 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.
Table of Contents
1 Abstract ............................................ 1
2 Introduction ........................................ 1
3 Issues about Handoff Impact on NSIS Protocol
Operation ...................................................... 2
Charles Qi Shen [Page 8]
Internet Draft NSIS Mobility Framework Issues July 12, 2002
3.1 The Need for a Separate View on Data and Control
Plane Identifiers .............................................. 2
3.2 Handoff Problem Statement and Basic Requirements .... 2
3.3 Evaluation of Existing Framework Proposals using
Mobile IP Against Requirements ................................. 3
3.3.1 Approach I .......................................... 3
3.3.2 Approach II ......................................... 4
3.3.3 Approach III ........................................ 4
3.3.4 Summary Notes ....................................... 4
3.4 Evaluation with Other Possible Mobility Mechanisms
Against Requirements ........................................... 5
4 Issues on Signaling Layering Between NSIS and
Mobility ....................................................... 5
5 Issue on Soft-State Management in NSIS and
Mobility Interaction ........................................... 6
6 Bibliography ........................................ 7
7 Authors' addresses .................................. 8
8 Full Copyright Statement ............................ 8
Charles Qi Shen [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 08:56:08 |