Next Steps in Signaling (nsis) T. Sanda (Ed.)
Internet-Draft Panasonic
Intended status: Informational X. Fu
Expires: January 10, 2008 University of Goettingen
S. Jeong
HUFS
J. Manner
Univ. of Helsinki
H. Tschofenig
NSN
July 9, 2007
Applicability Statement of NSIS Protocols in Mobile Environments
draft-ietf-nsis-applicability-mobility-signaling-07.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Sanda (Ed.), et al. Expires January 10, 2008 [Page 1]
Internet-Draft NSIS Signaling in Mobility July 2007
Abstract
Mobility of an IP-based node affects routing paths, and as a result,
can have a significant effect on the protocol operation and state
management. This draft discusses the effects mobility can cause to
the NSIS protocol suite, and how the protocols operate in different
scenarios, with mobility management protocols.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation and Terminology . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
4. Basic Operations for Mobility Support . . . . . . . . . . . . 11
4.1. Basic operation example . . . . . . . . . . . . . . . . . 11
4.2. Localized signaling in mobile scenarios . . . . . . . . . 13
4.2.1. CRN Discovery . . . . . . . . . . . . . . . . . . . . 15
4.2.2. State setup and update . . . . . . . . . . . . . . . . 16
4.2.3. State teardown . . . . . . . . . . . . . . . . . . . . 17
5. Interaction with Mobile IPv4/v6 . . . . . . . . . . . . . . . 18
5.1. Interaction with Mobile IPv4 . . . . . . . . . . . . . . . 18
5.2. Interaction with Mobile IPv6 . . . . . . . . . . . . . . . 20
5.3. Interaction with Mobile IP tunneling . . . . . . . . . . . 21
5.3.1. Sender-Initiated Reservation with Mobile IP tunnel . . 21
5.3.2. Receiver-Initiated Reservation with Mobile IP
tunnel . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3.3. CRN discovery and State Update with Mobile IP
tunneling . . . . . . . . . . . . . . . . . . . . . . 26
6. Further Studies . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. NSIS Operation in the multihomed mobile environment . . . 28
6.1.1. Selecting the best interface(s)/CoA(s) . . . . . . . . 28
6.1.2. Differentiation of two types of CRNs . . . . . . . . . 29
6.2. Interworking with other mobility protocols . . . . . . . . 30
6.3. Intermediate node becomes a dead peer . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7.1. MN as data sender . . . . . . . . . . . . . . . . . . . . 32
7.1.1. MN is authorizing entity . . . . . . . . . . . . . . . 32
7.1.2. CN is authorizing entity . . . . . . . . . . . . . . . 35
7.1.3. MN and CN are authorized . . . . . . . . . . . . . . . 38
7.2. CN as data sender . . . . . . . . . . . . . . . . . . . . 38
7.2.1. CN is authorizing entity . . . . . . . . . . . . . . . 38
7.2.2. MN is authorizing entity . . . . . . . . . . . . . . . 40
7.3. Multi-homing Scenarios . . . . . . . . . . . . . . . . . . 40
7.3.1. MN as data sender . . . . . . . . . . . . . . . . . . 40
7.3.2. CN as data sender . . . . . . . . . . . . . . . . . . 41
7.4. Proxy Scenario . . . . . . . . . . . . . . . . . . . . . . 42
7.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 42
Sanda (Ed.), et al. Expires January 10, 2008 [Page 2]
Internet-Draft NSIS Signaling in Mobility July 2007
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 44
9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 45
9.1. Changes from -00 version . . . . . . . . . . . . . . . . . 45
9.2. Changes from -01 version . . . . . . . . . . . . . . . . . 46
9.3. Changes from -02 version . . . . . . . . . . . . . . . . . 47
9.4. Changes from -03 version . . . . . . . . . . . . . . . . . 47
9.5. Changes from -04 version . . . . . . . . . . . . . . . . . 48
9.6. Changes from -05 version . . . . . . . . . . . . . . . . . 49
9.7. Changes from -06 version . . . . . . . . . . . . . . . . . 49
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
12.1. Normative Reference . . . . . . . . . . . . . . . . . . . 52
12.2. Informative References . . . . . . . . . . . . . . . . . . 52
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Appendix B. . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . . . 58
Sanda (Ed.), et al. Expires January 10, 2008 [Page 3]
Internet-Draft NSIS Signaling in Mobility July 2007
1. Introduction
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. Macro mobility also involves the change of the
mobile node's IP addresses. Since IP addresses are usually part of
flow identifiers, the change of IP addresses implies the change of
flow identifiers. Local mobility usually does not cause the change
of the global IP addresses, but affects the routing paths within the
local access network
The NSIS protocol suit consists of two layers: NSIS Transport Layer
Protocol (NTLP) and the NSIS Signaling Layer Protocol (NSLP). The
General Internet Signaling Transport [1] is the NTLP protocol. GIST
is a signaling application independent protocol and transports
service- related information between neighboring GIST nodes. Each
specific service has its own NSLP protocol; currently there two
standardized NSLP protocols, the QoS NSLP [2], and the NAT/Firewall
NSLP [3]
The goals of this draft are to present the effects of mobility on the
NTLP/NSLPs and to provide guides on how such NSIS protocols works in
basic mobility scenarios, including support for Mobile IPv4 and
Mobile IPv6 scenarios. This draft also briefly introduces
interworking with more complex mobility-related scenarios and their
issues as further study.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 4]
Internet-Draft NSIS Signaling in Mobility July 2007
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 RFC2119 [4].
The terminology in this draft is based on [1] and [9]. In addition,
the following terms are used. Note that in this draft, a generic
route change caused by regular IP routing is referred to as a 'route
change', and especially, the route change caused by mobility is
referred to as 'mobility' like [9].
(1) Downstream
The direction from a data sender towards the data receiver.
(2) Upstream
The direction from a data receiver towards the data sender.
(3) Crossover Node (CRN)
A Crossover Node is a node that for a given function is a merging
point of two or more paths along which states are installed.
In the mobility scenarios, there are two different types of merging
points in the network according to the direction of signaling flows
followed by data flows as shown in Figure 2 of Section 4.2, where we
assume that the MN is the data sender.
Upstream CRN (UCRN): the node closest to the data sender from
which the state information in the direction from data receiver to
data sender begins to diverge after a handover.
Downstream CRN (DCRN): the node closest to the data sender from
which the state information in the direction from the data sender
to the data receiver begins to converge after a handover.
In general, the DCRN and the UCRN may be different due to the
asymmetric characteristics of routing although the data receiver is
the same.
(4) State Update
State 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. The
State Update procedure is used to address mobility for the affected
Sanda (Ed.), et al. Expires January 10, 2008 [Page 5]
Internet-Draft NSIS Signaling in Mobility July 2007
flows.
Upstream State Update: State Update for the upstream signaling
flow which is initiated by an upstream signaling initiator. If
the MN is a data sender, the State Update is initiated by an NI on
the common path (e.g., a CN, an HA, or an MAP).
Downstream State Update: State Update for the downstream signaling
flow which is triggered by a downstream signaling initiator. If
the MN is a data sender, the State Update is triggered by an NI on
the new path (e.g., an MN, a mobility agent, or an AR).
If a route change happens without any change of the flow identifier,
State update on the common path is not required because the flow
identifiers do not change. Especially, in mobility scenarios, if the
NSIS signaling interacts with local mobility management (LMM)
protocols (e.g., HMIPv6), the State Update can be localized within
the access network. In this case, setup delay of NSIS signaling can
be minimized.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 6]
Internet-Draft NSIS Signaling in Mobility July 2007
3. Problem Statement
IP mobility in its simplest form only includes route changes. This
section identifies problems caused by mobility and multihoming, which
affect the operations of NSIS protocol suit. We also show how the
NSIS protocols cope with the problems identified as below.
1. Change of route and possibly change of the MN IP address
Topology changes or network reconfiguration might lead to path
changes for data packets sent to or from the MN and can cause an IP
address change of the MN. When an IP address changes by mobility,
firewall rules, NAT, bindings and QoS reservations become invalid
because the established flow identifier refers to a non-existent
flow. The impact of an out-dated flow identifier is most servers in
the NAT/FW case since the traffic will be blocked, or traffic will be
forwarded to the wrong IP address. In the QoS NSLP case, the impact
is limited to that the flow experiences best-effort treatment for a
limited period of time (until the flow identifier is updated again).
NSIS solution: The NSIS suite decouples state and flow
identification. A state is stored and referred to by the Session ID
(SID). Flows associated with a given NSLP state are defined by the
Message Routing Information (MRI). GIST notifies when a routing path
associated with a SID changes, and provides a notification to the
NSLP. It is then up to the NSLP to update the state information in
the network. Thus, the effect is an update to the states, not a full
new request. This decoupling effectively solves also a typical
problem with certain signaling protocols, where protocol state is
identified with flow endpoints, and when a flow endpoint changes, the
whole session state becomes invalid.
2. Double state problem
Since the state on the old path still 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 state
on the old path will be deleted automatically based on the soft state
timeout, the refresh timer value may be quite long (e.g., 30s as a
default value in RSVP). With the QoS NSLP, this problem might result
in the waste of resources and lead to failure of other reservations
(due to lack of resources). With the NAT/FW NSLP, it is still
possible to re-use this installed state although a mobile node roams
to a new location; this means that another host can send data through
a firewall without any prior NSIS NAT/FW signaling because of the
previous state which is not yet expired.
NSIS solution: Removing old state in the network is a functionality
Sanda (Ed.), et al. Expires January 10, 2008 [Page 7]
Internet-Draft NSIS Signaling in Mobility July 2007
of each NSLP independently. The QoS NSLP solves this through the use
of the Reservation Sequence Number (RSN). The RSN makes it possible
to identify new updated information related to a resource
reservation. A QNE that is CRN for a given reservation is able to
tear down an old reservation, and install a new reservation on the
new path. More details can be found in the QoS NSLP specification.
[WHAT DOES THE NAT/FW DO?]
3. End-to-end signaling and frequency of route changes
The change of route and IP addresses in mobile environments is
typically much faster and more frequent than traditional route
changes caused by node or link failure. This results in a need to
update NSLP states at a fast pace. A ping-pong type of handover
scenario may happen. Also, the flow identifier (MRI) may change.
NSIS solution: If the MRI does not change due to handovers, the NSIS
protocols are able to localize the update to only the new path. One
of the NSIS nodes on the path is a merging point of the old and new
routing paths, and is able to confine the signaling to only the
affect path. Thus, no end-to-end signaling is needed. If the MRI
changes, end-to-end signaling will happen since all the nodes on the
path must be provided with an updated flow identification (MRI); the
SID does not change. The ping-pong type of movement is a problem
caused by the mobility management. Thus, fixing this is out of scope
of the NSIS protocols.
4. Upstream State Update vs. Downstream State Update
Since the upstream and downstream paths are likely not to be exactly
the same, the upstream and downstream CRNs may not coincide, either.
Therefore, the State Update needs to be handled independently for the
upstream and the downstream, including the discovery of upstream and
downstream CRNs.
5. Identification of the crossover node
When a handover at the edge of a network has happened, in the typical
case, only some parts of the end-to-end path used by the data packets
changes. In this situation, the CRN plays a central role in managing
the establishment of the new signaling application state, and
removing any useless state.
NSIS solution: GIST provides NSLPs with an identifier of the next
signaling peer, the SII Handle. When this handle changes, the NSLP
knows a routing change has happened. Yet, the NSLP can also figure
out if it is also the crossover node for the session. More details
can be found in the NSLP specifications.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 8]
Internet-Draft NSIS Signaling in Mobility July 2007
6. Authorization Issues
The procedure of State Update may be initiated by the MN, the CN, or
even nodes within the network (e.g., crossover node, MAP in HMIP).
This State Update on behalf of the MN raises authorization issues
about the entity that is allowed to make these state modifications.
NSIS solution: Since NSIS operates on a hop-by-hop basis, any peer
can perform state updates. This is possible because a chain-of-trust
is expected between NSIS nodes. If this weren't the case, e.g., true
resource reservations would not be possible; one misbehaving or
compromised node would effectively break everything. Thus, currently
the NSIS protocols do not limit the roles of each NSIS signaling peer
on a path, and any node can make updates. Yet, some updates are
reflected back to the signaling end points, and they can decide
whether the signaling actually succeeded, or not.
7. Dead peer and invalid NR problem
When the MN is on the path of a signaling exchange, after handover
the old AR can not forward NSLP messages any further to the MN. In
this case, the old AR's mobility or routing protocol, or even the
NSLP may trigger an error message to indicate that the last node
fails or is truncated. This error message is forwarded and may
mistakenly cause the removal of the state on the existing common
path, if the state is not updated before the error message is
propagated through the signaling peers. This is called the 'invalid
NR problem'.
NSIS solution: In general, a QNE should be conservative when it
receives an indication for a state removal caused by a change in
routing. The QoS NSLP uses retransmissions and the RSN value to cope
with the problem - see the QoS NSLP specification for more details.
8. IP-in-IP Encapsulation
Mobility protocols may use IP-in-IP encapsulation on the segment 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
data traffic belonging to, for example, a QoS reservation. Moreover,
encapsulation of data traffic may lead to changes in the routing
paths since the source and the destination IP addresses of the inner
header differ from those of the outer header. Mobile IP uses
tunneling mechanisms to forward data packets among end hosts.
Traversing over the tunnel, NSIS signaling messages are transparent
on the tunneling path due to the change of flow's addresses. In case
of interworking with Mobile IP-tunneling, CRNs can be discovered on
the tunneling path. It enables NSIS protocols to perform State
Sanda (Ed.), et al. Expires January 10, 2008 [Page 9]
Internet-Draft NSIS Signaling in Mobility July 2007
Update procedure over the IP-tunnel. In this case, GIST needs to
cope with the change of Message Routing Information (MRI) for the CRN
discovery on the tunnel. Also, NSLP signaling needs to determine
when to remove the tunneling segment on the signaling path and/or how
to tear down the old state via interworking with the IP-tunneling
operation.
NSIS solution: If the signaling packets are encapsulated it is
necessary to perform a separate signaling exchange for the tunneled
region. Furthermore, a binding is needed to tie the end-to-end and
tunneled session together. The QoS NSLP implements this session
binding.
In addition to the above-mentioned issues, multihoming and key
management related to handovers bring along additional questions.
However, these are deemed out of scope of this document. Also,
practical implementations typically need various APIs across
components within a node. API issues, e.g., APIs from GIST to the
various mobility and routing schemes, are also out of scope of this
work. The generic GIST API towards NSLP is flexible enough to
fulfill most mobility-related needs of the NSLP layer.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 10]
Internet-Draft NSIS Signaling in Mobility July 2007
4. Basic Operations for Mobility Support
In this section, the basic operations of the NSIS protocol suite
needed after mobility related route changes are discussed. There may
be two possible ways of operations:
- Option 1: GIST detects the route change by its periodical
internal refreshes, then use NetworkNotification() API primitive
to notify NSLPs to update their corresponding state. Here the
operation may be incomplete before an end-to-end signaling is
accomplished.
- Option 2: Upon a handover event (e.g., acquisition of a new IP
address in the MN, or update of the binding cache in the HA or the
CN, as it will be discussed in Section 5), each NSLP updates its
signaling state in the reflected path. For generality this option
is preferred as it eventually accomplishes the signaling
procedure, no matter whether optimization is encountered.
In both options, as the primary task of signaling will be performed
in the NSLP layer, and the NSLP operation is of particular
importance. In order to illustrate this the following subsection
presents an example of QoS NSLP signaling for data traffic from the
MN to the CN in the Mobile IPv6 route optimization mode, following
the second option approach.
Furthermore, optimization of the signaling procedure may be used, to
reduce the unnecessary signaling overhead and to minimize the
processing. To optimize the signaling, two issues are identified,
namely how to discover an appropriate CRN and how to perform the
localized signaling (or so-called State Update) according to the
direction of data flows.
4.1. Basic operation example
The following figure illustrates an example of QoS NSLP signaling in
a Mobile IPv6 route optimization case, for the data flow from the MN
to the CN, where sender-initiated reservation is used. Once a
handover event is detected in the MN, the MN issues a QoS NSLP Resv
message towards the CN, which carries the unique session ID and other
identification information for the session, as well as the
reservation requirements. Upon receipt of the Resv message, the QoS
NSLP nodes (which will be discovered by the underlying NTLP)
establish the corresponding QoS NSLP state, and forward the message
towards the CN. When there is already an existing NSLP state with
the same session ID, the state will be updated. If all the QoS NSLP
nodes along the path support the required QoS, the CN in turn
responds with a Response message, to confirm the reservation.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 11]
Internet-Draft NSIS Signaling in Mobility July 2007
In the bi-directional tunneling case, the only difference is that the
Resv message should be sent to the HA instead of the CN, and the node
which responds with a Response should be the HA instead of the CN
too.
Therefore, for the basic operation there is no fundamental difference
among different operation modes of Mobile IP, and the main issue of
mobility support in NSIS is to trigger NSLP signaling appropriately
when a handover event is detected, and the destination of the NSLP
signaling shall follow the Mobile IP data path as being path-coupled
signaling.
In this process, the obsoleted state in the old path is not
explicited released. To speed up the process, there is possibility
to localize the signaling to speed this process. When the Resv
message reaches a node, depicted as CRN in this document, where a
state is determined for the first time to reflect the same session,
the node may issue a Resv message (with Teardown bit set) towards the
MN's old CoA, to release the obsoleted state.
MN R1 MN R2 R3 R4 CN
(CoA1) | (CoA2) | (CRN) | |
| | | | | | |
| | | | | | |
| | |Resv | | | |
| | |------>| | | |
| | | (1) |Resv | | |
| | | |---->| | |
| | | | (2) | Resv | |
| | | | |------->| |
| | |Resv(T)| | (3) |Resv |
| |<-----------------| |---->|
| | | (9) | | | (4) |
| | | | | |<----|
| | | | | Resp |Resp |
| | | | Resp|<-------| (5) |
| | | Resp |<----| (6) | |
| | |<------| (7)| | |
| | | (8) | | | |
| | | | | | |
| | | | | | |
Figure 1: Basic operation example
Sanda (Ed.), et al. Expires January 10, 2008 [Page 12]
Internet-Draft NSIS Signaling in Mobility July 2007
4.2. Localized signaling in mobile scenarios
As shown in Figure 2, mobility generally causes signaling path to
either converge or diverge depending on the direction of each
signaling flow.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 13]
Internet-Draft NSIS Signaling in Mobility July 2007
Old path
+--+ +-----+
original |MN|<------ |OAR | ---------^
address | | |NSLP1| ^
+--+ +-----+ ^ common path
| C +-----+ +-----+ +--+
| | |<--|NSLP1|----|CN|
| |NSLP2| |NSLP2| | |
v New path +-----+ +-----+ +--+
+--+ +-----+ V B A
New CoA |MN|<------ |NAR |----------V >>>>>>>>>>>>
| | |NSLP1| ^
+--+ +-----+ ^
D ^
>>>>>>>(Binding process)>>>>>>>>>>>>^
<=====(upstream signaling followed by data flows) =====
(a) The topology for upstream NSIS signaling flow due to
mobility
Old path
+--+ +-----+
original |MN|------> |OAR | ----------V
| | |NSLP1|
address +--+ +-----+ V common path
| K +-----+ +-----+ +--+
| | |---|NSLP1|--->|CN|
| |NSLP2| |NSLP2| | |
v New path +-----+ +-----+ +--+
+--+ +-----+ ^ M N
New CoA |MN|------> |NAR |-----------^ >>>>>>>>>>>>
| | |NSLP1| ^
+--+ +-----+ ^
L ^
>>>>>>>(Binding process)>>>>>>>>>>>>^
====(downstream signaling followed by data flows) ======>
(b) The topology for downstream NSIS signaling flow due to
mobility
Figure 2: The topology for NSIS signaling caused by mobility
These topological changes caused by mobility make the NSIS state
established in the old path useless. It may need to be removed (in
the end) as soon as possible. In addition, NSIS state needs to be
created along the new path and be updated along the common path. The
re-establishment of NSIS signaling may be localized when route
Sanda (Ed.), et al. Expires January 10, 2008 [Page 14]
Internet-Draft NSIS Signaling in Mobility July 2007
changes (including mobility) occur to minimize the impact on the
service and to avoid unnecessary signaling overhead. This localized
signaling procedure is referred to as State Update (refer to the
terminology section). In mobile environments, for example, the NSLP/
NTLP needs to limit the scope of signaling information only to the
affected portion of the signaling path because the signaling path in
the wireless access network usually changes only partially.
One of the most appropriate nodes to perform the State Update is the
CRN where the old and new signaling paths meet. The CRN should be
the logical merging point, not physical one. In the end, CRN
discovery can be a crucial element to alleviate the double
reservation and end-to-end signaling problems identified in
Section 3.
4.2.1. CRN Discovery
The approaches for CRN discovery can be divided into two classes
depending on which layer is responsible for the CRN discovery
(discussed in Section 2), and whether or not 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 either NTLP or NSLP layer. In case of mobility, proper place for
CRN discovery is NSLP. For the CRN discovery at the NSLP layer, the
information contained in NSLP signaling messages sent from the NSIS
initiator (NI) can be used. For example, the QoS-NSLP can determine
whether or not the node is a CRN by comparing the Source
Identification Information (SII) contained in the incoming signaling
message to the one stored. That is, when a RESERVE message with an
existing SESSION ID and different SII is received, the QNE knows its
upstream peer has changed and realizes it is implicitly the CRN [5].
The NTLP layer can easily detect route changes by tracking the SII-
Handle of sessions. Thus, in theory, it would be possible to also
discover the CRN at the NTLP layer since the NTLP is responsible for
detecting the path change of data (or signaling) flow. However, in
practice a routing change primarily affects an NSLP and its internal
state and next peers, and this change is out of scope of NTLP which
is mainly concerned with hop-by-hop transport of signaling messages.
Thus, all the logic for CRN discovery and how it affects the
application layer is ultimately the task of NSLP.
There can also be two different approaches for the CRN discovery
messaging depending on whether or not the discovery is coupled with a
signaling message: coupled approach and uncoupled approach. In the
coupled approach, the signaling to install the NSIS state along the
new path or update the state along the common path is performed
Sanda (Ed.), et al. Expires January 10, 2008 [Page 15]
Internet-Draft NSIS Signaling in Mobility July 2007
simultaneously with the CRN discovery. In the uncoupled approach,
the signaling for the State Update is performed after the CRN
discovery is completed. These two approaches may differ in terms of
security. Generally, the coupled approach in the NSIS protocol suit
is preferred to the uncoupled approach to reduce the delay for state
update.
4.2.2. State setup and update
Before initiating the State Update, the MN or the CN needs to acquire
necessary authentication and authorization for the corresponding
state operation. The MN or the CN may also check the availability of
resources on the new path. In case of QoS-NSLP, the Query message
can be used to find the availability of resources in the networks
(e.g., access networks or core networks). If the resources along the
new path are not sufficient, it may be needed to keep the state
established previously using multihomed interfaces while blocking
incoming new requests.
In the downstream State Update, if resources are available, the MN
initiates the NSIS signaling for state setup toward a CN and also the
implicit DCRN discovery is performed by the procedure of signaling as
described in Section 4.2.1. Then, DCRN may send a response message
towards the MN to notify of the NSLP state installed (e.g., QoS-NSLP
state) or installs the NSLP state as a response to the initiated NSLP
signaling (e.g., as in RSVP). Afterward, the DCRN sends a refresh
message towards the signaling destination to update the MRI on the
common path and also sends a teardown message towards the old AR to
delete the NSIS state (if possible). Note that in case of QoS-NSLP,
the sender-initiated approach leads to faster setup than the
receiver-initiated approach as in RSVP [5].
In the scenario of an upstream State Update, the CN (or a HA/ a GFA/
MAP) sends a refresh message toward the MN to perform State Update.
UCRN is discovered implicitly by the CN-initiated signaling along the
common path as described in Section 4.2.1. After the UCRN is
discovered, it may send a refresh message to the MN along the new
path while establishing the messaging association between the newly
found peers. Afterwards, the UCRN may send a teardown message
towards the old AR to delete the NSIS state (if possible).
The State Update on the common path to reflect the changed MRI brings
issues on the end-to-end signaling addressed in Section 3. Although
the State Update over the common path does not give rise to re-
processing of AAA and admission control, it may lead to the increased
signaling overhead and latency.
One of the goals of the State Update is to avoid the double
Sanda (Ed.), et al. Expires January 10, 2008 [Page 16]
Internet-Draft NSIS Signaling in Mobility July 2007
reservation on the common path as described in Section 3. The double
reservation problem on the common path can be solved by establishing
a signaling association using a unique SID and by updating packet
classifier/flow identifier. In this case, even though the flows on
the common path have different flow dentifiers, it keeps same NSLP
state.
4.2.3. State teardown
After establishment of the NSIS state along the new path, the state
on the obsolete path may need to be quickly removed by the State
Update mechanism. It helps prevent the waste of resources due to
double reservation, which causes resource re-allocation problem by
call blocking, and reduce the cost of using resources in the access
network as identified in Section 3. Although the release of the
existing state on the old path can be accomplished by soft state, the
refresh timer value may be quite long for reducing the overhead of
signaling messages. Especially, in mobility scenarios, the
maintenance of the NSIS state on the old path for a long time is not
necessary. Therefore, the transmission of teardown messages is
useful to quickly delete the old state.
The CRN is an appropriate point to initiate the teardown toward the
old AR after establishment of the state along the new path. The
release of the state on the obsolete path can be accomplished by
comparing SII. This can prevent the teardown message from being
forwarded toward along the common path. Note that, however, it is
not necessary for GIST state to be explicitly removed because of the
inexpensiveness of the state maintenance at the GIST layer [1].
It may not be desirable to allow the teardown message to be sent
toward the opposite direction to the state initiating node. This is
because it leads to an authorization problem because a node which
does not initiate signaling for establishing the NSIS state can
delete the already established state. One simple way to avoid the
authorization problem is to disallow the transmission of the teardown
message in the reverse direction [10].
The immediate removal of state along the old path may not be always
appropriate for some mobility situations, for instance, 'invalid NR'
problem addressed in Section 3. Old path should not be deleted
before re-establishing the state along the new path (make-before-
break handover).
Sanda (Ed.), et al. Expires January 10, 2008 [Page 17]
Internet-Draft NSIS Signaling in Mobility July 2007
5. Interaction with Mobile IPv4/v6
In Mobile IP scenario, there are two types of data routings, one is
triangular routing with tunneling section, and the other is optimized
routing which is direct routing between an MN and a CN. This section
analyzes NSIS operation with these data routes.
5.1. Interaction with Mobile IPv4
In Mobile IPv4 [6], the data flows are forwarded based on triangular
routing, and an MN retains a new CoA from the FA (or an external
method such as DHCP) in the visited access network. When the MN acts
as a data sender, the data and signaling flows sent 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, when the MN act as a data receiver, the data and signaling
flows sent from the CN are routed through the IP tunneling between
the HA and the FA (or the HA and the MN in case of the Co-located
CoA). With this approach, routing is dependent on the HA, and
therefore the NSIS protocols interact with the IP tunneling procedure
of Mobile IP for signaling.
The Figure 3 (a) to (e) show the NSIS signaling flows depending on
the direction of the data flows and the routing methods.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 18]
Internet-Draft NSIS Signaling in Mobility July 2007
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 CoA
MN (FL) HA CN
| | | |
| IPv4(tunnel) | |
|------------------------------->|IPv4 (normal) |
| | |-------------->|
(c) MIPv4: MN-->CN, the reverse tunnel with Co-located CoA
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 3: NSIS signaling flows under different Mobile IPv4 scenarios
When an MN (as a signaling sender) arrives at a new FA and the
corresponding binding process is completed (Figure 3 (a), (b) and
Sanda (Ed.), et al. Expires January 10, 2008 [Page 19]
Internet-Draft NSIS Signaling in Mobility July 2007
(c)), the MN performs the CRN discovery (DCRN) and the State Update
toward the CN (as described in Section 4) to establish the NSIS state
along the new path between the MN and the CN. In case reverse tunnel
is not used (Figure 3 (a)), a new NSIS state is established on direct
path from the MN to the CN. If the reverse tunnel and FA CoA are
used (Figure 3 (b)), a new NSIS state is established along a
tunneling path from the FA to the HA separately from end-to-end path.
CRN discovery and State Update in tunneling path is also separately
performed if necessary. If the reverse tunnel and co-located CoA are
used (Figure 3 (c)) the NSIS signaling for the DCRN discovery and the
State Update is the same as the case of using FA CoA above except for
the use of the reverse tunneling path from the MN to the HA. That
is, in this case, one of tunnel end points is the MN, not the FA.
When an MN (as a signaling receiver) arrives at a new FA and the
corresponding binding process is completed (Figure 3 (d) and (e)),
the MN sends NOFITY message to the signaling sender, i.e., the CN.
In case FA CoA is used (Figure 3 (d)), the CN initiates a NSIS
signaling to update an existing state between the CN and the HA, and
afterwards the NSIS signaling messages are forwarded to the FA and
reaches to the MN. A new NSIS state is established along the
tunneling path from the HA to the FA separately from end-to-end path.
During this operation, a UCRN is discovered on the tunneling path,
and a new flow identifier for the State Update on the tunnel may need
to be created. CRN discovery and State Update in tunneling path is
also separately performed if necessary. In case collocated CoA is
used (Figure 3 (d)) the NSIS signaling for the UCRN discovery and the
State Update is also the same as the case of using FA CoA above
except for the end point of tunneling path from the HA to the MN.
Note that Mobile IPv4 optionally supports route optimization. In the
case route optimization is supported, the signaling operation will be
the same as Mobile IPv6 route optimization.
5.2. Interaction with Mobile IPv6
Unlike Mobile IPv4, with Mobile IPv6 [7], the FA is not required on
the data path. If an MN moves to visited network, a CoA at the
network is allocated like co-located CoA in Mobile IPv4. In
addition, the route optimization process between the MN and CN can be
used to avoid the triangular routing in the Mobile IPv4 scenarios.
If the use of route optimization is not mandatory, data flow routing
and NSIS signaling procedures (including the CRN discovery and the
State Update) will be similar to the case of using the Mobile IPv4
with co-located CoA. However, if Route Optimization is used,
signaling messages are sent directly from the MN to the CN, or from
the CN to the MN. Therefore, route change procedures described in
Sanda (Ed.), et al. Expires January 10, 2008 [Page 20]
Internet-Draft NSIS Signaling in Mobility July 2007
Section 4 are applicable to this case.
5.3. Interaction with Mobile IP tunneling
In this section, we assume that MN acts as a signaling sender and CN
acts as a signaling receiver in interworking between Mobile IP and
NSIS signaling.
Scenarios for interaction with Mobile IP tunneling vary depending on:
- Whether a tunneling entry point (Tentry) is an MN or other node.
In case Mobile IPv4 co-located CoA or Mobile IPv6, Tentry is an
MN. In case Mobile IPv4 FA CoA case, Tentry is a FA. In both
case, a HA is tunneling exit point (Texit).
- Whether the mode of QoS-NSLP signaling is sender-initiated or
receiver initiated.
- Whether the signaling mode over tunnel is sequential mode or
parallel mode. In sequential mode, end-to-end signaling pauses
when it is waiting for results of tunnel signaling, and resumes
upon receipt of the tunnel signaling outcome. In parallel mode,
end-to-end signaling continues outside the tunnel while tunnel
signaling is still in process and its outcome is unknown [8].
The following subsection describes sender-initiated and receiver-
initiated reservation with Mobile IP tunneling and CRN discovery and
State Update with Mobile IP tunneling.
5.3.1. Sender-Initiated Reservation with Mobile IP tunnel
The following scenario assumes that a FA is a Tentry. However the
procedure is the same for the case an MN is a Tently if it is
considered that the MN and the FA are the same node.
- When an MN moves into a new network attachment point, QoS- NSLP
in the MN initiates RESERVE (end-to-end) message to start the
State Update procedure. The GIST below the QoS-NSLP adds GIST
header and then sends the encapsulated RESERVE message to peer
GIST node with corresponding QoS-NSLP for DCRN discovery. In this
case, the peer GIST node is a FA if the FA is an NSIS-aware node.
The FA is one of the endpoints of Mobile IP tunneling: Tentry. In
case of interaction with tunnel signaling originated from the FA,
there can be two scenarios depending on whether NSIS signaling
interacts with the Mobile IP tunneling. The first scenario is
that the NSIS signaling is discerned on the tunneling path between
the FA and corresponding HA, and then the tunneling path becomes
an NSIS-aware cloud. The second one is otherwise, and here the
Sanda (Ed.), et al. Expires January 10, 2008 [Page 21]
Internet-Draft NSIS Signaling in Mobility July 2007
tunneling path is transparent as a logical link to NSIS signaling
[8].
- In the NSIS-aware tunneling scenarios, as shown in Figure 4 and
Figure 5, upon receiving the RESERVE message from the MN, the QoS-
NSLP of FA explicitly creates a new RESERVE-t (tunnel) message,
which keeps the existing (end-to-end) Session ID and includes a
new (tunneling) Flow ID different from the (end-to-end) flow ID,
to distinguish the NSIS signaling messages over the Mobile IPv4
tunneling path. The RESERVE-t message is forwarded toward HA,
another end point of Mobile IPv4 tunneling. Also, after receiving
the RESERVE-t message from the FA, the HA should decide whether it
needs to initiate a RESPONSE-t (tunnel) message toward FA for
responding to the RESERVE-t message, or make the RESPONSE-t
message wait until a RSESPONSE message, which is created to react
the RESERVE message, arrives from the CN.
- In this procedure of NSIS-tunnel signaling, again, two
categories of tunnel signaling mode are taken into consideration,
i.e., either sequential or parallel mode.
- Provided that the tunnel signaling mode is sequential as shown
in Figure 4, the RESERVE signaling toward the HA resumes after
confirming completeness of NSIS tunnel signaling through the
RESERVE-t and the RESPONSE-t messages. Arriving at HA, the
RESERVE message is forwarded to CN to update or refresh the
existing NSIS states (QoS-NSLP and GIST) on the common path. The
CN initiates a RESPONSE message, responding to the RESERVE
message, toward the HA as its destination. The HA forwards the
RESPONSE message to the FA after encapsulating the message.
Finally, the RESPONSE message is sent to MN after being
decapsulated at the FA. Note that both end-to-end signaling
messages, the RESPONSE and the RESERVE messages, are not
discernible on the tunneling path, like a logical link, and those
messages just play a role of NSIS signaling for establishing end-
to-end state.
- Provided that the tunnel signaling mode is parallel as shown in
Figure 5, upon receiving the RESERVE message from the MN, the FA
forwards it to the HA at the drop of a hat. Also, arriving at the
HA from the CN, the RESPONSE message is again forwarded from the
HA to the FA regardless of the delivery of RESPONSE-t message.
Since in this parallel mode the end-to-end signaling messages do
not reconcile with both NSIS-tunnel signaling messages, the
RESERVE-t and RESPONSE-t messages, the tunneling path operates
like a logical link and thus NON-QoS-HOP flag is set within the
RESERVE message although NSIS-tunnel signaling messages are
available on the tunnel path.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 22]
Internet-Draft NSIS Signaling in Mobility July 2007
MN (Sender) FA (Tentry) Tnode HA (Texit) CN (Receiver)
| | | | |
| RESERVE | | | |
+--------->| | | |
| |RESERVE-t | | |
| +=========>| | |
| | |RESERVE-t | |
| | +=========>| |
| | |RESPONSE-t| |
| | |<=========+ |
| |RESPONSE-t| | |
| |<=========+ | |
| | RESERVE | |
| +-------------------->| |
| | | | RESERVE |
| | | +--------->|
| | | | RESPONSE |
| | | |<---------+
| | RESPONSE | |
| |<--------------------+ |
| RESPONSE | | | |
|<---------+ | | |
| | | | |
Figure 4: Sender-Initiated QoS-NSLP over Tunnel - Sequential Mode
Sanda (Ed.), et al. Expires January 10, 2008 [Page 23]
Internet-Draft NSIS Signaling in Mobility July 2007
MN (Sender) FA (Tentry) Tnode HA (Texit) CN (Receiver)
| | | | |
| RESERVE | | | |
+--------->| | | |
| |RESERVE-t | | |
| +=========>| | |
| | |RESERVE-t | |
| | +=========>| |
| | RESERVE | |
| +-------------------->| |
| | | | RESERVE |
| | | +--------->|
| | | | RESPONSE |
| | | |<---------+
| | |RESPONSE-t| |
| | |<=========+ |
| |RESPONSE-t| | |
| |<=========+ | |
| | RESPONSE | |
| |<--------------------+ |
| RESPONSE | | | |
|<---------+ | | |
| | | | |
Figure 5: Sender-Initiated QoS NSLP over Tunnel - Parallel Mode
5.3.2. Receiver-Initiated Reservation with Mobile IP tunnel
Figure 6 and Figure 7 show examples of receiver-initiated operation
with Mobile IP tunnel for Sequential and Parallel modes,
respectively. Basic Operation is the same as sender-initiated case.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 24]
Internet-Draft NSIS Signaling in Mobility July 2007
MN (Sender) FA (Tentry) Tnode HA (Texit) CN (Receiver)
| | | | |
|QUERY | | | |
+--------->| QUERY | |
| +-------------------->| QUERY |
| | | +--------->|
| | | | RESERVE |
| | RESERVE |<---------+
| |<--------------------+ |
| | QUERY-t | | |
| +=========>| QUERY-t | |
| | +=========>| |
| | |RESERVE-t | |
| |RESERVE-t |<=========+ |
| |<=========+ | |
| |RESPONSE-t| | |
| RESERVE +=========>|RESPONSE-t| |
|<---------| +=========>| |
| RESPONSE | | | |
+--------->| RESPONSE | |
| +-------------------->| RESPONSE |
| | | +--------->|
| | | | |
Figure 6: Receiver-Initiated QoS NSLP over Tunnel - Sequential Mode
Sanda (Ed.), et al. Expires January 10, 2008 [Page 25]
Internet-Draft NSIS Signaling in Mobility July 2007
MN (Sender) FA (Tentry) Tnode HA (Texit) CN (Receiver)
| | | | |
|QUERY | | | |
+--------->| QUERY | |
| +-------------------->| QUERY |
| | | +--------->|
| | | | RESERVE |
| | RESERVE |<---------+
| RESERVE |<--------------------+ |
|<---------+ | | |
| | QUERY-t | | |
| +=========>| QUERY-t | |
| | +=========>| |
| | |RESERVE-t | |
| |RESERVE-t |<=========+ |
| |<=========+ | |
| |RESPONSE-t| | |
| +=========>|RESPONSE-t| |
| | +=========>| |
| RESPONSE | | | |
+--------->| RESPONSE | |
| +-------------------->| RESPONSE |
| | | +--------->|
| | | | |
Figure 7: Receiver-Initiated QoS NSLP over Tunnel - Parallel Mode
5.3.3. CRN discovery and State Update with Mobile IP tunneling
Interaction with Mobile IP tunneling scenario can define two types of
CRNs, i.e., a CRN on end-to-end path and a CRN on tunneling path.
CRN discovery and State Update for these two paths are operated
independently.
CRN discovery for end-to-end path is initiated by the MN by sending
RESERVE (sender-initiated case) or QUERY (receiver-initiated case)
message. As MN uses HoA as source address even after handover, a CRN
is found by normal route change process (i.e., the same SID and FID,
but different SII handle). If a HA is QoS-NSLP aware, the HA is
found as the CRN. The CRN initiate tearing process on the old path
as described in [2]
CRN discovery for tunneling path is initiated by Tentry by sending
RESERVE-t (sender-initiated case) or QUERY-t (receiver-initiated
case) message. The route change procedures described in Section 4
Sanda (Ed.), et al. Expires January 10, 2008 [Page 26]
Internet-Draft NSIS Signaling in Mobility July 2007
are applicable to this case.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 27]
Internet-Draft NSIS Signaling in Mobility July 2007
6. Further Studies
This section introduces potential issues and possible approaches for
complicated scenarios in the mobile environment, i.e., peer failure
scenarios, multihomed scenarios, and interworking with other mobility
protocols. Topics in this section are out-of-scope of this document,
and detailed operations are not discussed. All topics are for future
studies.
6.1. NSIS Operation in the multihomed mobile environment
In multihomed mobile environments, multiple interfaces and addresses
(i.e., CoAs and HoAs) are available. This case, two major issues can
be considered. One is how to select or acquire the most appropriate
interface(s) and/or address(es) from end-to-end QoS point of view.
The other is, when multiple paths are simultaneously used for load-
balancing purpose, how to differentiate and manage two types of CRNs,
i.e., CRN between two on-going Paths (LB-CRN: Load Balancing CRN) and
CRN between the old and new paths caused by MN's handover (HO-CRN:
Handover CRN). This section introduces possible approaches for these
issues.
6.1.1. Selecting the best interface(s)/CoA(s)
In MIPv6 route optimization case, if multiple CoAs registration is
provided [11], the contents of QUERYs sent by candidate CoAs can be
used to select the best interface(s)/CoA(s).
Assume that an MN is a data sender and has multiple interfaces. Now
the MN moves to a new location and acquires CoA(s) for multiple
interfaces. After the MN performs the BU/BA procedure, it sends
QUERY messages toward the CN through the interface(s) associated with
the CoA(s). On receiving the QUERY messages, the CN or Gateway,
determines the best (primary) CoA(s) by checking 'QoS available'
field in the QUERY messages. Then a RESERVE message is sent toward
the MN to reserve resources along the path the primary CoA takes. If
the reservation is not successful, the CN transmits another RESERVE
message using the CoA with the next highest priority. The CRN may
initiate a teardown (RESERVE with the TEAR flag set) message toward
old access router (OAR) to release the reserved resources on the old
path.
In case of sender-initiated reservation, a similar approach is
possible. That is, the QUERY and RESERVE messages are initiated by
an MN, and the MN selects the Primary CoA based on the information
delivered by the QUERY message.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 28]
Internet-Draft NSIS Signaling in Mobility July 2007
|--Handover-->|
MN OAR AR1 AR2 AR3 CRN CRN CRN CN
(OAR/AR1)(OAR/AR2)(OAR/AR3)
| | | | | | | | |
|---QUERY(1)->|-------------------->|---------------------->|
| | | | | | | | |
|---QUERY(2)-------->|--------------------->|-------------->|
| | | | | | | | |
|---QUERY(3)--------------->|---------------------->|------>|
| | | | | | | | |
| | | | | | | | Primary CoA
| | | | | | | | Selection(4)
| | | | | | | | |
| | | | | | |<--RESERVE(5)--|
| | | |<------RESERVE(6)-----| (Flow ID |
| | | | (Actual reservation) | Update) |
|<----RESERVE(7)-----| | | | | |
| | | | | | | | |
| |<-----------teardown(8)-------------| | |
| | | | | | | | |
| | | | Multimedia Traffic | | |
|<=================->|<===================->|<=============>|
| | | | | | | | |
Receiver-initiated reservation in the multihomed environment
6.1.2. Differentiation of two types of CRNs
When multiple interfaces of the MN are simultaneously used for load-
balancing purpose, a possible approach for distinguishing LB-CRN and
HO-CRN will introduce an identifier to determine the relationship
between interfaces and paths.
An MN uses interface 1 and interface 2 for the same session, where
the paths (say path 1 and path 2) have the same SID but different
FIDs as shown in (a) of Figure 9. Now one of the interfaces of MN
performs a handover and obtains a new CoA, the MN will try to
establish a new path (say Path 3) with the new FID, as shown in (b)
of Figure 9. In this case the CRN between path 2 and path 3 cannot
determine if it is LB-CRN or HO-CRN since for both cases, SID is the
same but FIDs are different. Hence the CRN will not know if State
Update is required. One possible solution to solve this issue will
introduce path classification identifier which shows the relationship
between interfaces and paths. For example, signaling messages and
QNEs belong to paths from interface 1 and interface 2 carry the
identifier '00' and '02', respectively. By having this identifier,
Sanda (Ed.), et al. Expires January 10, 2008 [Page 29]
Internet-Draft NSIS Signaling in Mobility July 2007
the CRN between path 2 and path 3 will be able to determine whether
it is LB-CRN or HO-CRN. For example, if path 3 carries '00', the CRN
is LB-CRN, and if '01', the CRN is HO-CRN.
+--+ Path 1 +---+ +--+
| |IF1 <-----------------|LB | common path | |
|MN| |CRN|-------------|CN|
| | Path 2 | | | |
| |IF2 <-----------------| | | |
| | +---+ +--+
| |
+--+
(a) NSIS Path classification in multihomed environments
+--+ Path 1 +---+ +--+
| |IF1 <-----------------|?? | common path | |
|MN| |CRN|-------------|CN|
| | Path 2 -| | | |
| |IF2 <--- +------+ | | | | |
| | \_|??-CRN|--v +---+ +--+
| | / +------+
+--+IF? <---
Path 3
(b) NSIS Path classification after handover
Figure 9: The topology for NSIS signaling in multihomed mobile
environments
6.2. Interworking with other mobility protocols
Unlike the generic route changes, in mobility scenarios, the end-to-
end signaling problem by the State Update gives rise to the
degradation of network performance, e.g., increased signaling
overhead, service blackout, and so on. To reduce signaling latency
in the Mobile IP-based scenarios, the NSIS protocol suite may need to
interwork with localized mobility management (LMM). If the GIST/NSLP
(QoS-NSLP or NAT/FW-NSLP) protocols interact with Hierarchical Mobile
IPv6 and the CRN is discovered between an MN and an MAP, the State
Update can be localized by address mapping. However, how the State
Update is performed with scoped signaling messages within the access
network under the MAP is for future study.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 30]
Internet-Draft NSIS Signaling in Mobility July 2007
In the inter-domain handover, a possible way to mitigate the latency
penalty is to use the multi-homed MN. It is also possible to allow
the NSIS protocols to interact with mobility protocols such as
Seamoby protocols (e.g., CARD [RFC4066] and CXTP [RFC4067]) and FMIP.
Another scenario is to use peering agreement which allows aggregation
authorization to be performed for aggregate reservation on an inter-
domain link without authorizing each individual session. How these
approaches can be used in NSIS signaling is for further study.
6.3. Intermediate node 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 re-discovered
immediately by the CRN discovery procedure.
The failure of an AR may make the interactions with Seamoby protocols
(such as CARD and CXTP) 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
left for future work.
In Mobile IP-based scenarios, the failures of NSIS functions at an FA
and an HA may result in incomplete interaction with IP-tunneling. In
this case, recovery for NSIS functions needs to be performed
immediately. In addtion, a more detailed analysis of interactions
with IP-tunneling is left for future work.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 31]
Internet-Draft NSIS Signaling in Mobility July 2007
7. Security Considerations
This section describes authorization issues for mobility scenarios in
NSIS. It tries to raise additional questions beyond those discussed
in [10].
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 [12]
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 and
the reason is described in [12].
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 10 where the MN acts as a data sender
which moves from one point of attachment to another.
This description starts with an initial signaling exchange triggered
by the MN. The user (or another entity associated the initial setup)
provides the credentials for setup as part of the NSLP authorization
procedure (e.g., QoS reservation).
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 be
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 independently of the authorization issues
discussed in this section.
The following questions seem to be interesting:
Sanda (Ed.), et al. Expires January 10, 2008 [Page 32]
Internet-Draft NSIS Signaling in Mobility July 2007
- Should the MN indicate that it is the authorzing entity for
subsequent actions to all entities along the path?
- What information should be used for this purpose?
- Who should add this information? Should the visited network of
the MN add something to the signaling message during the initial
flow setup?
- How do other entities along the path learn this information?
MN CN
------>----->------>------>------>------>------> +
ACTION (MN is authz) |
|
<-----<-----<------<------<------<------<------- | Flow
ACK | Setup
|
|
===============================================> +
Traffic
Figure 10: MN authorized initial reservation
Next, the case for a mobile node authorizing the DCRN is considered.
This communication is illustrated in Figure 11.
The movement of the mobile node after the initial flow setup requires
authorization. Various session ownership authorization issues are
illustrated in [10].
MN DCRN CN
+ E.g.
------>----->------>------>------>------>------> | Movement
ACTION | with state
| creation at
<-----<-----<------<------<------<------<------- + new path
ACK
Sanda (Ed.), et al. Expires January 10, 2008 [Page 33]
Internet-Draft NSIS Signaling in Mobility July 2007
Figure 11: 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? [the trust is not the other way round:
the MN trusts the DCRN?]) As an example, the DCRN might delete
state along the old segment.
- Should the DCRN alone be able to start signaling (the DCRN might
be a dedicated node in some mobility protocols (e.g., MAP)) since
it is the node which has more information than other nodes based
on the mobility signaling protocols?
- How should other nodes between the MN and the DCRN and the nodes
between the DCRN 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 12 shows the exchange graphically.
In this scenario the CN wants to, for example, tear-down a
reservation.
MN DCRN CN
<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +
TRIGGER | E.g.
| Tear
| Down
------>----->------>------>------>------>------> |
ACTION |
|
<-----<-----<------<------<------<------<------- +
ACK
Figure 12: CN triggers action
The following questions arise:
- Why should the MN trust the trigger? Why should the
intermediate nodes trust it?
Sanda (Ed.), et al. Expires January 10, 2008 [Page 34]
Internet-Draft NSIS Signaling in Mobility July 2007
- 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 [12]).
- Should the CN restrict the actions of the MN (e.g., delete,
update, create action of established state information)? 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
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 13
7.1.2.1. CN asks MN to trigger action (on behalf of CN)
In Figure 13 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.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 35]
Internet-Draft NSIS Signaling in Mobility July 2007
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 13: 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 from the CN and the MN?
7.1.2.2. CN uses install state to route message backwards
The CN uses NSIS installed state to route a signaling message
backwards along the path. In some rare cases the DCRN 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 DCRN.
The mobile node might also trigger the deletion of resources along
the old segment together with this state creation (pessimistic
Sanda (Ed.), et al. Expires January 10, 2008 [Page 36]
Internet-Draft NSIS Signaling in Mobility July 2007
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 14: CN uses installed state to route message backwards
Figure 14 raises a few questions:
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.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 37]
Internet-Draft NSIS Signaling in Mobility July 2007
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.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 delegate the authorization decision. 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 [10]
draft which lists a few proposals for addressing the session
ownership problem.
7.2. CN as data sender
In this section we consider the scenarios where the CN acts as a data
sender. Figure 15 shows the topology and the participating entities.
7.2.1. CN is authorizing entity
This scenario is similar to the one described in Section [12]. No
additional problems arise with a scenario where the CN is both data
sender and also the authorizing entity. In Section 7.1.1 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.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 38]
Internet-Draft NSIS Signaling in Mobility July 2007
MN UCRN 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 15: 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 15.
- 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 message exchange it needs to be studied whether the
signaling message provides sufficient authorization to trigger the
NSIS exchange.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 39]
Internet-Draft NSIS Signaling in Mobility July 2007
7.2.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.2 where the MN is the data sender but
the CN is the authorizing entity.
7.3. Multi-homing Scenarios
Multi-homing scenarios have the property that more than one path
belongs to a signaling session. In Figure 16 the MN uses two
interfaces to route NSIS message towards the CN. The two individual
flows are tight together by using the same session identifier and
then associate it with the two flow identifiers. 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 might be stored (if desired).
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.3.1. MN as data sender
This section shows the multi-homing scenario with the MN as a data
sender.
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.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 40]
Internet-Draft NSIS Signaling in Mobility July 2007
segment 2
+---+
^>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>V
^ +---+ V
+----+ +----+ +--+
| MN | |DCRN|>>>>>>>>>>|CN|
|UCRN| | |>>>>>>>>>>| |
+----+ +----+ +--+
v +---+ ^ shared
v>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>^ segment
+---+
segment 1
=======================Traffic===============================>
Figure 16: Multi-homed MN as data sender
7.3.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.3.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===============================
Sanda (Ed.), et al. Expires January 10, 2008 [Page 41]
Internet-Draft NSIS Signaling in Mobility July 2007
Multi-homed CN as data sender
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.4. Proxy Scenario
The proxy scenarios refer 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 which
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 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.5. 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.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 42]
Internet-Draft NSIS Signaling in Mobility July 2007
- 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
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.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 43]
Internet-Draft NSIS Signaling in Mobility July 2007
8. Open Issues
1. Tearing Direction (Section 4.1)
- Direction of teardown in Figure 1 should be made compliant with
NSLP I-D. In Fig. 1, RESERVE (T) (message no. 9) is sent from CRN
towards QNI, as opposed to as indicated in the NSLP I-D: "RESERVE
messages MUST only be sent towards the QNR" (Section 5.4.1, para
2). However, this issue is still unclear.
Discussion: Does NSIS operation allow tearing down from QNR to
QNI?
2. MIP Interaction Part (Section 5)
- This section should illustrate how Tunnel I-D is applicable to
MIP cases.
Discussion: How does this section should be cleaned up?
3. NAT traversal
- When MN moves, IP address and routing are changed. In this
case, new NAT/FW pinhole need to be opened and old one should be
torn.
Discussion: When and how should NSIS tear old pinhole?
- In mobility scenario, it is possible that MN attaches to private
network, but it does not know whether the NAT is NSIS aware or
not. Therefore MN may need to set S-flag when it the attached
network is private.
Discussion: Does this need to be mentioned?
4. Security Considerations (Section 7
- This section still needs to be cleaned up.
Discussion: How does this section should be cleaned up?
Sanda (Ed.), et al. Expires January 10, 2008 [Page 44]
Internet-Draft NSIS Signaling in Mobility July 2007
9. Change History
9.1. Changes from -00 version
The major change made to the initial (-00) version of the draft is to
re-arrange the issues addressed in the draft in order to clearly
identify general issues caused by mobility itself and NSIS protocols-
specific issues. The generic route changes-related text in Section 4
was moved into Appendix to make this draft more mobility-specific.
Specifically, the following changes have been made:
1. Removed the terminologies, 'uplink' and 'downlink' in Section 2.
2. Removed the terminology, 'local repair' in Sections 2 and 4.
3. Re-arranged all problems in Section 3 by merging the 'mobility-
related issues with NSIS protocols' section and the 'problem
statement and general considerations' section.
4. Removed the general considerations section in Section 3.
5. Modified the problem statement section and moved it into the
general problem section in Section 3.1.
6. Added more problems including 'Identification of the crossover
node', 'Key exchanges', and 'AA-related Issues' to Section 3.1
7. Added the 'Multihoming-related issues' to Section 3.2.4
8. Removed the issues on 'how to immediately delete the state on
the old path' in Section 3.2.
9. Moved the generic route changes-related text in Section 4.1 into
Appendix.
10. Removed the figure describing "NSIS signaling topology for
downstream signaling flow after the route changes in the middle
of the network" in Figure 2.
11. Added 'NSLP_IDs' to each node in Figure 1.
12. Removed the 'use cases of identifiers' section, and instead,
added the 'support for ping-pong type handover' section to
Section5.
13. Added this change history.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 45]
Internet-Draft NSIS Signaling in Mobility July 2007
9.2. Changes from -01 version
Version -02 includes mainly a number of clarifications on the issues
raised in this draft and more details in some specific areas.
Specifically, the following changes have been made:
1. Defined the terminologies, 'route change' and 'mobility' in
Section 2.
2. Clarified the terminology, 'Crossover node (CRN)' in Section 2.
3. Removed the terminology, 'mobility CRN' in Section 2.
4. The issue, 'Priority of signaling messages' in Section 3.2.2 was
closed, and thus removed it.
5. Clarified the issue, 'CRN discovery and State Update on the IP-
tunneling path in Section 3.2.4.
6. Added the pros and cons of two mechanisms on CRN discovery
dependent on NSIS layers to Section 4.2.1.
7. Clarified the identifier, NSLP_Br_ID for CRN discovery in
Section 4.2.2.
8. Added the scenario on interaction between NSIS and Mobile IP to
Section 5.1.
9. Clarified interaction issues with IP-tunneling according to
reservation initiation type (receiver-initiated or sender-
initiated) in Mobile IPv4-based scenarios and added those to
Section 5.1.1.1.
10. 1Clarified interaction issues between NSIS protocols and IP-
tunneling in Mobile IPv6 and added those to Section 5.1.1.2.
11. Clarified the multihoming-related issues in Section 5.2.
12. Added the issues on usage of 'hint' information to trigger NSIS
signaling in mobility to Section 5.5.
13. Identified the dead peer-related issues in Mobile IP-based
scenario in Section 5.5.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 46]
Internet-Draft NSIS Signaling in Mobility July 2007
9.3. Changes from -02 version
In version -03, tunneling-related and multihoming-related scenarios
were newly added in Sections 5.1.3 and 5.2, respectively. Also, the
terminology, 'Path Update' is changed into 'State Update' in Section
3.2.4.
9.4. Changes from -03 version
Version -04 includes mainly a number of clarifications on the issues
raised in this draft and more details in some specific areas.
Specifically, the following changes have been made:
1. The issue, 'Peering agreement issue' in Section 3.2.2 was
closed, and thus removed it.
2. Clarified the issue, 'Interfaces between Mobile IP and NSIS
protocols' in Section 3.2.1.
3. Clarified the issue, 'Authorization-related issues with
teardown' in Section 3.2.2.
4. Clarified the issue, 'Dead peer discovery' in Section 3.2.2.
5. Clarified the issue, 'Invalid NR problem' in Section 3.2.2.
6. Clarified the issue, 'CRN discovery and State Update on the IP-
tunneling path' in Section 3.2.4.
7. Clarified the issue, 'Multihoming-related issues' in Section
3.2.4.
8. Changed Figure 1 (a) into (b) in Section 4.1.
9. Changed Figure 1 (b) into (a) in Section 4.1.
10. Clarified the identifier, NSLP_Br_ID for CRN discovery in
Section 4.2.2.
11. Clarified the identifier, Mobility identifier for CRN discovery
in Section 4.2.2.
12. Added the text on 'CRN_DISCOVERY flag bit' in Section 4.2.3, and
clarified the role of 'CD flag bit' in Section 4.3.1.
13. Clarified the issues on 'interaction with Mobile IP tunneling'
and added those to Section 5.1.4.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 47]
Internet-Draft NSIS Signaling in Mobility July 2007
14. Clarified the issues on 'load balancing in multihomed mobile
environments' and added those to Section 5.2.5.
15. Changed Problems of the heading name in Section 3.2 into
Challenges.
9.5. Changes from -04 version
Version -05 includes mainly a number of clarifications on the issues
raised in this draft and more details in some specific areas.
Specifically, the following changes have been made:
1. 'Explicit routes' in Section 3.1 (3) was removed.
2. Clarified the problem, 'Double reservation problem' in Section
3.1 (7).
3. Clarified the issue, 'CRN discovery-related issues' in Section
3.2.4 (1).
4. Clarified the issue, 'Issues on API between NTLP and NSLP' in
Section 3.2.4 (3).
5. Clarified the issue, 'approaches for CRN discovery' in Section
4.2.1.
6. Changed NSLP_Br_ID (of identifiers for CRN discovery) into
State_Br_ID in Section 4.2.2 for clarification.
7. Clarified the issue, 'double reservation problem on the common
path' in Section 4.3.1.
8. Clarified the issue, 'Interfaces between Mobile IP and NSIS' in
Section 5.1.1.
9. Removed the sencond paragraph on the issue, 'Explicit routes' in
Section 4.1.
10. Clarified the issue, 'refresh timer value in mobility scenarios'
in Section 5.3.
11. Removed the third paragraph on the issue, 'usage of Reservation
Sequence Number (RSN) to support ping-pong type hanover' in
Section 5.4.
12. Clarified the issues on 'peer failure' in Section 5.5.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 48]
Internet-Draft NSIS Signaling in Mobility July 2007
13. Removed Figure 3 'Sender- vs. Receiver-initiated reservation' in
Section 4.3.1.
9.6. Changes from -05 version
In Version -06, contents of this draft were re-selected and re-
structured:
1. Section 4 and 5 of -05 were divided into two parts:
1. 'Main' part, which is focusing on examples and describing how
mobility is handled by the NSIS protocols. Topics here will
be route change handling and NSIS interwork with MIP v4/v6
(Section 4 and Section 5 in -06)
2. 'Further Study' part, which introduces summary of potential
issues and possible approaches for other topics. These
topics are out-of-scope for discussing details (Section 6 in
-06)
2. Specific parameters and terms were removed from 'Main' part
3. Showing similar detailed operations were avoided in 'Interaction
with MIP tunneling section (Section 5.3)'
4. In Further Study section Section 6:
1. Detailed operations were removed
2. Ping-pong issue was removed
5. Problem Statement (Section 3) was cleaned up
9.7. Changes from -06 version
Changes in Version -06 are:
1. 'Invalid NR problem' are moved from Further Study section
2. Figure 7 (Receiver-Initiated QoS NSLP over Tunnel -Parallel Mode)
are changed
3. Terminologies 'NSLP CRN', 'NTLP CRN' 'NSIS CRN' 'Divergent-
convergent UCRN' and 'Divergent-convergent DCRN' are removed from
Terminology section.
4. 'Open Issues' section is added
Sanda (Ed.), et al. Expires January 10, 2008 [Page 49]
Internet-Draft NSIS Signaling in Mobility July 2007
10. Contributors
Sung-Hyuck Lee was the first editor of the draft. Since version 06
of the draft, Takako Sanda has taken the editorship.
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, Roland Bless and Shivanajay Marwaha. Separating
authors into two groups was done without treating any one of them
better (or worse) than others.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 50]
Internet-Draft NSIS Signaling in Mobility July 2007
11. Acknowledgements
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. The authors would also like to thank Robert Hancock, Andrew
Mcdonald, John Loughney, Rudiger Geib, Cheng Hong, Elena Scialpi, and
Pratic Bose for their useful comments and suggestions.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 51]
Internet-Draft NSIS Signaling in Mobility July 2007
12. References
12.1. Normative Reference
[1] Schulzrinne, H., "GIST: General Internet Signaling Transport",
Internet Draft draft-ietf-nsis-ntlp-13, Work in progress ,
April 2007.
[2] Manner, J., "NSLP for Quality-of-Service Signaling", Internet
Draft draft-ietf-nsis-qos-nslp-14, Work in progress ,
June 2007.
[3] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", Internet Draft draft-ietf-nsis-nslp-natfw-14, Work in
progress , March 2007.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Braden, B., "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC2205 , September 1997.
[6] Perkins, C., "IP Mobility Support for IPv4", RFC3344 ,
August 2002.
[7] Johnson, D., "Mobility Support in IPv6", RFC3775 , June 2004.
[8] Shen, C., "NSIS Operation Over IP Tunnels", Internet
Draft draft-ietf-nsis-tunnel-02, Work in Progress , March 2007.
12.2. Informative References
[9] Manner, J., "Mobility Related Terminology", RFC3753 ,
June 2004.
[10] Tschofenig, H., "NSIS Authentication, Authorization and
Accounting Issues", Internet
Draft draft-tschofenig-nsis-sid-00, Work in progress ,
June 2003.
[11] Wakikawa, R., "Multiple Care-of-Address Registration", Internet
Draft draft-ietf-monami6-multiplecoa-02, Work in progress ,
March 2007.
[12] Tschofenig, H., "NSIS Authentication, Authorization and
Accounting Issues", Internet
Draft draft-tschofenig-nsis-aaa-issues-01, Work in progress ,
March 2003.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 52]
Internet-Draft NSIS Signaling in Mobility July 2007
Appendix A.
The mobility occurs due to the change of the network attachment
point, but the generic route changes is associated with load sharing,
load balancing, or a link (or node) failure. 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.
The route changes brings on the change of signaling topology and it
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 18
Sanda (Ed.), et al. Expires January 10, 2008 [Page 53]
Internet-Draft NSIS Signaling in Mobility July 2007
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 18: The topology for NSIS signaling in case of the route
changes
Sanda (Ed.), et al. Expires January 10, 2008 [Page 54]
Internet-Draft NSIS Signaling in Mobility July 2007
Appendix B.
As described in 7 of Section 3, An old AR may trigger for tearing
down whole path before RESERVE from new location reaches to CRN.
NSIS approach is that GIST is conservative and careful in indicating
peer failure to the NSLP in mobile network.
Another possible implementation approach to enhance the operation is
that the MN informs AR (as adjacent QNE) or the CRN (including, HA
and MAP) of its' handover with some sort of policy beforehand or
afterward. Such a policy could, for example, indicate how it should
be processed in case the MN suddenly moves away, or how long the AR
may keep the QoS state after AR detects MN's handover (e.g., 30 sec.,
or until the MN moves back). In this case, the AR can be a proxy for
the MN (the last node) and it may be able to send RESPONSE messages
in response to REFRESH (or RESERVE) messages from an upstream node as
well as avoid causing unnecessary teardown. Still other possible
approach for latter case is the MN implicitly indicates which
massages are sent from the latest location, e.g., the MN may embed a
parameter to show the number of handover in the massages. By
comparing these numbers, the CRN can detect the latest massage and
avoid confusion.
Sanda (Ed.), et al. Expires January 10, 2008 [Page 55]
Internet-Draft NSIS Signaling in Mobility July 2007
Authors' Addresses
Takako Sanda
Matsushita Electric Industrial Co., Ltd. (Panasonic)
5-3, Hikarino-oka, Yokosuka City
Kanagawa 239-0847
Japan
Phone: +81 50 3687 6563
Email: sanda.takako@jp.panasonic.com
Xiaoming Fu
Computer Networks Group, University of Goettingen
Lotzestr. 16-18
Goettingen 37083
Germany
Email: fu@cs.uni-goettingen.de
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
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
Sanda (Ed.), et al. Expires January 10, 2008 [Page 56]
Internet-Draft NSIS Signaling in Mobility July 2007
Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich
81739
Germany
Email: Hannes.Tschofenig@nsn.com
Sanda (Ed.), et al. Expires January 10, 2008 [Page 57]
Internet-Draft NSIS Signaling in Mobility July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Sanda (Ed.), et al. Expires January 10, 2008 [Page 58]