IETF Next Steps in Signaling S. Lee, Ed.
Internet-Draft Samsung AIT
Expires: April 18, 2005 S. Jeong
HUFS
H. Tschofenig
Siemens AG
X. Fu
Univ. of Goettingen
J. Manner
Univ. of Helsinki
October 18, 2004
Applicability Statement of NSIS Protocols in Mobile Environments
draft-ietf-nsis-applicability-mobility-signaling-00.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 April 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The 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 April 18, 2005 [Page 1]
Internet-Draft Applicability Statement October 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. Requirements Notation and Terminology . . . . . . . . . . . . 4
3. Problem Statement and General Considerations . . . . . . . . . 7
3.1 Problem statement . . . . . . . . . . . . . . . . . . . . 7
3.2 General considerations . . . . . . . . . . . . . . . . . . 9
4. Basic Operations for Mobility Support . . . . . . . . . . . . 10
4.1 Generic route changes and mobility . . . . . . . . . . . . 10
4.2 CRN discovery . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1 Possible approaches for CRN discovery . . . . . . . . 13
4.2.2 The identifiers for CRN discovery . . . . . . . . . . 14
4.2.3 The procedure of CRN discovery . . . . . . . . . . . . 16
4.3 Path update . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1 State setup and update . . . . . . . . . . . . . . . . 17
4.3.2 State teardown . . . . . . . . . . . . . . . . . . . . 19
5. Mobility-Related Issues with NSIS Protocols . . . . . . . . . 20
5.1 Specific issues with NTLP . . . . . . . . . . . . . . . . 20
5.2 Specific issues with QoS-NSLP . . . . . . . . . . . . . . 21
5.3 Specific issues with NAT/FW NSLP . . . . . . . . . . . . . 23
5.4 Common issues related to NTLP and NSLP . . . . . . . . . . 24
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 24
6.1 Support for macro mobility-based scenarios . . . . . . . . 24
6.1.1 Implications to Mobile IP-related scenarios . . . . . 25
6.1.1.1 Mobile IPv4-specific issues . . . . . . . . . . . 27
6.1.1.2 Mobile IPv6-specific issues . . . . . . . . . . . 29
6.2 Multihoming scenarios . . . . . . . . . . . . . . . . . . 31
6.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 31
6.2.2 Some examples of NTLP/NSLP support . . . . . . . . . . 31
6.3 QoS performance considerations in mobility scenarios . . . 32
6.4 Use cases of identifiers . . . . . . . . . . . . . . . . . 34
6.5 Peer failure scenarios . . . . . . . . . . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37
7.1 MN as data sender . . . . . . . . . . . . . . . . . . . . 37
7.1.1 MN is authorizing entity . . . . . . . . . . . . . . . 37
7.1.2 CN is authorizing entity . . . . . . . . . . . . . . . 39
7.1.2.1 CN asks MN to trigger action (on behalf of the
CN) . . . . . . . . . . . . . . . . . . . . . . . 40
7.1.2.2 CN uses installed state to route message
backwards . . . . . . . . . . . . . . . . . . . . 41
7.1.2.3 MN and CN are authorized . . . . . . . . . . . . . 42
7.1.3 CN as data sender . . . . . . . . . . . . . . . . . . 42
7.1.3.1 CN is authorizing entity . . . . . . . . . . . . . 42
7.1.3.2 MN is authorizing entity . . . . . . . . . . . . . 44
Lee, et al. Expires April 18, 2005 [Page 2]
Internet-Draft Applicability Statement October 2004
7.1.4 Multi-homing Scenarios . . . . . . . . . . . . . . . . 44
7.1.4.1 MN as data sender . . . . . . . . . . . . . . . . 44
7.1.4.2 CN as data sender . . . . . . . . . . . . . . . . 45
7.1.5 Proxy Scenario . . . . . . . . . . . . . . . . . . . . 46
7.1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . 46
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 47
8.2 Informative References . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 48
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 49
Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . 51
Lee, et al. Expires April 18, 2005 [Page 3]
Internet-Draft Applicability Statement October 2004
1. Introduction
The mobility of IP-based nodes incurs route changes, usually at the
edge of the network. Route changes 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, and
each specific service has its own NSLP protocol.This draft also
discusses how the NSIS protocols should work in various mobility
scenarios.
This draft 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. More complex scenarios and issues of interworking with
various mobility-related protocols, such as Seamoby and local
mobility management protocols, are left for future work.
2. Requirements Notation and 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 direction from a data sender towards the destination.
O Upstream
The direction from a data destination towards the sender.
O Crossover Node (CRN)
Lee, et al. Expires April 18, 2005 [Page 4]
Internet-Draft Applicability Statement October 2004
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
corresponding 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 an NTLP CRN and/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 changes and mobility
in forming CRN according to the direction of signaling flows
followed by data flows
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 (UCRN), 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 (DCRN), 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.
Lee, et al. Expires April 18, 2005 [Page 5]
Internet-Draft Applicability Statement October 2004
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 the mobility management point of view, mobility CRN is the
node where the old and new paths (physically) merge. Note that
in general, the mobility CRN may be different from the NSLP CRN
or NTLP CRN.
Routing CRN is the node where the old and new paths (rather
physically) merge using normal routing. 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
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 mobility 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
Lee, et al. Expires April 18, 2005 [Page 6]
Internet-Draft Applicability Statement October 2004
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 or 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.
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 in mobile environments is
typically much faster and more 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
Lee, et al. Expires April 18, 2005 [Page 7]
Internet-Draft Applicability Statement October 2004
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 segments
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 addresses
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
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, so 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
Lee, et al. Expires April 18, 2005 [Page 8]
Internet-Draft Applicability Statement October 2004
remains as it is after re-establishing the state along the new
path due to mobility (or route changes), 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 mobile environments.
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
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 will be left for future work.
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
Lee, et al. Expires April 18, 2005 [Page 9]
Internet-Draft Applicability Statement October 2004
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.
4. Basic Operations for Mobility Support
In this section, we discuss the basic operations of NSIS signaling
needed after route changes including 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. Although Section 4.1 describes
basic differences between the generic route changes and mobility,
this draft mainly focuses on 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,
or a 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 changes 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
Lee, et al. Expires April 18, 2005 [Page 10]
Internet-Draft Applicability Statement October 2004
results in difference according to the types of route changes (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| ------^
+---+ +---+
=======(downstream signaling followed by data flows) ========>
(a) The topology for downstream NSIS signaling flow after
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
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
Lee, et al. Expires April 18, 2005 [Page 11]
Internet-Draft Applicability Statement October 2004
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)
====(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.
These topological changes caused by mobility make the signaling state
established on the old path useless and therefore it should be
removed (in the end). In addition, the existing NSIS state should
Lee, et al. Expires April 18, 2005 [Page 12]
Internet-Draft Applicability Statement October 2004
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 to 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 end point, 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
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 CRN discovery, 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
Lee, et al. Expires April 18, 2005 [Page 13]
Internet-Draft Applicability Statement October 2004
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
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
Lee, et al. Expires April 18, 2005 [Page 14]
Internet-Draft Applicability Statement October 2004
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
(NSLP_ID-flow_direction (D or U)-br_counter_No). 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 changes as shown in Figure 3 (a).
Old path
+-----+ +-----+
^---->|NSLP1| ... |NSLP1| ----V
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 | B | 2-D-#1|
| {IP-#X, IP-#V, | | | | | |
| protocol, ports} | | | | | 2-U-#1|
+------------------+-------+-------+--------+------------+-------+
(b) Routing state table at node A (NSLP CRN)
Lee, et al. Expires April 18, 2005 [Page 15]
Internet-Draft Applicability Statement October 2004
+------------------+-------+-------+----------+----------+-------+
| Message Routing |Session| NSLP |Upstream |Downstream| NSLP |
| Information | ID | ID | Peer | Peer |Br. ID |
+------------------+-------+-------+----------+----------+-------+
| Method = Path | 0xABCD| NSLP1 |Pointer to| O | 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 | Pointer | 2-D-#1|
| {IP-#X, IP-#V, | | | | to N-R | |
| protocol, ports} | | | | | 2-U-#1|
+------------------+-------+-------+----------+----------+-------+
(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 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 a new 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 for the node to realize it is CRN:
- 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).
Lee, et al. Expires April 18, 2005 [Page 16]
Internet-Draft Applicability Statement October 2004
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 as shown in Figure 3 (c) 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,
the UCRN should be the node (closet to the MN) where the signaling
flow begins to logically diverge: it is similar to the creation of
the routing table of node A as shown in Figure 3 (b) 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.
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 (see Section 6.2). In this case, NSIS signaling for the
Lee, et al. Expires April 18, 2005 [Page 17]
Internet-Draft Applicability Statement October 2004
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
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).
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
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 should be shared for flows with
different flow identifiers.
Lee, et al. Expires April 18, 2005 [Page 18]
Internet-Draft Applicability Statement October 2004
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-initiated reservation
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
Lee, et al. Expires April 18, 2005 [Page 19]
Internet-Draft Applicability Statement October 2004
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 at the GIMPS layer [2].
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 IDs 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
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.
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 changes, updating its own
routing state consistently, and informing NSLPs at affected nodes.
Lee, et al. Expires April 18, 2005 [Page 20]
Internet-Draft Applicability Statement October 2004
In mobile environments, for an end-to-end signaling flow, its
signaling path can be changed upon a successful Mobile IP
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 changes. 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 changes 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 changes,
thus an NTLP implementation needs to interact with mobility
registration carefully.
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 (or while) 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 should QoS-NSLP signaling be initiated after mobility?
Lee, et al. Expires April 18, 2005 [Page 21]
Internet-Draft Applicability Statement October 2004
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? 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 (or the mobility identifer) 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 to 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
multihomed interfaces (see Section 6.2). 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 in 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) performs handover before the receipt of the
message? If RESERVE (for refresh) 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
Lee, et al. Expires April 18, 2005 [Page 22]
Internet-Draft Applicability Statement October 2004
- 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 changes, 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 (for example, refresh
reduction) and dead peer are discussed further in Section 6, The
advanced features such as bi-directional reservation, aggregation
reservation, session binding, layering, peer agreement, and so on
will be future work and the second part of mobility discussion.
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 up-to-date.
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.
Lee, et al. Expires April 18, 2005 [Page 23]
Internet-Draft Applicability Statement October 2004
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], [6] and [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 NTLP 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 [2]. 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 changes. 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
changes 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.
6. Applicability Statement
6.1 Support for macro mobility-based scenarios
This section considers how NSIS protocols should 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 continually 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
corresponding service (e.g., QoS) to one. The signaling procedure
results in creating a new NSIS branch along the new path through
Lee, et al. Expires April 18, 2005 [Page 24]
Internet-Draft Applicability Statement October 2004
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
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, and those interaction
also needs to be notified to all NSLPs by the API between GIMPS and
Lee, et al. Expires April 18, 2005 [Page 25]
Internet-Draft Applicability Statement October 2004
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 appropriate 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 rather 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 mobility 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
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. In this case, the change
of CoA needs to be checked. 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.
Lee, et al. Expires April 18, 2005 [Page 26]
Internet-Draft Applicability Statement October 2004
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
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
Lee, et al. Expires April 18, 2005 [Page 27]
Internet-Draft Applicability Statement October 2004
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 5 (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
path from the FA to the HA as shown in Figure 5 (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 5 (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
Lee, et al. Expires April 18, 2005 [Page 28]
Internet-Draft Applicability Statement October 2004
discovery and the Path Update is equal to the case for FA CoA
above (as shown in Figure 5 (a)) except that in case of using the
reverse tunnel. That is, the NSIS state may be established along
the reverse tunneling path from the MN to the HA as shown in
Figure 5 (C).
- For upstream signaling flow, the NSIS signaling for the UCRN
discovery and the Path Update is also equal to the case for FA CoA
above (as shown in Figure 5 (d)) except the end of point of
tunneling path. That is, the NSIS state may be established along
the tunneling path from the HA to the MN as shown in Figure 5
(e).
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
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.1.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), respectively. 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):
Lee, et al. Expires April 18, 2005 [Page 29]
Internet-Draft Applicability Statement October 2004
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
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
Lee, et al. Expires April 18, 2005 [Page 30]
Internet-Draft Applicability Statement October 2004
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 scenarios
6.2.1 Overview
A host that is an initiator or responder of signaling messages may be
not only mobile but also multi-homed. When considering current
activities in the Multi6 and HIP WGs, multi-homed hosts and scenarios
may be common in the future IPv6-based Internet. Such scenarios may
include load balancing where multiple connections to different
providers are used simultaneously. In this case, the multi-homed MN
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.
The term "seamless mobility" is often referred to mean that the MN is
able to keep an ongoing session seamlessly (without experiencing
perceivable service 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.
The former requires the MN to keep the old path, while data is
received over the new path. This approach is possible if the MN is
multi-homed.
Other possible scenarios may include bi-casting, bandwidth increase,
etc.
6.2.2 Some examples of NTLP/NSLP support
NTLP uses an endpoint address (e.g., CoA) to install message routing
state. In multi-homed MN scenarios, there can be multiple CoAs for
the MN, and therefore an appropriate CoA should be selected to
establish NSIS state between the MN and CN. If the multi-homed MN
has multiple network interfaces, each network interface may use a
different CoA. To find a feasible signaling path, multiple NSIS
messages (e.g., multiple QUERY messages) may be sent from the MN to
Lee, et al. Expires April 18, 2005 [Page 31]
Internet-Draft Applicability Statement October 2004
the HA or CN (in case of route optimization), the HA or CN may decide
which one to choose based on some criteria (e.g., resource
availability). According to the decision, the HA or CN could send a
signaling message (e.g., RESERVE) for further action.
In case of handover where the new CoA for an MN introduced in Mobile
IP has to invoke a change of message routing state, both new and old
addresses can be valid during a certain period of time, and the new
data path may co-exist with the old one. It is theoretically
possible to perform certain NSIS state update on 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.
When there is a need for inter-domain handover, additional delay may
be caused 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.
For load balancing, NSIS may need to install NSIS state along
multiple paths. In this case, multiple NSIS messages (e.g., multiple
QUERY messages) could be sent to the remote endpoint to establish
NSIS state although the sender is the same MN. In this way, multiple
paths for load balancing can be set up between the same ends.
A more detailed analysis of the NTLP/NSLP functionality in different
multihomed scenarios (e.g., including load balancing, moving
multi-home MN, bi-casting, etc.) will be presented in the next
version.
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 NSIS signaling in dynamic environment
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) in various handover scenarios may be alleviated by the
procedure of the CRN discovery and the Path Update described in
Section 4. However, we need to take into consideration how the
resource utilization of the NSIS signaling flow itself can be
Lee, et al. Expires April 18, 2005 [Page 32]
Internet-Draft Applicability Statement October 2004
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
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
Lee, et al. Expires April 18, 2005 [Page 33]
Internet-Draft Applicability Statement October 2004
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 IDs 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
utilization of resources.
As mentioned in Section 3.1, in the mobility scenarios unlike the
route changes, 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
Lee, et al. Expires April 18, 2005 [Page 34]
Internet-Draft Applicability Statement October 2004
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
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. However, the SII may be redundant in terms of CRN
discovery if the CRN is discovered using the MRI,. 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 changes [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.
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 failed,
or because the MN moved away without informing NSLP/NTLP (it is
Lee, et al. Expires April 18, 2005 [Page 35]
Internet-Draft Applicability Statement October 2004
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.
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. A
more detailed analysis of interactions with Seamoby protocols is
future work.
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.
Lee, et al. Expires April 18, 2005 [Page 36]
Internet-Draft Applicability Statement October 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.
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?
Lee, et al. Expires April 18, 2005 [Page 37]
Internet-Draft Applicability Statement October 2004
- 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?
MN CN
------>----->------>------>------>------>------> +
ACTION (MN is authz) |
|
<-----<-----<------<------<------<------<------- | Flow
ACK | Setup
|
|
===============================================> +
Traffic
Figure 7: MN authorized initial reservation
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 April 18, 2005 [Page 38]
Internet-Draft Applicability Statement October 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 in
the paragraph below. Figure 9 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 April 18, 2005 [Page 39]
Internet-Draft Applicability Statement October 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 April 18, 2005 [Page 40]
Internet-Draft Applicability Statement October 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 April 18, 2005 [Page 41]
Internet-Draft Applicability Statement October 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 April 18, 2005 [Page 42]
Internet-Draft Applicability Statement October 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 changes. A trigger to
the CN allows the CN to quickly react on the route changes. 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 April 18, 2005 [Page 43]
Internet-Draft Applicability Statement October 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 April 18, 2005 [Page 44]
Internet-Draft Applicability Statement October 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?
segment 2
+---+
v<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<<^
v +---+ ^
+----+ +----+ +--+
| MN | |UCRN|<<<<<<<<<<|CN|
|DCRN| | |<<<<<<<<<<| |
+----+ +----+ +--+
^ +---+ v shared
^<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<<v segment
+---+
segment 1
<=============================================================
Traffic
Figure 14: Multi-homed CN as data sender
Lee, et al. Expires April 18, 2005 [Page 45]
Internet-Draft Applicability Statement October 2004
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.
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
entity allowed to perform the indicated action?" Only a few
Lee, et al. Expires April 18, 2005 [Page 46]
Internet-Draft Applicability Statement October 2004
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.
8. References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8.2 Informative References
[2] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol
for Signaling", draft-ietf-nsis-ntlp-03 (work in progress),
July 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-03 (work in progress), July
Lee, et al. Expires April 18, 2005 [Page 47]
Internet-Draft Applicability Statement October 2004
2004.
[7] Fessi, A., "Security Threats for the NAT/Firewall NSLP",
draft-fessi-nsis-natfw-threats-01 (work in progress), July
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-04
(work in progress), July 2004.
[12] Lee, S., "Mobility Functions in the QoS-NSLP",
draft-lee-nsis-mobility-nslp-01 (work in progress), November
2003.
[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
Lee, et al. Expires April 18, 2005 [Page 48]
Internet-Draft Applicability Statement October 2004
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
EMail: Hannes.Tschofenig@siemens.com
Xiaoming Fu
University of Goettingen
Telematics Group
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
Contributors
Many individuals have contributed to this draft. Since it was not
possible to list them all in the authors section, this section was
created to have a sincere respect for other authors, Paulo Mendes,
Robert Hancock and Roland Bless. Separating authors into two groups
was done without treating any one of them better (or worse) than
others.
Lee, et al. Expires April 18, 2005 [Page 49]
Acknowledgement
The authors would like to thank Byoung-Joon Lee, Charles Q. Shen,
Cornelia Kappler, Henning Schulzrinne, and Jongho Bang for
significant contributions in four earlier drafts and the previous
draft.
Lee, et al. Expires April 18, 2005 [Page 50]
Internet-Draft Applicability Statement October 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 April 18, 2005 [Page 51]