One document matched: draft-manyfolks-signaling-protocol-mobility-01.txt
Differences from draft-manyfolks-signaling-protocol-mobility-00.txt
IETF Next Steps in Signaling S. Lee, Ed.
Internet-Draft SAMSUNG AIT
Expires: January 17, 2005 S. Jeong
HUFS
H. Tschofenig
Siemens AG
X. Fu
Univ. of Goettingen
J. Manner
Univ. of Helsinki
July 19, 2004
Applicability Statement of NSIS Protocols in Mobile Environments
draft-manyfolks-signaling-protocol-mobility-01.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 January 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Mobility of an IP-based node affects routing paths, and as a result,
can have a dramatic effect on protocol operation and state
Lee, et al. Expires January 17, 2005 [Page 1]
Internet-Draft Applicability Statement July 2004
management. This draft discusses the effects mobility can cause to
the NSIS protocols, and how the protocols operate in different
scenarios, and together with mobility management protocols.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement and General Considerations . . . . . . . . . 8
3.1 Problem statement . . . . . . . . . . . . . . . . . . . . 8
3.2 General Considerations . . . . . . . . . . . . . . . . . . 10
4. Basic operations for mobility support . . . . . . . . . . . . 11
4.1 Generic Route Changes and Mobility . . . . . . . . . . . . 11
4.2 CRN Discovery . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1 Possible approaches for CRN discovery . . . . . . . . 14
4.2.2 The identifiers for CRN discovery . . . . . . . . . . 15
4.2.3 The procedure of the CRN discovery . . . . . . . . . . 17
4.3 Path update . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1 State setup and update . . . . . . . . . . . . . . . . 18
4.3.2 State Teardown . . . . . . . . . . . . . . . . . . . . 20
5. Mobility-Related Issues with NSIS Protocols . . . . . . . . . 22
5.1 Specific Issues with NTLP . . . . . . . . . . . . . . . . 22
5.2 Specific Issues with QoS-NSLP . . . . . . . . . . . . . . 23
5.3 Specific Issues with NAT/FW NSLP . . . . . . . . . . . . . 24
5.4 Common issues related to NTLP and NSLP . . . . . . . . . . 25
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 26
6.1 Support for Macro Mobility-based scenarios . . . . . . . . 26
6.1.1 Implications to Mobile IP-related scenarios . . . . . 27
6.1.1.1 Mobile IPv4-specific issues . . . . . . . . . . . 28
6.1.1.2 Mobile IPv6-specific issues . . . . . . . . . . . 30
6.2 Multihoming/make-before-break scenarios . . . . . . . . . 32
6.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 32
6.2.2 NTLP/NSLP support . . . . . . . . . . . . . . . . . . 33
6.3 QoS Performance Considerations in mobility scenarios . . . 33
6.4 Use cases of Identifiers . . . . . . . . . . . . . . . . . 35
6.5 Peer Failure Scenarios . . . . . . . . . . . . . . . . . . 36
6.6 Guidelines for design of NTLP and NSLPs . . . . . . . . . 37
7. Security Considerations . . . . . . . . . . . . . . . . . . . 38
7.1 MN as data sender . . . . . . . . . . . . . . . . . . . . 38
7.1.1 MN is authorizing entity . . . . . . . . . . . . . . . 38
7.1.2 CN is authorizing entity . . . . . . . . . . . . . . . 40
7.1.2.1 CN asks MN to trigger action (on behalf of the
CN) . . . . . . . . . . . . . . . . . . . . . . . 41
7.1.2.2 CN uses installed state to route message
backwards . . . . . . . . . . . . . . . . . . . . 42
7.1.2.3 MN and CN are authorized . . . . . . . . . . . . . 43
7.1.3 CN as data sender . . . . . . . . . . . . . . . . . . 43
7.1.3.1 CN is authorizing entity . . . . . . . . . . . . . 43
Lee, et al. Expires January 17, 2005 [Page 2]
Internet-Draft Applicability Statement July 2004
7.1.3.2 MN is authorizing entity . . . . . . . . . . . . . 45
7.1.4 Multi-homing Scenarios . . . . . . . . . . . . . . . . 45
7.1.4.1 MN as data sender . . . . . . . . . . . . . . . . 45
7.1.4.2 CN as data sender . . . . . . . . . . . . . . . . 46
7.1.5 Proxy Scenario . . . . . . . . . . . . . . . . . . . . 47
7.1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . 47
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.1 Interaction with Other Mobility-Related Protocols . . . . 49
8.1.1 Interaction with Seamoby Protocols . . . . . . . . . . 49
8.1.2 Interaction with Local Mobility Management
Protocols . . . . . . . . . . . . . . . . . . . . . . 49
8.1.3 State Establishment in Network Mobility Scenarios . . 50
8.2 Additional Issues on CRN discovery and Path Update . . . . 50
8.3 Support for the Ping-Pong Type of Movement . . . . . . . . 50
8.4 When both end-hosts are mobile . . . . . . . . . . . . . . 50
8.5 Bi-directional State Establishment . . . . . . . . . . . . 51
8.6 Priority Reservation . . . . . . . . . . . . . . . . . . . 51
8.7 Aggregation of End-to-End Flows in Mobile Environments . . 51
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 53
9.2 Informative References . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 54
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
B. Anticipated Handover . . . . . . . . . . . . . . . . . . . . . 57
Intellectual Property and Copyright Statements . . . . . . . . 59
Lee, et al. Expires January 17, 2005 [Page 3]
Internet-Draft Applicability Statement July 2004
1. Introduction
The mobility of IP-based nodes incurs route change, usually at the
edge of the network. Route change may also be caused by reasons
other than mobility, such as routing protocol adaptation in response
to varying network conditions (load sharing, load balancing, etc), or
host multi-homing. Normal IP mobility (i.e., macro-mobility) also
involves the change of mobile node IP addresses. Since IP addresses
are usually part of flow identifiers, the change of IP addresses
implies the change of flow identifier. Local mobility usually does
not cause the change of the global IP addresses, but affects the
routing paths within the local access network.
The goals of this draft are to present the effects of mobility on the
NSIS Transport Layer Protocol (NTLP) and on the NSIS Signaling Layer
Protocols (NSLP). The NTLP is an application independent protocol to
transport service-related information between nodes in a network.
Each specific service has its own NSLP protocol.This draft also
discusses how the NSIS protocols should work in various mobility
scenarios.
The discussion is divided into two parts. The first part discusses
the operation of the NSIS protocols in very basic mobility scenarios
(e.g., macro-mobility management protocols such as Mobile IPv4 and
Mobile IPv6), including support for multi-homing. The second part
takes the discussion to more complex scenarios and issues on
interworking with various mobility-related protocols such as Seamoby
and local mobility management protocols.
Lee, et al. Expires January 17, 2005 [Page 4]
Internet-Draft Applicability Statement July 2004
2. Terminology
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 [1].
The terminology in this draft is based on [2] and [3]. In addition,
the following terms are used.
O Downstream
The flow from a data sender towards the destination.
O Upstream
The flow from a data destination towards the sender.
O Crossover Node (CRN)
A Crossover Node is a node that for a given function is a merging
point of two or more separate sets of state information. The CRN
may not necessarily be a physical route splitting point. There
can be different types of logical (but not necessarily physical)
CRNs according to signaling states, flow direction, mobility
management, and normal routing (not caused by mobility):
From the perspective of NSIS states (i.e., NSLP and NTLP
states), the types of CRN are basically classified as follows.
NSLP CRN, from the NSLP's point of view, is a signaling
application-aware node in the network where the
correspondent signaling flows begin to merge or split after
route changes and mobility. The NSLP CRN may be different
according to the types of NSLP.
NTLP CRN, from the NTLP's point of view, is a network node
where more than one NTLP states begin to merge or split
after route changes and mobility.
NSIS CRN is either an NTLP CRN or an NSLP CRN. Note that
although the types of CRN differ according to the state
information, the CRN required for QoS-NSLP operation is the
NSLP CRN which has the corresponding signaling application
information to perform the path update.
There are some differences between route change and mobility in
forming CRN according to the direction of signaling flows
followed by data flows
Lee, et al. Expires January 17, 2005 [Page 5]
Internet-Draft Applicability Statement July 2004
In the mobility scenarios, there are two different types of
merging point in the network according to the direction of
signaling flows followed by data flows as shown in Figure 2
of Section 4.1, where we assume that the MN is a data
sender.
Upstream CRN, after a handover, is the node closest to
the data receiver from which the state information
towards the data sender begins to diverge.
Downstream CRN, after a handover, is the node closest to
the data sender from which the state information towards
the data receiver begins to converge.
In this case, the DCRN and the UCRN may be different due
to the asymmetric characteristics of routing although the
CN is the same.
In the route changes, the path change of signaling flows
results in forming a chain of two CRNs regardless of the
direction of signaling flows followed by data flows as shown
in figure 1 of Section 4.1, which is referred to as a
divergence-convergence pair:
Upstream CRN, after a route changes, is the node at which
the state information towards the data sender begins to
diverge, or to converge. As a result, a
(divergent-convergent) UCRN pair will be formed.
Downstream CRN, after a route changes, is the node at
which the state information towards the data receiver
begins to diverge, or to converge. As a result, a
(divergent-convergent) DCRN pair will be formed.
From mobility management point of view, mobility CRN is the
node where the old and new paths (physically) merge. Note that
in general, mobility CRN may be different from the NSLP CRN or
NTLP CRN.
Routing CRN is the node where using normal routing, the old and
new paths (rather physically) merge. Depending on the location
of nodes, the routing CRN may not be equal to the NSLP CRN or
NTLP CRN.
O Path Update and Local Repair
Path Update is the procedure for the re-establishment of NSIS
Lee, et al. Expires January 17, 2005 [Page 6]
Internet-Draft Applicability Statement July 2004
state on the new path, the teardown of NSIS state on the old path,
and the update of NSIS state on the common path due to the
mobility. This is used to improve mobility handling for the
affected flows.
Upstream Path Update: Path Update for the upstream signaling
flow which is initiated by an upstream signaling initiator. If
the MN is a sender, the Path Update is initiated by an NI on
the common path (e.g., a CN, an HA, or an MAP).
Downstream Path Update: Path Update for the downstream
signaling flow which is triggered by a downstream signaling
initiator. If the MN is a sender, the Path Update is triggered
by an NI on the new path (e.g., an MN, a mobile agent, or an
AR).
In case of route changes, the update of NSIS state on the common
path is not required and it is called Local Repair which localizes
the NSIS signaling. Especially, in mobility scenarios, if the
NSIS signaling interacts with localized mobility management
protocols (e.g., HMIPv6), the Path Update can be localized within
the access network.
O Dead Peer Discovery (DPD)
The procedure for finding a dead NSIS peer due to a link/node
failure and due to an MN moving away.
O Downlink
The direction from the CN towards the MN.
O Uplink
The direction from the MN towards the CN.
Lee, et al. Expires January 17, 2005 [Page 7]
Internet-Draft Applicability Statement July 2004
3. Problem Statement and General Considerations
3.1 Problem statement
IP mobility in its simplest form only includes route changes. Still,
the various protocols that seek to support the mobility of end hosts
may use very special techniques to reach their goals. Most of these
techniques are common IP mechanisms that can also be found in fixed
networks, and therefore, are not by themselves particular. The
operation of NSIS signaling protocols are affected by the following
issues:
O Change of route and possibly change of the MN IP address
Topology changes entail the change of routes for data packets sent
to or from the MN and may lead to the change of host IP addresses.
O Latency of route changes
The change of route and IP addresses is typically much faster and
frequent than traditional route changes, for example, those due to
failure, adding or removal of nodes/links.
O Explicit routes
Signaling protocols usually expect the data traffic to follow the
same path as the signaling traffic, but the data traffic sometimes
traverses the path different from the path of signaling traffic
due to the adaptation of routing protocol according to varying
network conditions such as load balancing, load sharing and
mobility. For example,Mobile IP adds the possibility to use
routing headers to define explicit routes, which diverts the
traffic from an expected path.
O IP-in-IP encapsulation
Mobility protocols may use IP-in-IP encapsulation on the segmnts
of the end-to-end path for routing traffic from the CN to the MN,
and vice versa. Encapsulation harms any attempt to identify and
filter. Moreover, encapsulation may lead to changes in the
routing paths, since the sender and destination IP address differ
from the values in the original user data packet. The same
considerations apply if the signaling packets are encapsulated,
too.
O Ping-pong type handover
NSIS needs to remove states quickly along the old path in order to
Lee, et al. Expires January 17, 2005 [Page 8]
Internet-Draft Applicability Statement July 2004
mitigate the waste of resources. However, in a ping-pong type
handover, the MN returns to the previous AR after staying with the
new AR only for a short while, the prompt removal of state along
the old path causes the state to be re-established soon again and
it adds overhead.
O Upstream Path Update vs. Downstream Path Update
Since the upstream and downstream paths may not be equal, the
upstream and downstream CRNs may not be equal, either. In this
case, Path Update needs to be handled independently for upstream
and downstream flows, including, e.g., the discovery of upstream
and downstream CRNs.
O State identification problem
A mobility event may cause the address of flow endpoints to
change, and in this case it is desirable that signaling
application state is independent of the underlying flow to keep
the state from being re-installed completely. Therefore, the
session and flow identifiers need to be created separately, and
this makes it possible to correlate the session identifier with
the signaling application about the different flows with the same
network control state.
O Double reservation Problem
Since the state on the old path (and the common path) still
remains as it is after re-establishing the state along the new
path due to mobility (or route change), the double reservation
problem occurs. Although the existing state on the old path can
be torn down by the timeout of soft state, the refresh timer value
in the core or wired network is quite long (e.g., 30 seconds in
QoS-NSLP). As a result, in case of QoS-NSLP, the double
reservation problem leads to the waste of resources and call
blocking.
O End-to-end signaling Problem
The mobility may change the flow identifier, and the change of
flow identifier requires state update along the entire path to
reflect the physical location of the MN, resulting in the
end-to-end signaling. This also incurs a long state setup delay
and signaling overhead which affect network performance.
Ultimately, the long state setup delay may particularly give rise
to the service blackout or degradation for multimedia application
in the mobility environment.
Lee, et al. Expires January 17, 2005 [Page 9]
Internet-Draft Applicability Statement July 2004
In summary, NSIS signaling needs to work with basic mobility which
can be considered as an extension to the general route (topological)
change, to handle the change of IP address, and to support mobile IP
tunnels and multi-homing. In this case, Path Update should be
localized, and handled independently for upstream and downstream
flows.
3.2 General Considerations
At the first step, this draft discusses NSIS state establishment
(e.g., QoS-NSLP, NAT/FW, etc) in the macromobility-based scenarios
(e.g., basic Mobile IP (v4 and v6) handovers) and the interaction
with the specific micromobility protocols leading to performance
optimization of NSIS signaling would be discussed further in the next
version of the draft.
Our assumptions in this document and the general considerations are:
O Session-ID is used to index state
Even if an MN has a permanent IP address (its home address), it
cannot be used to index state in the network since the home
address may not easily be visible to interior nodes. Other types
of mobile nodes (e.g., using SIP or other application layer
techniques) may not have permanent addresses at all. After a
movement it obtains a new CoA, which is the basis for routing its
data. If signaling-associated state is indexed based on some
temporary data plane information, such as CoA, the state indexed
by previous CoAs might be inaccessible for the signaling after
most handover procedures.
O Routing may be asymmetric
IP packets arriving to and leaving the MN may be routed
differently. This may be due to the basic triangular routing of
MIPv4, due to the operation of an LMM protocol, or due to
asymmetric routing caused by the basic operation of the IP routing
protocols themselves.
O The CN is not a mobile device
We may later add text to consider a mobile CN, too.
Lee, et al. Expires January 17, 2005 [Page 10]
Internet-Draft Applicability Statement July 2004
4. Basic operations for mobility support
In this section, we discuss the basic operations of NSIS signaling
needed after the route changes including the mobility. The basic
operations include how an appropriate CRN is discovered and how the
Path Update is performed by the NSIS signaling according to the
direction of data flows. The procedure of CRN discovery (in Section
4.2.3) can be applied in the same way as for both the generic route
changes and mobility. However, the Path Update for the generic route
changes is different from that for mobility. This draft mainly
discusses the Path Update for the route changes caused by mobility.
4.1 Generic Route Changes and Mobility
The generic route changes occurs due to load sharing, load balancing,
an link or node failure, but the mobility is associated with the
change of the network attachment point. These cause divergence (or
convergence) between the old path along which state has already been
installed and the new path along which data forwarding will actually
happen.
Although the mobility may be considered similar to the route changes,
the main difference is that the Message Routing Information (MRI:
e.g., flow identifier) may not change after the route change while
the mobility may cause the change of MRI by having a new network
attachment point. Since the session should remain the same after any
mobility event, the MRI should not be used to identify the session of
any signaling application [4].
The route changes brings on the change of signaling topology and it
results in difference according to the types of route change (e.g.,
the route changes or mobility). The route changes generally forms
two common paths, an old path, and a new path, where the old path and
the new path begin to diverge from one common path and afterward to
converge to another common path for each direction of signaling flows
(e.g., downstream or upstream flows) as shown in Figure 1.
Old path
+---+ +---+
^ --->|NE | ... |NE | ------V
common path ^ +---+ +---+ V common path
+--+ +----+ +----+ +--+
|S |-----> |DCRN| |DCRN| -------> |R |
| | | | | | | |
+--+ +----+ New path +----+ +--+
V +---+ +---+ ^
V --->|NE | ... |NAR| ------^
Lee, et al. Expires January 17, 2005 [Page 11]
Internet-Draft Applicability Statement July 2004
+---+ +---+
=======(downstream signaling followed by data flows) ========>
(a) The topology for downstream NSIS signaling flow after the
route changes
Old path
+---+ +---+
v <---|NE | ... |NE | ----- ^
common path v +---+ +---+ ^ common path
+--+ +----+ +----+ +--+
|S |<----- |UCRN| |UCRN| <------- |R |
| | | | | | | |
+--+ +----+ New path +----+ +--+
^ +---+ +---+ v
^ <---|NE | ... |NAR| ----- v
+---+ +---+
<=====(upstream signaling followed by data flows) ========
(b) The topology for upstream NSIS signaling flow after the
route changes
Figure.1 The topology for NSIS signaling in case of the route changes
However, the mobility results in creating a common path, an old path,
and a new path, and the old and new paths only converge or diverge
according to the direction of each signaling flow as shown in Figure
2.
Old path
+--+ +---+
original |MN|------> |OAR| -------------V
address +--+ +---+ V common path
| +----+ +--+
| |DCRN| -------> |CN|
| | | >>>>> | |
v New path +----+ ^ +--+
+--+ +---+ ^ ^
New CoA |MN|------> |NAR|--------------^ ^
+--+ +---+ ^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
(Binding process)
Lee, et al. Expires January 17, 2005 [Page 12]
Internet-Draft Applicability Statement July 2004
====(downstream signaling followed by data flows) ======>
(a) The topology for downstream NSIS signaling flow due to
mobility.
Old path
+--+ +---+
original |MN|<------ |OAR| -------------^
address +--+ +---+ ^ common path
| +----+ +--+
| |UCRN| <------- |CN|
| | | >>>>> | |
v New path +----+ ^ +--+
+--+ +---+ v ^
New CoA |MN|<------ |NAR|--------------v ^
+--+ +---+ ^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
(Binding process)
<=====(upstream signaling followed by data flows) =====
(b) The topology for upstream NSIS signaling flow due to
mobility.
Figure.2 The topology for NSIS signaling caused by mobility.
Figure 2: Signaling topology by mobility event.
These topological changes caused by mobility make the signaling state
established on the old path useless and therefore removed (in the
end). In addition, the existing NSIS state should also be
re-established along the new path and to be updated along the common
path. Note that to minimize the impact on seamless service and
improve signaling scalability, NSIS signaling should be localized
when route changes (including mobility) occur; the localized
signaling procedure is referred to as Local Repair in this draft (in
case of the interaction with localized mobility protocols: see the
terminology section). As an example, in mobility scenarios, although
NSIS signaling messages are initiated by an MN or CN and sent to the
opposite terminating point of the path, the path in the wireless
access network usually changes only partially. Therefore, the NSLP/
NTLP needs to limit the scope of signaling information to a local
section of the signaling path. One of the most appropriate nodes to
do the Local Repair (or Path Update) can be the Crossover node (CRN)
where the old and new session paths meet.
The NTLP module (of a node experiencing a topological change) should
Lee, et al. Expires January 17, 2005 [Page 13]
Internet-Draft Applicability Statement July 2004
detect it through the various mechanisms described in [4] at
transport level and triggers the NSLP operation over itself, and then
the NSLP should initiate necessary NSIS state establishment (i.e.,
QoS re-establishment) along the new path and the update or removal of
associated states, at the signaling application level. Note that in
the case of QoS-NSLP, state re-establishment due to the route changes
does not need any state update along the entire signaling path since
the flow identifier does not change (in other words, the IP address
of endpoint does not change).
4.2 CRN Discovery
4.2.1 Possible approaches for CRN discovery
The approaches for CRN discovery can be divided into two classes
according to which layer is responsible for the discovery of CRN, and
whether the discovery is coupled with the transport of signaling
application messages.
From the NSIS protocol stack point of view, the CRN can be discovered
at both NTLP and NSLP layers. First, the CRN discovery at the NSLP
layer is possible using the information contained in NSLP signaling
messages sent from the signaling initiator. For example, NSLP can
realize that it is a CRN by comparing the Source Identification
Information (SII) contained in the incoming signaling message to the
one stored previously in the node. However, since NTLP is
responsible for detecting the path change of data (or signaling) flow
(and the route changes may easily be detected at the NTLP level
rather than at the NSLP), CRN discovery can be considered as an
extension to the peer discovery at the NTLP level (e.g., using GIMPS
query-response [2]). In general, the GIMPS message has message
routing state information such as flow/session/signaling application
identifier, so signaling application can be identified at the NTLP
level. For example, in the connection mode of NTLP, when NTLP
establishes a messaging association between two adjacent peers, the
NTLP peers exchange message routing state information through GIMPS
query and response messages. Therefore, although the CRN can be
discovered at the NTLP level, the discovered CRN could be actually
NSLP-aware node which has an involved signaling application.
There can also be two different approaches for CRN discovery
according as whether the discovery is coupled with signaling message
or not: the coupled approach and uncoupled approaches. If the
signaling to update NSIS state along a new path or the common path,
after route changes or mobility, is done simultaneously with the CRN
discovery procedure, it is called the coupled approach. If the
signaling to do Path Update is done after the CRN discovery is
completed, it is called the uncoupled approach. These approaches may
Lee, et al. Expires January 17, 2005 [Page 14]
Internet-Draft Applicability Statement July 2004
have some effect on security aspect. Generally, the coupled approach
would be preferred to the uncoupled approach to reduce the delay for
signaling setup. Note that CRN discovery and Path Update described
in this draft are based on the coupled approach.
4.2.2 The identifiers for CRN discovery
There are some basic identifiers which can be used for CRN discovery
at the NTLP level: session identifier, flow identifier (MRI), and
signaling application identifier (NSLP_ID) related to message routing
state [2]), and NSLP branch identifier related to the direction of
NSIS signaling branch.
The session identifier in the GIMPS message is used to easily
identify the involved session because it remains the same while the
MRI may (or may not) change due to handover. The MRI is used to
specify the relationship between the address information and the
state (e.g., QoS-NSLP state) re-establishment. In other words, the
change of MRI indicates topological changes and therefore it
represents that the state along the common path should be updated
after the CRN discovery.
The signaling application identifier (NSLP_ID) is used to refer to
the corresponding NSLP at GIMPS level, and in the context of CRN
discovery it helps to discover an appropriate NSLP CRN using the
GIMPS peer discovery message.
The NSLP branch identifier as a virtual branch identifier can be used
to establish or delete NSIS associations between peers and it can
also be used as an identifier to determine the CRN at the GIMPS
layer. The NSLP branch identifier can consist of the location
information of peer nodes with the correspondent NSLP ID by the
procedure of GIMPS message association. For instance, as shown in
Figure 3, for the downstream case, NSLP1 of node A requires a
messaging association for sending its messages towards node D after a
route changes. In this case, NSIS entity A creates an NSLP branch ID
for NSLP 1 toward node D and increases the counter of NSLP branch ID
to locally distinguish each virtual interface identifier between
adjacent NSLP peers: the corresponding NSLP br.ID is 1-D-#2. Note
that the NSLP branch identifier can be included in the NSIS message,
but it can also be considered as an implementation issue. This
identifier would be more useful when the merging point of the old
path and a new path is not an NSLP CRN after the route change.
Old path
+-----+ +-----+
^---->|NSLP1| ... |NSLP1| ----V
Lee, et al. Expires January 17, 2005 [Page 15]
Internet-Draft Applicability Statement July 2004
common path ^ +-----+ +-----+ V common path
+-----+ +-----+ C K +-----+ +-----+
--->|NSLP1|--->| | | |--->|NSLP1|-->
|NSLP2| |NSLP2| |NSLP2| |NSLP2|
+-----+ +-----+ New path +-----+ +-----+
A B V +-----+ +-----+ ^ M N
V--->|NSLP1| ... |NSLP1| ----^
+-----+ +-----+
D L
=======(Flow direction) ========>
(a) NSIS signaling topology for downstream signaling flow after the
route changes in the middle of the network
+------------------+-------+-------+--------+------------+-------+
| Message Routing |Session| NSLP |Upstream| Downstream | NSLP |
| Information | ID | ID | Peer | Peer |Br. ID |
+------------------+-------+-------+--------+------------+-------+
| Method = Path | 0xABCD| NSLP1 | Z | Pointer to | 1-D-#1|
|Coupled; Flow ID =| | | | A-C | |
| {IP-#X, IP-#V, | | | | Pointer to | 1-D-#2|
| protocol, ports} | | | | A-D | |
| | | | | | 1-U-#1|
| Method = Path | | | | | |
|Coupled; Flow ID =| 0x1234| NSLP2 | Z | (null) | 2-D-#1|
| {IP-#X, IP-#V, | | | | | |
| protocol, ports} | | | | | 2-U-#1|
+------------------+-------+-------+--------+------------+-------+
(b) Routing state table at node A (NSLP CRN)
+------------------+-------+-------+----------+----------+-------+
| Message Routing |Session| NSLP |Upstream |Downstream| NSLP |
| Information | ID | ID | Peer | Peer |Br. ID |
+------------------+-------+-------+----------+----------+-------+
| Method = Path | 0xABCD| NSLP1 |Pointer to| (null) | 1-U-#1|
|Coupled; Flow ID =| | | K-N | | |
| {IP-#X, IP-#V, | | |Pointer to| | 1-U-#2|
| protocol, ports} | | | L-N | | |
| | | | | | 1-D-#1|
| Method = Path | | | | | |
|Coupled; Flow ID =| 0x1234| NSLP2 | M | (null) | 2-U-#1|
| {IP-#X, IP-#V, | | | | | |
| protocol, ports} | | | | | 2-D-#1|
+------------------+-------+-------+----------+----------+-------+
Lee, et al. Expires January 17, 2005 [Page 16]
Internet-Draft Applicability Statement July 2004
(C) Routing state table at node N (NSLP CRN)
Figure.3 Routing state table and NSLP branch ID
Optionally, the mobility identifier as an object form can also be
used for immediate CRN discovery in various mobility scenarios. The
mobility object can also be used for other purposes. The more
details are discussed further in Section 6.4.
4.2.3 The procedure of the CRN discovery
In general, when a mobility event occurs, the CRN can be recognized
by comparing the existing message routing information (e.g., the NSLP
ID, the session identifier and MRI) and the NSLP branch ID with the
message routing information and the NSLP branch ID (with different
counter number) included in the NTLP peer discovery message initiated
by an NI (e.g., an MN or a CN). For example, if an NTLP message is
routed to an NSIS peer node, the following information (shown in
Figure 3 (b) and (c)) is checked:
- Whether the same NSLP ID exists,
- Whether the corresponding CRN is already discovered,
- Whether the same session identifier and MRI exist,
- Whether the NSLP branch identifier is changed: for example, as
shown in Figure 3 (b), it for NSLP 1 changed to 1-D-#2 from
1-D-#1,
- Optionally, check the mobility identifier, if any: for example,
the Mobility object to know which message is sent due to the
latest handover (see Section 6.4).
The CRN discovery can be further divided into UCRN discovery and DCRN
discovery according to which node is a signaling initiator (by
upstream or downstream), or whether the MN is a data sender:
- If the MN is a data sender and when a mobility event occurs, the
MN begins to transmit signaling messages toward a CN in the
downstream direction. In this case, an NSLP-aware node recognizes
that the session paths logically converge, and then the NSLP-aware
node realizes it is the DCRN through the procedure above: the
procedure of CRN discovery is similar to the creation of the
routing table of node N except for the unchanged flow ID.
- When an MN (as a sender) undergoes handover, the UCRN can be
determined for upstream flow by the method above. In this case,
Lee, et al. Expires January 17, 2005 [Page 17]
Internet-Draft Applicability Statement July 2004
the UCRN should be the first node where the signaling flow begins
to logically diverge: it is similar to the creation of the routing
table of node A except for the unchanged flow ID. Since the UCRN
is determined by whether outgoing path diverges or not, the UCRN
discovery is more complex than the DCRN discovery.
4.3 Path update
The CRN discovery is different according to the direction of
signaling flow in mobility scenarios, and the DCRN operates
independently of the UCRN although DCRN and UCRN can be
simultaneously ferreted in bi-directional state establishment.
Therefore, the procedures for path update may differ according to the
direction of signaling flows as defined in terminology section: the
upstream Path Update and the downstream Path Update. In this case,
each signaling initiator has to be authorized for secure signaling.
For both types of path update, NSIS protocol needs to interact with
various mobility signaling protocols, if any (during or posterior
handover) to obtain performance gains through fast re-establishment
of the NSIS states along the new path. In this case, NSIS also needs
to monitor the movement of a mobile node through several methods
[4].In this section, we assume that an MN is a data sender.In this
section, we assume that an MN is a data sender.
4.3.1 State setup and update
Before initiating the Path Update, an MN or a CN needs to have its
session ownership by the procedure of authentication and
authorization and to check the availability of resources on the new
path. If the resources along the new path run short of, it needs to
keep state previously established for the flows while blocking new
requests. In this case, NSIS signaling for the Path Update also
needs to have an appropriate priority over local requests for the
resources.
In the downstream path update, if resource availability is assured,
the MN initiates the NSIS signaling for state setup toward a CN along
the new path, and the DCRN discovery is implicitly done by this type
of signaling initiated by the MN. In this case, the node where the
old and new logical session paths converge realizes that it is the
DCRN, and afterward the DCRN sends a response message toward the MN
to notify of NSLP state installed (e.g., in QoS-NSLP) or installs the
NSLP states as responding the NSLP signaling initiated by the MN
(e.g., as in RSVP). In this case, the sender-initiated approach
(e.g., QoS-NSLP) leads to faster setup than the receiver-initiated
approach as RSVP as shown in Figure 4 below. And then, the DCRN
sends a refresh message toward the signaling destination to update
Lee, et al. Expires January 17, 2005 [Page 18]
Internet-Draft Applicability Statement July 2004
the changed MRI on the common path and also sends a teardown message
toward the old AR to delete the NSIS states along the obsolete path
(if possible).
NI (MN) NF NF NR (CN)
| | | |
| RESERVE | | |
+--------->| RESERVE | |
| +--------->| RESERVE |
| | +--------->|
| | | |
| | | RESPONSE |
| | RESPONSE |<---------+
| RESPONSE |<---------+ |
|<---------+ | |
| | | |
| | | |
(a) Sender Initiated Reservation
NI (MN) NF NF NR (CN)
| | | |
| QUERY | | |
+--------->| QUERY | |
| +--------->| QUERY |
| | +--------->|
| | | |
| | | RESERVE |
| | RESERVE |<---------+
| RESERVE |<---------+ |
|<---------+ | |
| | | |
| RESPONSE | | |
+--------->| RESPONSE | |
| +--------->| RESPONSE |
| | +--------->|
| | | |
b) Receiver Initiated Reservation
Figure.4 Sender- vs. Receiver-intiated reservation
In the case of upstream path update, the CN (or a HA/ a GFA/MAP)
sends a refresh message toward the MN to perform path update. UCRN
is discovered implicitly by the CN-initiated signaling along the
Lee, et al. Expires January 17, 2005 [Page 19]
Internet-Draft Applicability Statement July 2004
common path, and the node from which the common path begins to
diverge into the old and new logical session paths realizes that it
is the UCRN. In this case, the CN should be informed of the movement
event using an NSIS signaling message sent by the MN or monitoring
the mobility signaling after detecting a change in its binding entry
(see Section 6.1). After the UCRN is determined as described in
Section 4.2.3, it may send a refresh message to the MN along the new
path while establishing the NSIS association between the updated
peers, and afterward the UCRN may send a teardown message toward the
old AR to delete the NSIS state on the obsolete path (if possible).
The state update in control plane on the common path to reflect the
changed MRI brings issues on the end-to-end signaling addressed in
Section 3.1. Although the state update does not give rise to
re-process AAA and admission control, it may lead to the signaling
overhead and latency.
One of the goals of path update is to avoid double reservations (in
case of QoS signaling) on the common path described in Section 3.1.
The double reservation occurred along the common path may be solved
by establishing a signaling association using the unique session
identifier and by the update of packet classifier/flow identifier.
In this case, the NSLP state can be shared for flows with different
flow identifiers.
4.3.2 State Teardown
After re-establishment of the NSIS state along the new path, the
state on the obsolete path need to be quickly removed by path update
mechanism to prevent the waste of resources due to double reservation
(and resource allocation problem by call blocking) and to reduce the
cost of using the resources in the access network as described in
Section 3.1. Although the release of the existing state on the old
path can be accomplished by timeout of soft state, the refresh timer
value may be quite long and the maintenance of the NSIS state on the
obsolete path may not be necessary. Therefore, the transmission of a
teardown message is particularly preferred to the use of refresh
timer to quickly delete the old state. Note that, however, it is not
necessary for the GIMPS to be explicitly removed because of the
inexpensiveness of the state maintenance.
The CRN is an appropriate point to initiate the teardown toward the
old AR after re-establishment of the state along the new path. In
this case, the release of old state on the obsolete path can be
accomplished by comparing the NSLP branch ID and through reverse
routing using SII. This can prevent the teardown message from being
forwarding toward along the common path. However, whether the
teardown message can be sent toward the opposite direction to the
Lee, et al. Expires January 17, 2005 [Page 20]
Internet-Draft Applicability Statement July 2004
state initiating node is still an open question. This also leads to
authorization problem because a node which does not initiate
signaling for establishing the NSIS state can delete the state.
The immediate removal of state along the old path may not be
appropriate for some mobility situations. For instance, in the fast
handover of a ping-pong type where an MN may return to the previous
AR after staying at a new AR for a short while, it causes signaling
overhead and when to delete the state along the obsolete path remains
still an open issue and needs to be discussed further in the later
version of this draft. Another example is the last node detection
problem. If the old AR is the last node due to handover, its NSLP
may trigger an error message to indicate that NSLP messages cannot be
forwarded any further. This error message may cause the removal of
the old states. However, although the error message is initiated,
the state on the old path should not be deleted before
re-establishing the state along the new path (make-before-break
handover). The more details are discussed further in Section 6.5.
Lee, et al. Expires January 17, 2005 [Page 21]
Internet-Draft Applicability Statement July 2004
5. Mobility-Related Issues with NSIS Protocols
5.1 Specific Issues with NTLP
The NTLP protocol maintains a per-flow message routing state and a
per-peer messaging association state. The former is installed and
maintained by a peer discovery mechanism, while the latter is set up
by the normal procedures of transport (and security protocols, when
secure channel for C-message transport is desired) that comprise the
messaging association.
NTLP is responsible for detecting route change, updating its own
routing state consistently, and informing NSLPs at affected nodes.
In mobility environments, for an end-to-end signaling flow, its
signaling path can be changed upon a successful MIP registration.
This means a new peer discovery procedure needs to be triggered
(e.g., through certain routing interface) and a new NTLP message
routing state must be adapted.
NTLP provides 5 mechanisms to detect a route change. In uplink
signaling case in mobility environments an MN can use the first
approach, local trigger, to determine next hop has changed and
initiate a new peer discovery until downstream CRN is found. In
downlink signaling case mobility environments, most detection
mechanisms at CN, HA or other mobility agents (if they support NSIS
at all) can only determine a route has "changed", i.e., a binding
cache changed. However, these entities do not necessitate an actual
NTLP or NSLP CRN, and the latter is the actual node of NSIS interests
and needs to be detected. This is an issue related to an NTLP
implementation's scale of re-discovery.
After detecting a route change has occurred, in addition to updating
the message routing state, an NTLP implementation at the downstream
CRN needs to notify local NSLP(s) to initiate their own state local
repairs. Messaging association state can be ignored as it is
per-peer meaningful and not very expensive.
NTLP works with general IP tunneling by applying the same
encapsulation to NSIS messages as data packets. Most mobility
protocols involve IP-in-IP encapsulation in part of the signaling
path. As this becomes effective dynamically after a mobility
registration, an NTLP implementation should gain the knowledge about
the introduction or change of encapsulation methods in the responding
node, if NSLPs want to be signaled into these tunnels. Moreover,
IP-in-IP encapsulation is simultaneously coupled with route change,
thus an NTLP implementation needs to interact with mobility
registration carefully.
Lee, et al. Expires January 17, 2005 [Page 22]
Internet-Draft Applicability Statement July 2004
5.2 Specific Issues with QoS-NSLP
The QoS-NSLP protocol establishes and maintains QoS-related state at
NSIS aware nodes along the path of data flow to support some
forwarding resources required for that flow. In mobility scenarios,
as mentioned in Section 4, the QoS-NSLP protocol needs to immediately
perform the procedure of the Path Update after an appropriate CRN is
discovered to continue to support QoS-related state for that session.
In this case, the following basic issues rise when considering
interaction with GIMPS layer as well as mobility protocols:
- When/how is QoS-NSLP signaling initiated after mobility? For
instance, if an MN is a sender and the sender-initiated
reservation approach is used, when does the MN send RESERVE
message forward CN to do the Path Update (and CRN discovery if
coupled approach is used)? In the receiver-initiated reservation,
when is Query message sent to a corresponding receiver or node
initiating reservation? In this case, QoS-NSLP should know or
detect the MNí¯s movement, e.g., through the SII notified over API
between GIMPS and QoS-NSLP (see Sections 5.4 and 6.1).
- How/when does an MN know/find out what resources are available
before a reservation is made after handover? And If QoS-resources
in a new access network are oversubscribed, how is the reservation
for required resources made? The QoS-NSLP of MN may be able to
know the availability of resources at the new access network using
Query message. In this case, the Query message needs to have a
priority rather than any other signaling: priority signaling for
call setup. If an MN moves an access network which does not have
a sufficient resources available, the MN may fail to reserve the
resources and it tries to keep the previous state by its mulihomed
interfaces. In such an oversubscribed scenario, certain signaling
message required for reservation may also be prioritized, but how
those signaling messages are dealt with priority is still open and
so needs to be discussed further in the later version of this
draft.
- Which layer should the (NSLP) CRN discovery be performed at, GIMPS
or QoS-NSLP? Although a QoS-NSLP can detect the change of
signaling path and discover the CRN by keeping track of SII, The
CRN discovery may be preferred at the GIMPS layer to at the
QoS-NSLP. As mentioned Section 4, since GIMPS detects the CRN as
an extension of peer discovery, it does not add processing
overhead.
- How/by who can RESPONSE message be sent to the corresponding QNI
if QNR (e.g., an MN) of the RESPONSE message performs handover
before the receipt of the message? If RESERVE (for refresh)
Lee, et al. Expires January 17, 2005 [Page 23]
Internet-Draft Applicability Statement July 2004
including Response request is sent to the MN from a node but the
MN begins to handover the OAR in behalf of the MN may be a proxy
to initiate RESPONSE message. In this case, the MN may notify OAR
of the handover or error conditions
(the-last-node-is-not-detected) using NOTIFY message. This
í«invalid-NRí¯ problem is discussed further in Section 6.5.
- How is refresh time set up in the situation of frequent handover?
The QoS-NSLP uses peer-to-peer refreshing approach to allow QNEs
to choose appropriate refresh intervals according to their network
environments (e.g., an access network, or a core network). In
mobility environments, refresh time intervals-related issues are
discussed in Section 6.3
- How does CRN immediately remove the state along the old path after
the establishment of state along a new path? The CRN can delete
the state along the old path by keeping track of SII or using
Request Identification Information (RII). Since the SII object is
similar in nature to the RSVP HOP object [5], RESERVE message set
with TEAR flag can be forwarded to the direction of reverse path.
In route change, the RII contained RESPONSE_REQUEST object (if
any) allows the CRN to correctly send back the RESERVE message
with TEAR flag to an appropriate (scoped) node. Note that as
mentioned in Section 5.1, NTLP state along the old path does not
need to be explicitly deleted before the expiration of the refresh
time interval because of inexpensive of NTLP state.
Some issues according to performance gain, bi-directional
reservation, aggregation reservation and various handover scenarios
are discussed further in Section 6: for example, refresh reduction,
session binding, layering, peer agreement, and so on.
5.3 Specific Issues with NAT/FW NSLP
The NAT/Firewall NSLP [6] establishes and maintains firewall pinholes
and NAT bindings at NAT/FW NSLP nodes along the data path. With
regard to mobility a few issues need to be considered:
In case of an IP address change firewall rules and/or NAT bindings
become invalid which effectively prevents the end host from
sending or receiving data packets. For example, without updating
the firewall pinhole by a NSIS aware data sender who is located
behind a firewall data packets with a new source IP address are
most likely dropped at the firewall. If a data receiver , who is
located behind a NAT, changes its IP address then incoming packets
are rewritten at the NAT and forwarded to the wrong IP address.
The QoS NSLPs might 'only' temporarily experience a weaker quality
of service if the installed flow identifier is not uptodate.
Lee, et al. Expires January 17, 2005 [Page 24]
Internet-Draft Applicability Statement July 2004
Although NSIS applies the soft-state principle and allocated state
times out without refresh messages, it is possible that mobility
leaves state (such as firewall pinholes) in place for some time.
Since the NAT/Firewall NSLP aims to install pinholes (and NAT
bindings) it is possible to re-use this installed state once a
mobile node roams to a new location. Deleting state along the old
path helps to limit this problem. However, this problem exists
anyway as identified in [7] due to the capability of IP spoofing
since the main problem is the usage of non-cryptographically based
IP address filters. Hence, the NAT/Firewall NSLP is (in a
mobility environment) not in the same fashion concerned about
deletion of state along the old path.
There also seem to be some differences between the security
functionality required by the QoS NSLP and the NAT/Firewall NSLP
(as analysed in [7], in [6] and in [8]. The security solution for
the NAT/Firewall NSLP needs to reflect mobility specific security
issues. This also has an impact on refresh handling (i.e.,
peer-to-peer vs. end-to-end), authorization issues, the usage of
the session identifier and end-to-end security (with regard to
the binding between NSIS and the application layer signaling).
5.4 Common issues related to NTLP and NSLP
In mobile environments, mobility related information for path update
can be exchanged through the API specified in [NTLP]. For example,
when a route change due to mobility occurs, SII-Handle can be
provided from GIMPS to an NSLP in order to inform of the route
change. The SII-Handle is a handle to a data structure, identifying
peer addresses and interfaces. It can be used to identify route
changes and for explicit routing to a particular GIMPS next hop.
Based on the information, the involved NSLP can initiate path update
by sending necessary signaling messages through the API. The details
on the API are an implementation issue.
Message routing information (MRI) and Session ID are also shared by
the GIMPS and NSLP through the API. Whenever there is any route
change due to mobility the MRI will be updated although the Session
ID will not change. The MRI should be consistent with the SII-Handle
described above.
Lee, et al. Expires January 17, 2005 [Page 25]
Internet-Draft Applicability Statement July 2004
6. Applicability Statement
6.1 Support for Macro Mobility-based scenarios
This section considers how should NSIS protocols interact with the
basic macro mobility protocols such as Mobile IPv4 and Mobile IPv6,
and other global mobility approaches will be discussed further in the
next version of this draft.
The NSIS signaling needs to consider the following scenarios related
to basic Mobile IP to interact with it.
(1) A flow associated with an MN, either sent or received by the MN,
may desire to be continuely served signaling services after a
mobile IP handover. In this case, NSIS needs to be able to signal
for such flows upon an MN's movements to seamlessly provide the
correspondin service to one (e.g., QoS). The signaling procedure
results in creating a new NSIS branch along the new path through
an appropriate CRN discovery and a Path Update.
(2) Either the sender or the receiver of an MN's flow can initialize
an NSIS signaling, and it is essential to require the NSIS
signaling initiator to be authorized to initialize the signaling.
Note that nodes within the network may also initiate NSIS
signaling for the given session, for example, to handle route
changes caused by Mobile IP routing in the middle of the network,
or to support seamless handovers.
(3) Data traffic, in either direction between an MN and a CN, can be
routed directly using a routing header, or indirectly by IP-in-IP
encapsulation (or the combination of them) in different segments
of the data transmission depending on the mobility mode (either
route optimization or triangle routing is used; whether reverse
tunneling is used; either mobile IPv4 or IPv6 is used; whether LMM
is used, etc.). In this case, NSIS signaling needs to immediately
be initiated by using a mobility routing interface (e.g., mobility
API) between the NSIS protocols and the Mobile IP according to the
method of each routing.
(4) An MN's handover can be either intra-domain (within an access
network domain) or inter-domain (from an access network domain to
another), which mainly concerns with topology information
exchange, authorization and accounting issues. The interworking
with NSIS signaling and some mobility management protocols (i.e.,
HMIP, FMIP, etc) in various handover scenarios may give rise to
some performance gains (see Section 6.3).
(5) In mobile IPv6, an MN can support multiple care-of-addresses at
Lee, et al. Expires January 17, 2005 [Page 26]
Internet-Draft Applicability Statement July 2004
one time, if it is connected to multiple access networks
simultaneously (or even if it is connected to one access network).
Although only one primary care-of-address will be used for routing
traffic from the CN to the MN, this multi-homing feature
potentially can be used to enhance the NSIS signaling performance
(see Section 6.2). The inter-domain handover, for instance, may
require additional latency to perform the NSIS signaling procedure
including authentication and authorization rather than the
intra-domain handover, but the latency penalty of NSIS signaling
can be mitigated if the MN is multi-homed.
6.1.1 Implications to Mobile IP-related scenarios
As NSIS is path-coupled signaling, one imposed requirement here is
that the NSIS protocols are to be typically associated with a route
changes for route optimization between the CN & the MN and an
IP-in-IP encapsulation from the HA to the MN as well as mobility, and
those interaction also needs to be notified to all NSLPs by the API
between GIMPS and NSLP for the CRN discovery and the Path Update as
described in Section 4. Therefore, NTLP or NSLP needs to have an
interface with the Mobile IP to immediately react to the mobility
event. In other words, NSIS implementation needs to be designed to
react based on the endpoint notification of which behaviour of Mobile
IP has taken place and probably, when the timer of Mobile IP
refreshes (to keep corresponding NSLPs reacting to it).
An ideal interface between NSIS signaling and the Mobile IP should
make that NSIS signaling is able to react to the mobility event as
soon as possible whenever Mobile IP changes its characteristics in
any place for the flows, In general, it is appropriate that NTLP is
involved in the interaction with the Mobile IP rahter than NSLP,
because NTLP is responsible for detecting the mobility and routing
NSIS messages. Therefore, it is reasonable to assume NTLP should be
able to notify NSLP of the update of state when mobiity is detected.
Here also are some issues which rise when the API between the NSIS
and the Mobile IP is considered.
- Which information does the NTLP detect the movement based on?
After an MN arrives at a new network attachment point, current
reachability information is transferred from the MN to its HA as
the last procedure of handover. It indicates that NTLP may need
to interact with the start/completion of a binding process (e.g.,
registration request in Mobile IPv4 and Binding Update in Mobile
IPv6) to detect the IP address change and refer to the tunnel
information of Mobile IP. Therefore, provided the NTLP detects
the mobility using the information of binding process, faster
state establishment and removal can be performed. However, in the
fast or ping-pong handover, it may result in considerable
Lee, et al. Expires January 17, 2005 [Page 27]
Internet-Draft Applicability Statement July 2004
signaling overhead and some possible errors.
- How and what information can the NSLP expect from NTLP, or
directly from the routing interface after mobility?
- How to coordinate the mobility binding update interval and NSIS
signaling interval? Since the Binding Update or the Registration
request message occur periodically even for the MN with the same
point of attachment, the movement detection based on the binding
process sometimes causes the NTLP/NSLP to inappropriately initiate
the CRN discovery and the Path Update. Although the issue is
closely related to implementation, it needs to be considered to
have the performance gain of NSIS signaling.
An overall coordination/synchronization about the interworking with
the NSIS and the Mobile IP is still open and needs to be discussed
further.
6.1.1.1 Mobile IPv4-specific issues
The data flows of Mobile IPv4 are forwarded based on the triangular
routing (even if route optimization is considered an extended
option), and an MN retains a new CoA from the FA (or the external
method such as DHCP) in the corresponding access network unlike the
Mobile IPv6 whenever the MN arrives at the new network attachment
point (e.g., a FA or a foreign link)[9]. When the MN is a sender,
the downstream data flows from the MN are directly transferred to the
CN not necessarily through the HA or indirectly through the HA using
the reverse routing. On the other hand, upstream data flows from the
CN are routed through the IP tunneling between the HA and the FA (or
the HA and the MN in the case of the Co-located CoA). In this case
of such a routing which is dependent on the HA, it represents that
the NSIS signaling needs to interact with the IP tunneling of Mobile
IP to provide an appropriate signaling service for that flow.
The following figures 5 (a)-(e) show the NSIS signaling flows
required according to the direction of data flows and the routing
methods .
MN FA (or FL) CN
| | |
| IPv4-based Standard IP routing |
|------------ |------------------------------>|
| | |
(a) MIPv4: MN-->CN, no reverse tunnel
Lee, et al. Expires January 17, 2005 [Page 28]
Internet-Draft Applicability Statement July 2004
MN FA HA CN
| IPv4 (normal) | | |
|--------------->| IPv4(tunnel) | |
| |--------------->| IPv4 (normal) |
| | |-------------->|
(b) MIPv4: MN-->CN, the reverse tunnel with FA Care-of-Address
MN (FL) HA CN
| | | |
| IPv4(tunnel) | |
|------------------------------->|IPv4 (normal) |
| | |-------------->|
(c) MIPv4: MN-->CN, the reverse tunnel with Co-located
Care-of-address
CN HA FA MN
|IPv4 (normal) | | |
|-------------->| | |
| | MIPv4 (tunnel) | |
| |---------------->| IPv4 (normal)|
| | |------------->|
(d) MIPv4: CN-->MN, Foreign agent Care-of-address
CN HA (FL) MN
|IPv4(normal ) | | |
|-------------->| | |
| | MIPv4 (tunnel) | |
| |------------------------------->|
| | | |
(e) MIPv4: CN-->MN with Co-located Care-of-address
Figure 5. Implications for signaling under different Mobile IPv4
scenarios
When an MN (as a sender) arrives at a new FA and the corresponding
binding process for the FA CoA is completed:
- For downstream signaling flow, the MN needs to perform the CRN
discovery (DCRN) and the (downstream) Path Update toward the CN as
described in Section 4 to establish the NSIS state along the new
path between the MN and the CN as shown in Figure 6 (a). If the
reverse tunnel is used and the state along the tunneling path does
not exist, the NSIS state may be established along the tunneling
Lee, et al. Expires January 17, 2005 [Page 29]
Internet-Draft Applicability Statement July 2004
path from the FA to the HA as shown in Figure 6 (b). In this
case, the DCRN may be discovered on the tunneling path and the new
flow identifier for the tunneling state update may need to be
created.
- For upstream signaling flow, the CN may initiate the NSIS
signaling to update the existing state between the CN and the HA,
and then NSIS signaling may need to interact with IP tunneling to
also update the state along the tunneling segment from the HA to
the FA as shown in Figure 6 (d). In this case, the UCRN may be
discovered somewhere on the tunneling path, and the new flow
identifier for the tunneling state update may be created.
When the MN (as a sender) arrives at a new foreign link and the
corresponding binding process for the co-located CoA is completed:
- For downstream signaling flow, the NSIS signaling for the DCRN
discovery and the Path Update is equal to the case for FA CoA
above (as shown in Figure (a)) except that in case of using the
reverse tunnel, the NSIS state may be established along the
tunneling path from the MN to the HA as shown in Figure 6 (C).
- For upstream signaling flow, the CN may initiate the NSIS
signaling to update the existing state between the CN and the HA
and then NSIS signaling may need to interact with IP tunneling to
also update the state along the tunneling segment from the HA to
the MN as shown in Figure 6 (e). In this case, the UCRN may
eventually be discovered somewhere on the tunneling path, and the
new flow identifier for the tunneling state update may also be
created.
Note that in the case of interaction with IP tunneling, DCRN and UCRN
may be identified at the same node on the tunneling path. For
example, NSIS CRN may usually be the HA if the HA and the FA are
NSIS-aware and the NSIS state along the tunneling path is not
established. Therefore, the CRN discovery may be affected according
to the interaction with NSIS signaling and IP tunneling, and the FA
and the HA should be NSIS-aware to do the Path Update along the
appropriate path. However, the effect that the IP tunneling has on
the CRN discovery and the Path Update needs to be discussed further.
6.1.1.2 Mobile IPv6-specific issues
The Mobile IPv6 case differs from Mobile IPv4 in that an FA is not
required in the data path and the Route Optimization process between
the MN and CN is basically used to avoid the triangular routing in
the Mobile IPv4 scenarios as shown in Figure 6 [10]. Therefore, if
the use of route optimization is not mandatory, data flow routing and
Lee, et al. Expires January 17, 2005 [Page 30]
Internet-Draft Applicability Statement July 2004
NSIS signaling procedure (including the CRN discovery and the Path
Update) of Mobile IPv6 would be similar to that of the Mobile IPv4
described in Section 6.1.2.1.
When an MN (as a sender) arrives at a new AR and the binding process
is successfully completed, for downstream signaling flow, the MN may
initiate NSIS signaling for DCRN discovery and the (downstream) Path
Update to establish the state along the new path between the MN and
the CN or the tunneling path from the MN to the HA if the reverse
tunnel is used, as shown in Figure 6 (a) & (b), repectively. for
upstream signaling flow, the CN may also update the state along the
common path toward the HA through the Path Update and afterward the
NSIS state along the tunneling segment from the HA to the MN may be
updated by interaction with IP tunneling as shown in Figure 6 (d).
However, if the route optimization is performed successfully between
the CN and the MN, for upstream flow, CN needs to newly initiate NSIS
signaling to discover an appropriate UCRN and do the Path Update
along a new path between the CN and the MN as shown in Figure 6 (c):
bidirectional state establishment may be required. In this case, the
obsolete path of the existing tunneling segments needs to
appropriately be removed after re-establishment of NSIS state along
the optimized path. However, when to remove the tunneling segment
and/or how to tear it down through the interworking with the
IP-tunneling is still an open issue.
Although the routing of Mobile IPv4 with the co-located CoA is
similar to that of Mobile IPv6 as shown in Figure 5 (a), (c) and (e),
one of the differences between the Mobile IPv6 and the Mobile IPv4 is
the method to acquire the CoA. That is, the Mobile IPv6 can usually
acquire the CoA from the corresponding access router or external
method through the stateless autoconfiguration or the stateful
autoconfiguration (e.g., DHCPv6), respectively , and the Mobile IPv4
obtains the co-located CoA using an external method such as DHCP.
This difference may have some effects on the creation of flow
identifier and make NSIS signaling performed differently according to
Mobile IP mode. However, it is still open and needs to be discussed
further in the later version of this draft.
MN CN
| |
|IPv6+HomeAdressOpt |
|--------------------------------------------->|
| |
(a) MIPv6: MN-->CN, no reverse tunnel
Lee, et al. Expires January 17, 2005 [Page 31]
Internet-Draft Applicability Statement July 2004
MN HA CN
|IPv6(tunnel) | |
|------------->| IPv6(normal) |
| |------------------------------>|
| | |
(b) MIPv6: MN-->CN, with reverse tunnel
CN MN
| |
| MIPv6(RH Type 2) |
|--------------------------------------------->|
| |
(c) MIPv6: CN-->MN, route optimization
CN HA MN
|IPv6(normal) | |
|------------->| |
| | MIPv6(tunnel) |
| |------------------------------>|
| | |
(d) MIPv6: CN-->MN, no route optimization
Figure 6. Implications for signaling under different Mobile IPv6
scenarios
6.2 Multihoming/make-before-break scenarios
6.2.1 Overview
A host that is an initiator or responder of signaling messages may be
either multi-homed or mobile in some cases. Especially, when current
activities in the multi6 WG are considered, multi-homed hosts and
scenarios may be very common in a future IPv6 Internet. Such
scenarios may also include load balancing techniques, i.e., when
multiple connections to different providers are used simultaneously.
Therefore, multi-homed hosts may use different paths that converge at
some CRN. If load balancing is active, the paths are used at the
same time, but if multi-homing is used for resilience only, the
active path changes during fail-over.
For mobile hosts flow paths are changed when the point of network
attachment is changed. This may also require a change of state in
network elements along the old and new paths.The term "seamless
mobility" is often referred to mean that the MN is able to keep an
ongoing session seamlessly (without experiencing perceivable service
Lee, et al. Expires January 17, 2005 [Page 32]
Internet-Draft Applicability Statement July 2004
interruption or performance penalty) during and after moving from one
access network to another. Measures to achieve seamless mobility
include soft handover and anticipated handover [QoSSig4G]. The
former requires the MN to keep the old path, while data is received
over the new path. This approach is only possible if the MN is
multi-homed. Appendix B discusses fast state installation by using
anticipated handovers, in which the MN signals the new path while
still connected to the old one.
6.2.2 NTLP/NSLP support
NTLP uses endpoint address to install message routing state, thus the
new address for an MN introduced in MIP has to invoke a change of
message routing state. In multihomed MN scenarios, both new address
and old address can be valid during a certain period of time, the new
data path may co-exist with the old one. It is theoretically
possible to perform certain NSIS state update in the new path during
this period, however the signaling ends need to be careful, so that
the correct routing information will be delivered for setting up new
or updating existing message routing state in the correct path
segment. Furthermore, performing such actions should not cause NSLP
service interruption, protocol misbehaviors or security holes and
thus should be discouraged.
6.3 QoS Performance Considerations in mobility scenarios
The routing characteristics of mobile IP system described in Section
6.1 cause the session path to be changed and in this case the exiting
protocols which do not support signaling in dynamic environment where
route change or mobility event occurs can cause the problems
addressed in Section 3.1. Particularly, in mobile/wireless
environments, QoS parameters such as resource utilization and
signaling latency need to be considered so that how NSIS protocols
should interact with mobility protocols is correctly evaluated. In
the perspective of resource utilization, the double reservation
problem leading to the waste of resource and call blocking is
generally known in handover scenarios and it may be alleviated by the
procedure of the CRN discovery and the Path Update described in
Section 4. In this section, we take into consideration on how the
resource utilization of the NSIS signaling flow itself can be
managed: The adjustment of refresh time interval and refresh
reduction.
The NSIS protocol suite normally use a soft-state approach based on
the peer-to-peer refreshing to manage state in NEs. At the GIMPS
layer, the state is maintained through the exchange of GIMPS query/
response messages between adjacent peers [2]. In this case, the peer
relationship is maintained using a timer which implies how long the
Lee, et al. Expires January 17, 2005 [Page 33]
Internet-Draft Applicability Statement July 2004
association between the peers can be considered valid. That is, if
it has not been refreshed until the timer expires (e.g., after 30
seconds as a default value), the peer relationship is removed. The
management of state (i.e., routing state and messaging association)
can be controlled in this way. In case of QoS-NSLP, states are also
set up and then maintained for the reservation of desired resources
using the peer-to-peer refresh messages. The peer-to-peer based
refreshment allows the QoS-NSLP to appropriately select the refresh
time by considering the current network environment. For example, it
may set the refresh timer value in the mobile/wireless (access)
network to a smaller value than that in the core (wired) network by
the method described in [11]. In the situation of frequent handover,
the adjustment of the refresh time results in minimizing the waste of
resources. Note that, however, unlike the QoS-NSLP, the refresh time
of NTLP state doesn't need to be adjusted according to the type of
the network from the perspective of resource utilization.
Furthermore, NTLP state along the obsolete path does not also need to
be explicitly removed before the expiration of refresh timer.
In mobile and wireless networks, the QoS-NSLP (rather than the NTLP)
is able to set the refresh timer value depending on the handover type
(e.g., make-before-break or break-before-make handovers ) or the
reservation style (e.g., pre-establishment or re-establishment) to
optimize the resources utilization. For example, in the
make-before-break handover, appropriate refresh time intervals are
able to be notified using the reserved field of REFRESH object, and
if the refresh time value is set to a little higher value than the
estimated handover latency, the MN can be provided with seamless QoS
service using the pre-reserved resources, and the resources which are
pre-reserved but unused will be timely released after handover [12].
After the state along a new path established, QNEs along the
signaling path may send refresh message to the neighboring peer node
before the expiration of refresh timer to only update the state
previously installed along the path or the changed flow ID along the
common path after the CRN discovery. In this case, the overhead
required to perform refreshes can be reduced, in similar way to that
proposed for RSVP [Refresh Reduction]: Refresh Reduction. Once a
RESPONSE message has been received indicating the successful
installation of a reservation, subsequent refreshing RESERVE messages
can simply refer to the existing reservation, rather than including
the complete reservation specification. For example, only the
Session_ID and the SII with no QSPEC at all are sent to just refresh
the state (e.g., reservation) previously installed and additionally
the changed flow ID with together those ID is only sent to update it
along the common path. Especially, the use of reduced refresh
messages over wireless channels or in access networks as well as in
core networks results in having the advantage of efficient
Lee, et al. Expires January 17, 2005 [Page 34]
Internet-Draft Applicability Statement July 2004
utilization of resources.
As mentioned in Section 3.1, in the mobility scenarios unlike the
route change, the end-to-end signaling problem according to the Path
Update gives rise to the deterioration of network performance such as
the signaling overhead, service blackout, and so on. To reduce
signaling latency in the Mobile IP-based scenarios, the NSIS protocol
suit needs to interwork with localized mobility management (LMM). If
the GIMPS/QoS-NSLP protocols operate over Hierarchical Mobile IPv6
and the CRN is discovered between an MN and MAP, the procedure of the
Path Update can be localized. However, it needs to be discussed
further how the Path Update is performed with scoped signaling
messages within the access network under the MAP.
In the inter-domain handover, additional latency occurs to perform
the NSIS signaling procedure including authentication and
authorization rather than that in the intra-domain handover. In this
case, a possible scenario for mitigation of the latency penalty may
be that the MN is multi-homed, or the NSIS protocols interact with
mobility protocols such as Seamoby protocols (e.g., CARD and CTP) and
FMIP. Another scenario is to use peering agreement which allows that
for an aggregate reservation, aggregation authorization is performed
once on an inter-domain link without the check of the authorization
of each individual session. However, those issues are still open how
those approaches can be used by the NSIS protocol suit.
6.4 Use cases of Identifiers
The current NTLP and QoS-NSLP drafts have defined important
identifiers including Session Identifier (SID), flow identifier,
signaling application identifier (NSLPID), Source Identification
Information (SII), Reservation Sequence Number (RSN), and so on.
These IDs are useful for different purposes in NSIS signaling.
When an NSIS signaling message (e.g., RESERVE) with an existing SID
and a different SII is received, an NE (e.g., QNE) knows its upstream
peer has changed. In mobile environments, the SID and SII can be
used to detect the CRN. For example, after the handover of an MN, if
an NE (e.g., QNE) on the data path receives an NSLP message (e.g.,
RESERVE) with an SID for which it already has state installed but
with a different SII, the QNE can determine that it is a merging
point (i.e., an NSLP CRN) of the old and new paths, accordingly,
involve state setup in the new path and teardown of the state on the
old path. However, if an NE (e.g., QNE) receives an NSIS message
(e.g., RESERVE) with a special flag (e.g., NO_REPLACE flag) set but
with the different SII, teardown of the state on the old path should
not happen. This may apply to a ping-pong type of handover where an
MN wishes to keep state to its old attachment point in case it moves
Lee, et al. Expires January 17, 2005 [Page 35]
Internet-Draft Applicability Statement July 2004
back there.
It is also possible to discover the CRN using message the routing
information (MRI) and SID at the GIMPS level. The MRI is used by
GIMPS in determining the correct next GIMPS hop for the signaling
message [2]. Whether the CRN is discovered by NTLP or NSLP is still
an open question. If the CRN is discovered using the MRI, the SII
may be redundant in terms of CRN discovery. In any case, the MRI
should be consistent with the SII.
The data flow will typically be classified by the flow identifier at
NEs. The flow identifier may change due to mobility. In this case,
it should be updated on the common path so that the data flow can get
necessary treatment.
The RSN may be useful in detecting duplicate messages in the mobile
environment. For example, it is possible for the MN to move to the
2nd NAR soon after being attached to the 1st NAR. In this case, an
NSIS node may receive the RESERVE message twice. The problem arises
without using RSN, when the RESERVE message from the 1st NAR arrives
later than the RESERVE message from the 2nd NAR.
Optionally, although a mobility object has not been defined in the
NTLP/NSLP drafts, it may be used to inform of the handover of an MN
or a route change [12] and therefore to expedite the CRN discovery.
The mobility object may be defined in the NTLP (e.g., in GIMPS
payload) or NSLP messages to notify of any mobility event explicitly,
and it may contain various mobility-related fields, e.g.,
mobility_event_counter and handover_init fields. The
mobility_event_counter field can be used to detect the latest
handover event to avoid any confusion about where to send a
confirmation message and to handle the ping-pong type of movement
described in Section 6.7. The handover_init field can be used to
explicitly inform that a handover is now initiated for fast state
re-establishment and to handle the invalid NR problem described in
Section 6.5.
6.5 Peer Failure Scenarios
A dead peer can occur either because a link or a network node, or
because the MN moved away without informing NSLP/NTLP (it is
recommended to link mobility- and NSIS signaling such that this does
not happen).
Dead peers of interest in mobility scenarios include CRN, MN, and AR.
In general, it is possible that only NSIS functions (i.e., NTLP/NSLP)
of the node may fail, or the physical hardware.
Lee, et al. Expires January 17, 2005 [Page 36]
Internet-Draft Applicability Statement July 2004
An MN may either fail or move. When it fails, it becomes a dead
peer. When it moves, it either retains or changes its IP address
(e.g., CoA). If it moves and changes its IP address without
notifying NSLP/NTLP, it also becomes a dead peer.
The failure of a (potential) NSIS CRN may result in incomplete state
re-establishment on the new path and incomplete teardown on the old
path after handover. In this case, a new CRN should be discovered
immediately by the CRN discovery procedure described above.
The failure or movement of an MN may cause the 'invalid NR' problem
[12] where the NR is the MN. If the MN moves, care should be taken
to prevent the teardown of NSIS state on the old path before the NSIS
state is re-established on the new path. In this case, an error
message should not be generated/sent to avoid any teardown on the old
path. It may be possible that the MN is not the NR, but a router in
the access network (possibly the AR) is proxying for the MN instead.
The failure of an AR may make the interactions with seamoby protocols
(such as CARD and CT) impossible. In this case, the neighboring peer
closest to the dead AR may need to interact with such protocols.
In any case, dead peers should be discovered fast to minimize service
interruption. The procedures for dead peer discovery (DPD) should be
the same no matter why a peer is dead, because an NE discovering a
dead peer cannot judge the specific reason. The procedures for DPD
should be handled by the NTLP. In fact, the DPD can be considered as
an extension to the GIMPS peer discovery. A peer discovery message
can be periodically transmitted to the neighboring peer (e.g.,
responding node in [2]), and the responding node can send a response
message. To determine if the peer is alive, the use of a timer may
be helpful. For example, the response message may need to be
received by the sender (e.g.,querying node in [2]) before the timer
expires. Otherwise, the responding node can be considered dead.
6.6 Guidelines for design of NTLP and NSLPs
(XF) My interpretion is: in this whole doc we emphasis on the
judging/stating whether/how current NTLP/NSLPs support mobility
scenarios. If we keep 6.6 here, we should keep it rather short and
avoid long description of new solutions. Or just a summary of which
features are not supported in current protoocls (and need to be taken
care) and general considerations for new NSLPs.
Lee, et al. Expires January 17, 2005 [Page 37]
Internet-Draft Applicability Statement July 2004
7. Security Considerations
This section describes authorization issues for mobility scenarios in
NSIS. It tries to raise additional questions beyond those discussed
in [13].
For the discussion of various authorization problems we assume that
initial authorization is strongly coupled to authorization handling
in subsequent message interactions. Making this assumption has some
implication to the signaling message behavior. It is certainly
possible that the entities who request the initial reservation or a
firewall pinhole and those who subsequently cause modifications are
not the same entities.
NSIS NSLPs define a flexible authorization scheme. As argued in [14]
it is necessary to consider cases where the sender, the receiver or
both are authorizing a reservation. For NAT and Firewall signaling
it is necessary that, the sender and the receiver, authorize the
creation of a NAT binding and the creation of a firewall pinhole.
Subsequently, we will consider the case where the mobile node acts as
a data sender followed by a discussion of the CN as a data sender.
7.1 MN as data sender
This section refers to Figure 2 where the MN acts as a data sender
which moves from one point of attachment to another.
This description starts with an initial flow setup triggered by the
MN which is also authorized by the MN.
7.1.1 MN is authorizing entity
This scenario considers the initial flow setup executed by the MN
whereby the MN provides authorization for the initial flow setup.
The initial setup might be used to create state for subsequent
authorization actions by the MN. It is obvious that the
authorization for the NSLP application (e.g., QoS NSLP) has to
provided. Depending on the underlying authorization model it might
be either peer-to-peer or end-to-middle. This authorization decision
can possibly be treated independent of the authorization issues
discussed in this section.
MN CN
------>----->------>------>------>------>------> +
ACTION (MN is authz) |
Lee, et al. Expires January 17, 2005 [Page 38]
Internet-Draft Applicability Statement July 2004
|
<-----<-----<------<------<------<------<------- | Flow
ACK | Setup
|
|
===============================================> +
Traffic
Figure 7: MN authorized initial reservation
The following questions seem to be interesting:
- Should the MN indicate that it is the authorizing entity for
subsequent actions to all entities along the path?
- What information should be used for this purpose?
- Who should add this information? Should the visited network of the
MN add something to the signaling message during the initial flow
setup?
- How do other entities along the path learn this information?
Next, the case for a mobile node authorizing the DCRN is considered.
This communication is illustrated in Figure 8.
The movement of the mobile node after the initial flow setup requires
authorization. Various session ownership authorization issues are
illustrated in [13].
MN DCRN CN
+ E.g.
------>----->------>------>------>------>------> | Movement
ACTION | with state
| creation at
<-----<-----<------<------<------<------<------- + new path
ACK
Figure 8: MN authorizes DCRN
The following questions are of interest:
- Why should the DCRN execute something on behalf of the MN? (i.e.,
why should it trust the MN and what information can the DCRN use
for verification?) As an example, the DCRN might delete state
along the old segment.
Lee, et al. Expires January 17, 2005 [Page 39]
Internet-Draft Applicability Statement July 2004
- Should the DCOR alone be able to start signaling (the DCOR might
be a designed node in some mobility protocols (e.g., MAP)) since
it is the node which has more information that other nodes based
on the mobility signaling protocols?
- How should other nodes between the MN and the DCRN and the nodes
between the DCNR and the CN know that the DCRN is now acting on
behalf of the MN?
The case of a corresponding node triggering an action is discussed.
shows the exchange graphically.
In this scenario the CN wants to, for example, tear-down a
reservation.
MN DCNR CN
<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +
TRIGGER | E.g.
| Tear
| Down
------>----->------>------>------>------>------> |
ACTION |
|
<-----<-----<------<------<------<------<------- +
ACK
Figure 9: CN triggers action
The following questions arise:
- Why should the MN trust the trigger?
- Is it possible to specify the security properties of the trigger
message in more detail? Is this an NSIS signaling message?
- The discussions about an indicator which entity to charge for the
reservation might be relevant (see [14]).
- Should the CN restrict the actions of the MN (e.g., delete,
update, create)? On the shared segment it might, for example, be
possible to restrict the allowed action to a flow identifier
update.
7.1.2 CN is authorizing entity
This scenario is similar to the CN triggering in Section 7.1.1. Two
Lee, et al. Expires January 17, 2005 [Page 40]
Internet-Draft Applicability Statement July 2004
slightly different protocol variations will be considered.
Authorizing some actions in the reverse data flow direction is more
difficult as it can easily be seen in Figure 10.
7.1.2.1 CN asks MN to trigger action (on behalf of the CN)
In Figure 10 the CN authorizes the MN to start signaling after, for
example, a movement. After receiving the trigger message (and some
authorization information) the mobile node starts signaling along the
new segment and automatically discovers the DCRN. The message
travels along the shared segment to the CN and updates the flow
identifier (if necessary). The MN might additionally allow the DCRN
to delete the reservation along the old segment.
MN DCRN CN
<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +
TRIGGER |
|
------>----->------>------>------>------>------> |
ACTION (CN is authz; MN on behalf of CN) |
+-----------------+ +-----------------+ |
| Action: | | Action: | |
| 'create' along)| | 'update' along)| |
| new segment) | | shared segment)| | Action
+-----------------+ +-----------------+ |
<------<------<------- |
+-----------------+ |
| Action: | |
| 'delete' along)| |
| old segment) | |
+-----------------+ |
<-----<-----<------<------<------<------<------- |
ACK |
|
|
===============================================> |
Traffic +
Figure 10: CN asks MN to trigger an action (on behalf of the CN)
The following questions need to be considered:
- How should the "delegation" mechanism work such that intermediate
nodes believe the MN that it is acting on behalf of the CN?
- Is it possible to carry this information with the trigger message
Lee, et al. Expires January 17, 2005 [Page 41]
Internet-Draft Applicability Statement July 2004
from the CN and the MN?
7.1.2.2 CN uses installed state to route message backwards
As a second variant the CN uses NSIS installed state to route a
signaling message backwards along the path. In some rare cases the
DCNR node might be known already. In this case it is possible to
stop the update process along the shared segment and to possibly mark
installed state along the old segment for deletion. When the MN
receives the message it again has to install state along the new
segment towards the DCOR. The mobile node might also trigger the
deletion of resources along the old segment together with this state
creation (pessimistic delete). An optimistic delete operation is
certainly more error prone.
MN DCNR CN
[ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> ] +
[ TRIGGER (e.g., MIP) ] |
|
------<-----<------<------<------<------<------< |
ACTION (CN is authz) |
+--------------------+ +-----------------+ |
| Action:optimistic | | Action: | |
| 'delete' along | | 'update' along)| |
| old segment) | | shared segment)| |
+--------------------+ +-----------------+ |
>------>------>----------->------>------>------- |
+-----------------+ ACK |
| Action: | | Action
| 'create' along)| |
| new segment) | |
+-----------------+ |
<------<------<------- |
+-------------------+ |
| Action:pessimistic| |
| 'delete' along) | |
| old segment) | |
+-------------------+ |
|
===============================================> |
Traffic +
Figure 11: CN uses installed state to route message backwards
Figure 11 raises a few questions:
Lee, et al. Expires January 17, 2005 [Page 42]
Internet-Draft Applicability Statement July 2004
The security properties of the trigger message need to be
evaluated.
It is not always possible to route signaling message backwards
from the CN to the MN:
- state at the new path might not be established (hence the
signaling message cannot travel backwards)
- the signaling message might not reach the MN via the old
segment.
In the multi-homing case where the mobile node can be reached via
more than one path it is possible to execute this exchange. The
same might be true for some local repair cases.
The messages triggered by the MN (namely create state along the
new segment and the pessimistic 'delete along the old segment)
still need to be executed on behalf of the CN. Compared to the
first variant there might be some room for optimization since the
first message was transmitted by the CN.
7.1.2.3 MN and CN are authorized
If we argue that the authorization at the NSLP layer is somehow tight
to the authorization for certain protocol actions then we also have
to consider the case where the MN and the CN have to contribute to
the authorization decision. This situation appears, for example, in
the NAT/Firewall signaling case but also in the area of QoS
reservation where both parties might need to share the cost of a
reservation.
If both end hosts are authorized then some signaling message
exchanges are less difficult since the trigger message does not need
to include authorization information. Some problems, however, do not
disappear such as the session ownership problem and additional
problems might be caused by certain solution approaches. Since this
section does not discuss solutions the reader is referred to the [13]
draft which lists a few strawman proposals for addressing the session
ownership problem.
7.1.3 CN as data sender
In this section we consider the scenarios where the CN acts as a data
sender. Figure 2 shows the topology and the participating entities.
7.1.3.1 CN is authorizing entity
Lee, et al. Expires January 17, 2005 [Page 43]
Internet-Draft Applicability Statement July 2004
This scenario is similar to the one described in Section 7.1.1. No
additional problems arise with a scenario where the CN is both data
sender and also the authorizing entity. In Figure 8 the CN
authorizes the UCNR to delete the old segment and to establish a new
reservation along the new segment. Furthermore, at the shared
segment only an update of the flow identifier might be necessary.
MN UCNR CN
+ E.g.
<-----<-----<------<------<------<------<------- | Create
ACTION | new
+-----------------+ | +-----------------+ | State
| Action: | | | Action: | |
| 'create' along)| | | 'update' along)| |
| new segment) | | | shared segment)| |
+-----------------+ | +-----------------+ |
<------<------<--------+ |
+-----------------+ |
| Action: | |
| 'delete' along)| |
| old segment) | |
+-----------------+ |
|
>----->----->------>------>------>------>------> |
ACK (along new path) |
|
<=============================================== +
Traffic
Figure 12: CN as data sender is authorized
Since the mobile node first detects the route change. A trigger to
the CN allows the CN to quickly react on the route change. There are
three variants:
- The MN sends a trigger to the CN and the CN starts signaling as
shown in Figure 12.
- The MN routes the message back along the reverse path using the
previously established state along the old route. This mechanism
only works if the MN is able to send messages along the old path.
As a generic mechanism this is not suggested.
- An intermediate node act on its own. This might be possible that
the UCRN is an entity which participates in the mobility signaling
(e.g., Mobility Anchor Point (MAP)) exchange. Depending on the
Lee, et al. Expires January 17, 2005 [Page 44]
Internet-Draft Applicability Statement July 2004
message exchange it needs to be studied whether the signaling
message provides sufficient authorization to trigger the NSIS
exchange.
7.1.3.2 MN is authorizing entity
In this scenario we consider the case where the CN is the data sender
but the MN authorizes actions. The considerations are similar to
those elaborated in Section 7.1.3 where the MN is the data sender but
the CN is the authorizing entity.
7.1.4 Multi-homing Scenarios
Multi-homing scenarios have the property that the more than one path
belongs to a signaling session. In Figure 13 the MN uses two
interfaces to route NSIS message towards the CN. The two individual
sessions are tight together with the same session identifier. The MN
needs to indicate that both reservations need to be kept alive (and
the DCRN should not delete a reservation). At the shared segment
only a single reservation is stored.
From an authorization point of view the session ownership issues is
applicable since the DCRN needs to merge the two reservations into a
single one along the shared segment.
7.1.4.1 MN as data sender
This section shows the multi-homing scenario with the MN as a data
sender.
segment 2
+---+
^>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>V
^ +---+ V
+----+ +----+ +--+
| MN | |DCNR|>>>>>>>>>>|CN|
|UCNR| | |>>>>>>>>>>| |
+----+ +----+ +--+
v +---+ ^ shared
v>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>^ segment
+---+
segment 1
===============================================================>
Traffic
Figure 13: Multi-homed MN as data sender
Lee, et al. Expires January 17, 2005 [Page 45]
Internet-Draft Applicability Statement July 2004
If the MN is the authorizing entity then the session ownership
problem needs to be solved. Without solving this type of
authorization problem it is possible for an adversary to "join" the
reservation at the shared segment. Furthermore, it is an open issue
whether reservation merging is allowed only for cases where one flow
identifier is used at different interfaces or even with different
flow identifiers.
If the CN is the authorizing entity then, again, some message needs
to be sent from the CN to the MN to trigger the exchange or to route
the request backwards along the established path. The MN is
reachable via the two paths.
Mobility handling might be smoother since it is possible that only
one interface experiences an IP address change with all the
previously discussed implications.
7.1.4.2 CN as data sender
This section shows the multi-homing scenario with the CN as a data
sender. The scenario is simpler (for the CN authorizing case) than
the one described in Section 7.1 since the signaling message along
the shared segment travels the previously established path. It shows
some similarities with a route change scenario. At the mobile node
itself the two paths merge which again leads to a session ownership
problem. How should the MN know whether a signaling message with the
same session identifier hitting a different interface belongs to the
indicated session authorized by the CN?
If the MN is the authorizing entity then again communication between
the end hosts is required as a trigger. Routing the signaling
messages in the reverse path might, in some cases, also be possible.
segment 2
+---+
v<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<<^
v +---+ ^
+----+ +----+ +--+
| MN | |UCRN|<<<<<<<<<<|CN|
|DCRN| | |<<<<<<<<<<| |
+----+ +----+ +--+
^ +---+ v shared
^<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<<v segment
+---+
segment 1
<=============================================================
Lee, et al. Expires January 17, 2005 [Page 46]
Internet-Draft Applicability Statement July 2004
Traffic
Figure 14: Multi-homed CN as data sender
7.1.5 Proxy Scenario
The proxy scenarios refers to those cases where one of the end hosts
or even both end hosts are not NSIS aware. Two security implications
need to be studied:
- First, there is an authorization issue with regard to the NSLP
application. For QoS signaling the end host (and the user) has to
authorize the QoS reservation since the reservation might require
the user is charged for it. Since the end host is not NSIS aware
some other mechanism or protocol needs to be available with
provides this functionality. For NAT/Firewall signaling delayed
authorization assures that both end hosts authorize the packet
filter creation at their local networks (particularly in case of
missing trust relationship between intermediate networks).
- Second, the authorization issues which relate to the session
ownership problem also need to be studied. Since the session
ownership issues are a related to the signaling participating
nodes and not to the users or the true end points we think that it
does not lead to complications. This is, however, only true if we
assume that authorization at the NSLP and authorization decisions
for the signaling message handling is decoupled.
7.1.6 Conclusion
This section tries to point to some authorization aspects for NSIS
signaling in a mobility environment. Performance is important in
mobility environments but a proper security handling accounts for a
high percentage of the total performance. It is important to
consider this aspect in the analysis of mobility proposals.
From the scenarios we can observe the following issues:
- Signaling in the direction of the data path is simpler than in the
opposite direction.
- There are many similarities between the scenarios where the MN
acts as a data sender and the scenarios the CN acts as a data
sender, particularly if multi-homing scenarios are included.
- Many authorization problems arise after the initial setup of
resources along the path. This problem can be stated as: "Is an
Lee, et al. Expires January 17, 2005 [Page 47]
Internet-Draft Applicability Statement July 2004
entity allowed to perform the indicated action?" Only a few
problems are related to the initial signaling message exchange.
- If the data sender triggers the signaling message exchange and
also provides authorization then the complexity can be kept fairly
low.
- NSLP authorization decisions should be treated separately from
authorization decisions which affect the signaling message
exchange.
During the work a few open issues have been selected:
- This section does not consider the different message types.
- The implication of price determination caused by mobility is
excluded from this description.
- It was tried to keep the description in this section very generic.
Implications of certain mobility protocols are therefore not
considered.
Lee, et al. Expires January 17, 2005 [Page 48]
Internet-Draft Applicability Statement July 2004
8. Open Issues
This section highlights some issues which may need further discussion
in the future.
8.1 Interaction with Other Mobility-Related Protocols
8.1.1 Interaction with Seamoby Protocols
The NSIS protocol suite should be able to operate independently of
Seamoby protocols such as Context Transfer Protocol (CTP) and
Candidate Access Router Discovery (CARD). However, significant
performance gains can be achieved if NSIS signaling can interact with
such protocols. For example, with the help of CARD and CTP, NSIS
signaling can quickly re-establish the NSIS state on the new path by
reducing the state re-setup delay. However, making use of the CARD
and CT protocols requires the ability from NTLP/NSLP to do (at that
stage) off-path signaling on-behalf of the MN; this has implications
on the authorization of signaling.
For efficient interaction between NSIS and Seamoby protocols, it is
desirable to select the optimal NSIS-aware candidate access router
(CAR) and to transfer NSIS state information fast between the old and
new access routers to avoid reestablishing the state from the
beginning.
If NSIS is not able to interact with CARD/CTP for some reason, it may
be desirable to discover the CAR by using a CAR discovery mechanism
which can be an extension to the NTLP peer discovery, and to check
whether necessary resources are available on the new candidate path
before handover is completed. However, this will also cause off-path
signaling.
8.1.2 Interaction with Local Mobility Management Protocols
Localized mobility management [LMM] mechanisms reduce the latency in
mobility management signaling upon Care of Address change. These
schemes, such as fast handover [15] and hierarchical mobile IPv6
[HMIPv6], complicates NSIS signaling, for example, by associating new
scoped care-of-addresses for a mobile node, and introducing one or
more IP-in-IP encapsulated segment(s) in the path traversed by the
communicating traffic. The additional CoA and IP-in-IP tunnels have
implications for both the NTLP and NSLP.
Whenever a mobility protocol changes characteristics in any place for
the flow, NSIS signaling should be able to react accordingly as soon
as possible. However, an overall coordination/synchronization needs
further study.
Lee, et al. Expires January 17, 2005 [Page 49]
Internet-Draft Applicability Statement July 2004
8.1.3 State Establishment in Network Mobility Scenarios
The solutions in the nemo WG will support preservation of route
aggregation in the network when flows of MNs (and/or fixed hosts) in
a mobile network are sent to the same CN. In this case, aggregate
state installation, e.g., for aggregate reservation (or group
reservation), should be considered to guarantee resources along the
aggregated path between the mobile router of the mobile network and
the CN. From NSIS perspective, to deal with aggregate state
installation in such a situation, problems caused by the nested
mobile network and various scenarios for network mobility, should be
examined.
8.2 Additional Issues on CRN discovery and Path Update
The CRN discovery may be initiated before the handover is completed
for optimal performance. To do this, an efficient mechanism may be
needed to find a potential CRN as fast as possible. In this case,
seamoby protocols such as CARD and CTP may be involved.
The state update in the control plane on the shared/common path to
reflect the changed flow identifier brings issues on the end-to-end
signaling. Although the state update does not cause re-processing of
AAA and admission control, it leads to the signaling overhead.
When NSIS operates together with HMIPv6 and a MAP is an NSIS-aware
node, the CRN can be discovered in the local region. How to discover
the CRN in such an environment is an open question.
8.3 Support for the Ping-Pong Type of Movement
NSIS signaling to release resources on the old path should be done as
quickly as possible to avoid waste of resources. When the route
change occurs in the mobile access network where resources are
scarce, it is inefficient to wait until the soft-state timer expires.
However, immediate release of resources along the old path may not be
desirable in some cases. For example, in case of a ping-pong type of
movement, the immediate release of state on the old path should be
avoided so that resources along the old path can be reused after a
short period of time. The current QoS-NSLP draft has defined
NO-REPLACE flag which can be used to support such a ping-pong type of
movement.
8.4 When both end-hosts are mobile
It is possible that both end hosts are mobile devices. Therefore,
signaling between two mobile devices should be considered. Until
now, we are assuming a non-mobile correspondent node. Problems can
Lee, et al. Expires January 17, 2005 [Page 50]
Internet-Draft Applicability Statement July 2004
show up if both devices start to signal at the same time.
8.5 Bi-directional State Establishment
Although the bidirectional data flows have the same end points, the
paths in the two directions do not need to be the same. Therefore,
the CRN of the downstream path may be different from that of the
upstream path in mobile scenarios. As a matter of course, the
Session ID in the downstream reservation should be different from
that of the upstream reservation. If the routes (i.e., upstream and
downstream paths) are symmetric, an NSIS single signaling message can
be used to install state in both directions. If the routes are
asymmetric, an NSIS signaling message from the originator (e.g., MN
or CN) can trigger an independent signaling message from the
responder.
Bi-directional reservations can be considered as a special case of
fate sharing. The current QoS-NSLP has defined BOUND_SESSION_ID
which can be used to relate bidirectional flows to each other. Since
BOUND_SESSION_ID can also be used to support aggregate reservation,
care should be taken when both the bidirectional reservation and the
aggregate reservation are supported at the same time.
8.6 Priority Reservation
The QoS-NSLP draft [11] defines a Priority object in the QSPEC
template. In mobile environments, priority of certain signaling
messages over others may be required when a message loss during call
set-up is less harmful than during handover. Priority of certain
reservations over others may be required when QoS resources are
oversubscribed. In that case, existing reservations may be preempted
in other to make room for new higher-priority reservations e.g., to
support handover. Although supportfor the reservation priority is a
QoS model specific issue, it may be useful to support a call which
needs a certain amount of resources immediately after handover of an
MN.
8.7 Aggregation of End-to-End Flows in Mobile Environments
Session binding defined in the QoS-NSLP draft [11] can be used to
support aggregation. An aggregated session may have a different flow
ID from the end-to-end message sent or received by an MN. Including
the BOUND_SESSION_ID object in a session indicates a dependency
relation. By default, a session that is bound to another session
with the BOUND_SESSION_ID object shares fate with it. In mobile
environments where a route change due to mobility occurs, an
end-to-end flow may need to be bound to a new aggregate flow which is
different from the current one due to route change. Therefore, it
Lee, et al. Expires January 17, 2005 [Page 51]
Internet-Draft Applicability Statement July 2004
may be desirable to re-setup session binding as quickly as possible.
Lee, et al. Expires January 17, 2005 [Page 52]
Internet-Draft Applicability Statement July 2004
9. References
9.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
9.2 Informative References
[2] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol
for Signaling", draft-ietf-nsis-ntlp-02 (work in progress),
June 2004.
[3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[4] Hancock, R., "Next Steps in Signaling: Framework",
draft-ietf-nsis-fw-06 (work in progress), July 2004.
[5] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[6] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-02 (work in progress), May
2004.
[7] Fessi, A., "Security Threats for the NAT/Firewall NSLP",
draft-fessi-nsis-natfw-threats-00 (work in progress), May 2004.
[8] Tschofenig, H., "Path-coupled NAT/Firewall Signaling Security
Problems", draft-tschofenig-nsis-natfw-security-problems-00
(work in progress), July 2004.
[9] "IP Mobility Support for IPv4, revised",
draft-ietf-mip4-rfc3344bis-00 (work in progress), July 2004.
[10] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[11] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-03
(work in progress), May 2004.
[12] Lee, S., "Mobility Functions in the QoS-NSLP",
draft-lee-nsis-mobility-nslp-01 (work in progress), November
2003.
Lee, et al. Expires January 17, 2005 [Page 53]
Internet-Draft Applicability Statement July 2004
[13] Tschofenig, H., "Security Implications of the Session
Identifier", draft-tschofenig-nsis-sid-00 (work in progress),
June 2003.
[14] Tschofenig, H., "NSIS Authentication, Authorization and
Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 (work
in progress), March 2003.
[15] Dommety, G., "Fast Handovers for Mobile IPv6",
draft-ietf-mobileip-fast-mipv6-05 (work in progress), October
2002.
Authors' Addresses
Sung-Hyuck Lee
SAMSUNG Advanced Institute of Technology
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9585
EMail: starsu.lee@samsung.com
Seong-Ho Jeong
Hankuk University of FS
89 Wangsan Mohyun
Yongin-si, Gyeonggi-do 449-791
KOREA
Phone: +82 31 330 4642
EMail: shjeong@hufs.ac.kr
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
Munich, 81739
Germany
Phone:
EMail: Hannes.Tschofenig@siemens.com
Xiaoming Fu
University of Goettingen
Telematics Group
Lee, et al. Expires January 17, 2005 [Page 54]
Internet-Draft Applicability Statement July 2004
Lotzestr. 16-18
Goettingen 37083
Germany
EMail: fu@cs.uni-goettingen.de
Jukka Manner
Department of Computer Science University of Helsinki
P.O. Box 26 (Teollisuuskatu 23)
HELSINKI, FIN-00014
Finland
Phone: +358-9-191-44210
EMail: jmanner@cs.helsinki.fi
Roland Bless
Institute of Telematics, Universitaet Karlsruhe (TH)
Zirkel 2
76128 Karlsruhe
Germany
EMail: bless@tm.uka.de
Paulo Mendes
DoCoMo Communications Laboratories Europe GmbH
Landsberger Str. 312
80687 Munich, Germany
Voice: +49-89-56824-226
Fax: +49-89-56824-300
E-mail: mendes@docomolab-euro.com
Robert Hancock
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
Voice: +44-1794-833601
Fax: +44-1794-833434
E-Mail: robert.hancock@roke.co.uk
Lee, et al. Expires January 17, 2005 [Page 55]
Internet-Draft Applicability Statement July 2004
Appendix A. Acknowledgements
The authors would like to thank Jongho Bang, Cornelia Kappler,
Byoung-Joon Lee, Henning Schulzrinne, and Charles Q. Shen for
significant contributions in four earlier drafts and the previous
draft.
Lee, et al. Expires January 17, 2005 [Page 56]
Internet-Draft Applicability Statement July 2004
Appendix B. Anticipated Handover
With an anticipated handover, state in the new path can be set in
advance, which means before the MN gets any layer 3 connectivity to
the new access router. Anticipated handovers require the discovery
of candidate access points or access routers (CARD may help), and the
ability of the MN to trigger the signaling to set up the new path via
the old access router. If the sender is moving, the old access
router may directly signal to the candidate access router. However,
the new path up to/from the CRN must be also figured out which is
especially not that easy in case the MN is acting as receiver. In a
QoS scenario, an anticipated handover checks resource availability
along a potential new path before an MN actually changes its point of
attachment. Therefore, if there are not enough resources available
along the new path an unsuccessful handover (or period of QoS
degradation) can be avoided and the MN can stay connected to its
current point of attachment (if possible).
Anticipated handovers offer mainly two advantages:
- reducing seamless handover latency, because most signaling to set
up resources in the new path is carried out in advance.
- avoiding unsuccessful handovers or unnecessary periods of QoS
degradation.
The first point is especially important in inter-domain handover
scenarios where signaling procedures will take longer and additional
time consuming authentication procedures may be necessary. On the
other hand, the higher resource consumption may be considered as
disadvantage if resources along the new path could be reserved
successfully, but the old path is still used (dual reservation after
split or merge CRN). However, an indication for handover completion
(thereby triggering release of the obsolete path) may help to keep
this period as short as possible.
To perform an anticipated handover, MNs do not have to be
multi-homed. However, anticipated handovers may involve some kind of
NSIS proxy [2] on the new access network to signal on the new path on
behalf of the MN. If we assume that the end-to-edge communication is
done between the MN and its access router, some study is required to
determine how to signal between the MN's current access router and
the NSIS proxy in the new access network, e.g., how to discover the
most suitable NSIS proxy, and to establish a communication between
access networks. The latter issue involves out-of-path signaling.
Moreover, in some anticipated signaling scenarios, NSIS signaling
cannot be triggered by the mobility protocol, which requires some
Lee, et al. Expires January 17, 2005 [Page 57]
Internet-Draft Applicability Statement July 2004
study about other possible triggers, such as:
- Cross-layer triggering. For instance, the layer-2 mechanism can
give some information about a possible movement.
- Context-awareness triggering. For instance, information about a
lower traffic load in some neighbor access networks can trigger
the establishment of state in a new path.
It follows a conceptual description of a signaling exchange of an
anticipated handover for resource reservation.
In this scenario, we assume the sender is moving.
- The MN must discover candidate access points or routers and signal
its current AR to initiate an anticipated handover.
- The current AR has to discover its corresponding signaling peer,
usually the candidate AR. This may be accomplished with similar
techniques like CARD, e.g., by learning addresses from moving
nodes. Different domains may exchange corresponding information
due to roaming agreements.
- A new signaling association must be setup between the current AR
and the candidate AR.
- The current AR signals a request for an anticipated handover to
the candidate AR. The candidate AR sets up a new reservation
state along the new path downstream. The session id should be
used in order to allow the crossover node CRN to discover the
handover process. In case reservation parameters are not changed,
signaling can stop at the CRN, which will then generate a response
that is sent back to the candidate AR. Otherwise signaling along
the unchanged path may also be required in order to prepare the
intended changes.
- The candidate AR forwards the result of the new path setup to the
current AR. The new reservation should be removed automatically
by using timers if the handover is not performed by the MN within
a certain period (it never shows up at the CAR).
- The candidate AR forwards the result of the new path setup to the
current AR. The new reservation should be removed automatically
by using timers if the handover is not performed by the MN within
a certain period (it never shows up at the CAR).
Lee, et al. Expires January 17, 2005 [Page 58]
Internet-Draft Applicability Statement July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lee, et al. Expires January 17, 2005 [Page 59]
| PAFTECH AB 2003-2026 | 2026-04-22 21:24:12 |