Internet DRAFT - draft-cheng-nsis-multihoming
draft-cheng-nsis-multihoming
Next Steps in Signaling (nsis) H. Cheng
Internet-Draft T. Sanda
Intended status: Standards Track T. Ue
Expires: August 5, 2007 S. Marwaha
Panasonic
Feb 2007
NSIS Multihoming Support Issues
draft-cheng-nsis-multihoming-00.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 August 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Cheng, et al. Expires August 5, 2007 [Page 1]
Internet-Draft NSIS Multihoming Feb 2007
Abstract
The NSIS operation will be greatly affected by the multihoming
development in IETF such as Monami6, Shim6, etc. Solutions from
these groups introduce different architecture elements and
assumptions to the network layer, and thus render the current NSIS
protocols ineffective or irrelevant. This draft provides an analysis
of the multhoming scenarios that have impacts on the NSIS operation.
Requirements for NSIS multihoming support are derived from the
discussions of the NSIS applicability in these scenarios.
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. NSIS Applicability on Static Multihoming scenarios . . . . . . 6
4.1. Single CoA with multiple HoAs . . . . . . . . . . . . . . 6
4.1.1. Using bi-direction tunnel via home agents . . . . . . 6
4.1.2. Using Route Optimization . . . . . . . . . . . . . . . 8
4.2. Multiple CoAs with single HoA . . . . . . . . . . . . . . 10
4.2.1. Using bi-directional tunnel via home agents . . . . . 10
4.2.2. Using Route Optimization . . . . . . . . . . . . . . . 12
4.3. Multiple CoAs with Multiple HoAs . . . . . . . . . . . . . 14
5. Multihoming Scenarios with mobility . . . . . . . . . . . . . 15
5.1. Single CoA with multiple HoAs . . . . . . . . . . . . . . 15
5.1.1. Using bi-direction tunnel via home agents . . . . . . 15
5.1.2. Using Route Optimization . . . . . . . . . . . . . . . 15
5.2. Multiple CoAs with single HoA . . . . . . . . . . . . . . 15
5.2.1. Using bi-direction tunnel via home agents . . . . . . 16
5.2.2. Using Route optimization . . . . . . . . . . . . . . . 18
5.3. Multiple CoAs with a single HoA . . . . . . . . . . . . . 18
6. Problem statement for NSIS multihoming support . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Cheng, et al. Expires August 5, 2007 [Page 2]
Internet-Draft NSIS Multihoming Feb 2007
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [1].
Cheng, et al. Expires August 5, 2007 [Page 3]
Internet-Draft NSIS Multihoming Feb 2007
2. Introduction
Support of multihoming has become essential to the success of a
protocol in the mobile environment. With the integration of access
technologies and proliferation of multimode terminals, multihoming
scenarios are commonplace in modern networks. Naturally, use of
multihoming is viewed as a solution to provide ubiquitous and fault
tolerant access to the Internet with better user experience. Several
groups in IETF have set out to develop solutions on multihoming in
response to the market demand, e.g.Monami6 [2], Shim6 [3], etc.
However NSIS WG has yet to come up with an analysis of the impact of
these new developments.
New solutions developed in these WGs address only the data bearer
aspect of the multihoming. The signaling control aspect, the area
related to NSIS, is left unexplored. Although data bearer solutions
conceal multihoming details from upper layers, path coupled signaling
control still needs to work out the paths individually, e.g. multiple
end-to-end QoS NSLP signaling have to be carried out on all paths for
a load sharing case. Therefore, NSIS faces a more vibrant and
complicated environment when multihoming solutions are used, and
difference requirements would be placed on its operations.
This draft studies the multihoming scenarios and identifies operation
issues relevant to NSIS, i.e. multiple paths are used simultaneous
for a session. Requirements for the NSIS multihoming support are
derived from the discussion. As there are different multihoming
solutions in development, this draft does not concentrate on a
specific scheme. Instead, the scenarios studied are loosely based on
a more generic classification [9]. Requirements resulted from the
study could be used by the WG in defining necessary changes and
enhancement for NSIS protocols to support multihoming.
Cheng, et al. Expires August 5, 2007 [Page 4]
Internet-Draft NSIS Multihoming Feb 2007
3. Terminology
The Terminology defined in [4], applies to this draft. In addition,
the following terms are used:
CCRN: CN side CRN. Assuming MN is the multihoming node and CN is the
normal node, CCRN is the point where the multiple paths split. In
other words, between CN and CCRN, all the flows share the common
path.
MCRN: MN side CRN. This is the point where multiple paths join
before reaching MN. It should only exist when MN has a single CoA or
multiple CoA belonging to the same subnet.
HCRN: Home Agent side CRN. Assuming MN is the multihoming node, HCRN
is the point where the multiple paths split when reverse tunneling is
used. Between HA and the MCRN (in turn between CN and MCRN), all the
flows share the common path.
TCRN: Transient CRN. This is a crossover node between the new path
and the old path due to the MN's mobility. It is equivalent to the
normal CRN definition in Mobility Applicability I-D [5]. In certain
scenarios, the TCRN could collocate with the CCRN, MCRN, or HCRN. In
other scenarios, the TCRN could be different from either of the other
CRNs.
Cheng, et al. Expires August 5, 2007 [Page 5]
Internet-Draft NSIS Multihoming Feb 2007
4. NSIS Applicability on Static Multihoming scenarios
This section analyzes NSIS applicability on various multihoming
scenarios based on current NSIS specifications.
IP level multihoming could result from varies reasons. For example,
a node may use the site multihoming solution to achieve redundancy or
load sharing [6]. A multimode terminal may also access services
simultaneously via both interfaces.
However, not all IP level multihoming scenarios require special
functions for the path-coupled signaling, e.g. NSIS. For example,
if an application session only makes use of one fixed path, it
obviously has no difference from a normal single-homed scenario.
Therefore, in the following scenario analysis, focus is placed on
cases where the different paths are used for the same session or
related sessions.
The scenarios are presented using Mobile IPv6 related cases as
examples. However, this does not imply the issues are only limited
to MIPv6. Similar issue exists even for fixed nodes communications.
The relevance to fixed node cases is covered in detail analysis in
each subsection.
4.1. Single CoA with multiple HoAs
This scenario happens when a single interface device has multiple
subscription profiles and tries to use them all for the same
application session. Another possible case is when a multiple
interface device has one link down, and makes use of the live
interface as if it roamed.
4.1.1. Using bi-direction tunnel via home agents
In this scenario, when current NSIS operation procedure is followed,
e.g. QoS NSLP [4] and NSIS Tunneling [7], session binding
information may get lost over the path from different HAs to the MN.
Details of the issue are presented with the example below.
Figure 1 shows an example of the scenario and the possible data
paths. A MN having two HoAs, HoA-a and HoA-b obtained from HA1 and
HA2 respectively, is communicating with a CN via the bi-directional
tunnel through the Home Agents, i.e. HA1 and HA2. Data path from CN
towards the two Home Agents splits at CCRN; and tunneled data paths
from the two Home Agents to the MN merges at MCRN.
Cheng, et al. Expires August 5, 2007 [Page 6]
Internet-Draft NSIS Multihoming Feb 2007
+--+
|CN|
+--+
ab
ab
+----+
aaaaaaa|CCRN|bbbbbbb
a +----+ b
a b
+---+ +---+
|HA1| |HA2|
+---+ +---+
A B
A +----+ B
AAAAAAA|MCRN|BBBBBBB
+----+
AB
AB
+--+
|AR| aaaaa Path between CN and HA1
+--+ AAAAA Bi-directional tunnel between
AB MN and HA1
AB
+--+ bbbbb Path between CN and HA2
|MN| BBBBB Bi-directional tunnel between
+--+ MN and HA2
Figure 1. CoA, Multiple HoA, with bi-directional tunnel
Obviously, as shown in the figure, the two home addresses of the MN
are visible to the CN. Therefore, multihoming schemes are necessary
at CN to support the communication, e.g. SCTP or Shim6.
When applying NSIS signaling over the data paths, two different End-
to-End (E2E) flows should be used, due to the two home addresses (of
MN) and thus two paths towards MN. Between CN and HA1, FlowID-a is
used; and between CN and HA2, FlowID-b is used. As for the Session
Identifier, one has the choice of using a single SID or different
SIDs.
In the above scenario, when the signaling initiator is CN, e.g. CN
is QNI, binding of the two flows is problematic between the MCRN and
MN if operation specified in Tunneling Draft I-D [7] is followed.
When two different SIDs were used, e.g. SID-a and SID-b, a
BOUND_SESSION_ID would be included into the E2E signaling messages.
Cheng, et al. Expires August 5, 2007 [Page 7]
Internet-Draft NSIS Multihoming Feb 2007
For example, message sent to HA1 is using a Session Identifier SID-a,
and having a BOUND_SESSION_ID of value SID-b. Therefore, over the
common path, i.e. from CN to CCRN, the two sessions would be bound as
desired. However, when the E2E message reaches the home agents,
tunneling operation would apply. According to Tunneling Draft I-D
[7], a new tunnel session, say SID-A, will be created at HA1; and the
E2E signaling message would be tunneled towards the tunnel end point,
i.e. MN, with a BOUND_SESSION_ID object set to SID-A included.
Similarly, at HA2, a new tunnel session SID-B will be created for the
E2E signaling session SID-b, and the E2E signaling message would be
tunneled towards MN with a BOUND_SESSION_ID object set to SID-B.
Obviously, the two sessions created for the tunnel sections are no
longer bound, since no BOUND_SESSION_ID is carried in the tunnel
session messages. Moreover, there is no existing method for the two
tunnel entry points, i.e. HA1 and HA2, to exchange the new SID
information. Therefore, even if BOUND_SESSION_ID object is allowed
for tunnel session messagess, no correct value could be set.
When a single SID was used for the two E2E flows, e.g. SID-ab, no
BOUND_SESSION_ID object would be necessary for the E2E flow
signaling. However, proper flags need to be set to indicate their
relationships. For example, for QoS NSLP [4] messages, the REPLACE
flag should be unset in messages of both flows. Similarly, at the
home agents, if new sessions are created for the tunnel paths, no
BOUND_SESSION_ID would be present in the tunnel signaling. This
again leaves the two tunnel sessions unbound.
When generalized, the above problem could be state as: two flows
would lose their binding relationship if both go through tunnels via
different tunnel entry points. This would be a major issue for
multihoming devices, where using multiple paths for load sharing is
common.
4.1.2. Using Route Optimization
In this scenario, it is possible that different flows share the same
MRI after address swapping for Route Optimization, i.e. original
flows are only differentiated by home address. In this case, NSIS
needs to interact with Mobile IP stack to trigger aggregation when
necessary, so that signaled specification could be enforceable.
Following example provides further discussion of the issue.
Figure 2 shows the scenario when the CN support Route Optimization
(RO). Since the MN has only one CoA, IP address alone would not
separate the two flows. Therefore, CCRN and MCRN only exist if
routing is based on higher layer information, e.g. port number, etc.
Cheng, et al. Expires August 5, 2007 [Page 8]
Internet-Draft NSIS Multihoming Feb 2007
+--+
|CN|
+--+
cd
cd
cd
+----+
ccccccc|CCRN|ddddddd
c +----+ d
c d
c d
c d
c +----+ d
ccccccc|MCRN|ddddddd
+----+
cd
cd
+--+
|AR| ccccc RO Path for HoA-a
+--+
cd ddddd RO Path for HoA-b
cd
+--+
|MN|
+--+
Figure 2. Single CoA, Multiple HoAs, with Route Optimization
In certain cases, the two flows may have identical MRIs. For
example, CN and MN use the same higher layer port number for the
application. This is highly possible for applications based on
connectionless transport, e.g. UDP. For such cases, QNEs on the
path will have difficulty to distinguish packets from the two flows,
since the normally used classifier does not check the Type 2 Routing
Headers.
Obviously, aggregation is necessary at the end host since the
intermediary QNEs has no way to enforce QoS for the flows separately.
Therefore, NSLP layer signaling application needs to monitor the MRI
in use at the end hosts. When the same MRI is used for a new flow,
aggregation mechanisms should be triggered. Thus, NSIS must have
interaction with the Mobile IP stack and cannot allow transparent
operations.
Cheng, et al. Expires August 5, 2007 [Page 9]
Internet-Draft NSIS Multihoming Feb 2007
4.2. Multiple CoAs with single HoA
This scenario would apply to single interface MNs as well as multi-
interface MNs. It is natural that multiple interfaces of a MN would
obtain different IP address when used simultaneously. For a single
interface MN, it is still possible to have multiple IP addresses when
it is used in a site-multihoming network. To use the CoAs for the
same HoA requires some enhancement [8] for MIP. Details are analyzed
in the following sub-sections.
In the static case, i.e. no mobility event, there is no difference in
the scenario regardless if MN has a single or multiple interfaces.
However, more complicated mobility scenarios are possible with multi-
interface MNs. These will be discussed in section 5.2.
4.2.1. Using bi-directional tunnel via home agents
In this scenario, when CN is the QNI, special functionalities should
be provided by the Home Agents, e.g. the multiplexing of signaling
messages, indicating binding relationship of the different paths,
etc. When MN is the QNI, the Home Agent only needs to merge the
different signaling messages. Following example illustrated this
clearly.
Figure 3 shows the possible data paths when multiple CoAs are used
for a single HoA. Assuming MN obtained two CoAs, CoA-a and CoA-b
respectively, using them simultaneously requires registering the two
CoAs with the same Home Agent. In order to achieve this, the
Multiple CoA Registration enhancement [8] needs to be supported at
HA.
In this scenario, CN is unaware of the multiple addresses involved in
the communication. Therefore, special NSIS signaling management
functions are necessary at the HA.
Cheng, et al. Expires August 5, 2007 [Page 10]
Internet-Draft NSIS Multihoming Feb 2007
+--+
|CN|
+--+
aa aaaaa Path from CN to HA
aa aaaaa
aa
+--+ AAAAA Tunnel path from HA
|HA| to CoA-a
+--+
AB
AB BBBBB Tunnel path from HA
AB to CoA-b
+----+
AAAAAAAA|HCRN|BBBBBBBB
A +----+ B
A B
A B
+---+ +---+
|AR1| |AR2|
+---+ +---+
A B
A B
A +--+ B
AAAAAAAAA|MN|BBBBBBBBB
+--+
Figure 3. Multiple CoAs, Single HoA, with Bi-direction tunnel
When the signaling is initiated by the CN, e.g. CN being the QNI,
only one signaling session is created, since to CN, there is only one
MN address, the HoA. Therefore, the E2E signaling from CN towards MN
will carry a SID, say SID-a, and a FlowID derived from MN's HoA, say
FID-a. When this E2E signaling message arrives at HA, flow filtering
rules would apply to the FlowID to decide the path (CoA).
For example, if the application session makes use of two ports,
Port-A and Port-B, and the filtering rule at HA may be set such that
packets for Port-A is to be sent to CoA-a and packets for Port-B is
to be sent to CoA-b. Obviously, the FlowID would cover both Port-A
and Port-B. Therefore, when applying the filtering rule to the
FlowID, all matches should be identified, instead of stopping at the
first match as for processing normal data packet.
In the above example, HA would identify two CoAs for the FlowID of
the received E2E signaling message. This means data flow for the
session may go via both paths. The HA would need to create signaling
Cheng, et al. Expires August 5, 2007 [Page 11]
Internet-Draft NSIS Multihoming Feb 2007
session for both of the tunnel paths, e.g. SID-A and SID-B.
Adjustment of the signaling application data, e.g. QSPEC, is
necessary. However, information for such adjustment might not be
available at HA, e.g. how many percent of the traffic goes to Port-A,
and thus CoA-a. Therefore, collaboration of MN is required, i.e. for
the tunnel sessions, MN should be the QNI.
Lastly, when forwarding the E2E signaling message to MN, HA could
choose to send one copy of the message over any of the path, carrying
two BOUND_SESSION_IDs set to SID-A and SID-B respectively.
Alternatively, HA could duplicate the E2E signaling message and send
one over each of the two paths. In this case, a special flag is
necessary to indicate to the MN how to treat the message
duplications.
When the signaling is initiated by MN, e.g. MN being the QNI,
operations would be subtle. MN can initiate two flows, using either
two SID and BOUND_SESSION_ID objects, or using one SID and two
FlowIDs with REPLACE flag unset. Normal tunnel operation defined in
[7] is sufficient for the paths between MN and HA. The HA however,
needs to merge the two flows, and presents one single signaling
towards the CN.
4.2.2. Using Route Optimization
In this scenario, current defined NSIS procedure is adequate to deal
with the multiple paths, e.g. either using multiple SID with
BOUND_SESSION_ID objects, or using the same SID and unsetting REPLACE
flag.
Figure 4 shows the possible route optimized data paths when multiple
CoAs are used for a single HoA. In this case, MN uses the two CoA,
CoA-a and CoA-b, to communicate with CN directly. The two data paths
merge at the CN side CRN (CCRN). Obviously, to support this
scenario, CN needs to implement certain enhancement of the Mobile IP,
e.g. the Multiple CoA Registration [8].
Cheng, et al. Expires August 5, 2007 [Page 12]
Internet-Draft NSIS Multihoming Feb 2007
+--+
|CN|
+--+ aaaaa Path from CN to CoA-a
ab
ab
ab bbbbb Path from CN to CoA-b
ab
+----+
aaaaaaaa|CCRN|bbbbbbbb
a +----+ b
a b
a b
+---+ +---+
|AR1| |AR2|
+---+ +---+
a b
a b
a +--+ b
aaaaaaaaa|MN|bbbbbbbbb
+--+
Figure 4. Multiple CoA, Single HoA, with Route Optimization
In this case, the CN is aware of the two flows used in the transport.
However, the use of multiple addresses is transparent to applications
above the IP layer due to the use of Mobile IP.
As shown in Figure 4, the two paths have different destination
addresses. Therefore, two different MRIs are required for the NSIS
signaling, i.e. separate signaling should be carried out for the two
paths. As the two paths are used for the same application level
session, user might want to create certain association between them,
e.g. for resource sharing and better signaling state management.
This could be achieved by using the same Session ID for the two
flows, or using different Session ID and BOUND_SESSION_ID object in
the signaling message.
In case the same Session ID is used, the REPLACE flag should be unset
in the QoS NSLP message so that the QNEs along the path between CN
and CCRN could distinguish this from a mobility event. The RMF on
those QNEs could decide the proper treatment for the two flows, e.g.
allow sharing of the resources, etc. This does not require any
special functionality for the QoS NSLP signaling and state machine
management.
In case different Session IDs are used, at least one of the flow's
Cheng, et al. Expires August 5, 2007 [Page 13]
Internet-Draft NSIS Multihoming Feb 2007
signaling messages should carry a BOUND_SESSION_ID object that
indicates the Flow ID used by the flow. In this case, the common
QNEs follow procedures specified in QoS NSLP [4] regarding the
session binding.
4.3. Multiple CoAs with Multiple HoAs
This scenario is basically a combination of the scenarios introduced
in section 4.1 and 4.2, i.e. Single CoA with multiple HoAs, and
Multiple CoAs with single HoA. Therefore, all the issues discussed
earlier apply here. Besides the above issues, new requirements on
efficient path selection would apply as well.
The new requirements arise due to the multiple potential paths
between the CN and MN. Generally, for a MN of m CoAs and n HoAs, the
number of possible paths is m*n. Therefore, picking the right path
combination for the application session becomes an issue. Carrying
end-to-end queries over all the possible paths obviously has high
overheads and causes long delay in path setup. Optimization is
desired for expediting the path selection process.
When Route optimized path is used in this scenario, the number of
possible data path is largely determined by the number of CoAs used
by the MN. In this case, one CoA could be shared by multiple HoAs.
Therefore, issues discussed in section 4.1.2 also apply here.
Cheng, et al. Expires August 5, 2007 [Page 14]
Internet-Draft NSIS Multihoming Feb 2007
5. Multihoming Scenarios with mobility
This section analyzes multihoming scenarios introduced in section 4
when mobility events are considered. Same subsection structure as
section 4 is maintained, so that cross reference could be done
easily.
5.1. Single CoA with multiple HoAs
Static case of this configuration is introduced in section 4.1. In
this section, focus is on the mobility aspect of the operation.
5.1.1. Using bi-direction tunnel via home agents
Since the MN has only one CoA, change of the location results in
change of paths from MN to all Home Agents. However, this change
should only affect the tunnel section between MN and its Home Agents.
The end to end section, i.e. from CN to Home Agents, should not be
altered. Therefore, the change of the CoA should not trigger updates
of the path for end to end section.
5.1.2. Using Route Optimization
When Route Optimization paths are used for the communication, there
is essential one address pair in use, as shown in Figure 2.
When the MN changes CoA (results from a mobility event), both paths
will change. Therefore, multiple signaling messages need to be sent
to update the paths. Signaling optimization is desired to avoid a
surge in the signaling, especially when MRIs are identical. Using
aggregation would help in this aspect.
5.2. Multiple CoAs with single HoA
As discussed in section 4.2, to support this scenario requires
extension of the Mobile IP stack, e.g. the multi-CoA Registration
enhancement.
In this scenario, the multiple CoAs of the MN may change
independently. For example, a MN that is handing over to another
WiFi hotspot may keep the CoA assigned to its WiMAX access.
Issues arise from this independence in mobility as current NSIS
message does not indicate such relationships between sessions.
Details of the issue are analyzed in the following subsections using
examples.
Cheng, et al. Expires August 5, 2007 [Page 15]
Internet-Draft NSIS Multihoming Feb 2007
5.2.1. Using bi-direction tunnel via home agents
In this scenario, due to the MN mobility and multihoming, different
types of CRN would be generated. To distinguish these CRNs is
essential for the correct signaling of the flows.
As shown in Figure 5, MN originally has two CoAs, CoA-a and CoA-b,
used for the communication with CN via the Home Agent (HA). Assuming
the HA supports the mCoA extension of Mobile IP, MN registers both
CoAs with the HA. CN is unaware of the multiple CoAs used for the
communication.
The two tunnel paths from HA to MN split at node HCRN. Thus, path
between HA and HCRN are shared by the two flows. As indicated in
section 4.2.1, there are two possible ways of signaling the
relationship of the two flows, using the same SID or different SIDs.
At certain point of time, MN obtains a new CoA for one of its
interface, say CoA-c, and registers it with HA to replace an existing
CoA. As shown in Figure 5, path from the new CoA-c to the HA (marked
with 'C') joins the path from CoA-A to HA (marked with 'A') at TCRN,
and in turn joins the path from CoA-b to HA (marked with 'B') at
HCRN.
In case the CoA-c is to replace CoA-a, path marked 'B' and 'C' should
co-exist, and path marked 'A' should be torn down. Therefore, the
signaling message for path 'C' should include information to allow
TCRN identifying the relationship of the two paths ('C' replace 'A'),
and at the same time, it should also allow HCRN identifying the other
relationship ('C' does not replace 'B').
In case the CoA-c is to replace CoA-b instead, path marked 'A' and
'C' should co-exist, and path marked 'B' should be torn down.
Therefore, signaling message for path 'C' should contain information
for TCRN and HCRN to draw different conclusion as in the above
example.
However, the current NSIS signaling message does not contain
information to that effect. Detail analysis for cases where the same
SID is used and different SIDs are used is provided below.
Cheng, et al. Expires August 5, 2007 [Page 16]
Internet-Draft NSIS Multihoming Feb 2007
+---+
|CN |
+---+
a aaaaa Path from CN to HA
a
a
+---+ AAAAA Tunnel path from HA
|HA | to CoA-a
+---+
ABC
ABC BBBBB Tunnel path from HA
ABC to CoA-b
+----+
AAAAAAAA|HCRN|BBBBBBBB
ACCCCCCC+----+ B BBBBB Tunnel path from HA
AC B to CoA-c
+----+ B
AAAA|TCRN|CCCC B
A +----+ C B
A C B
+---+ +---+ +---+
|AR1| |AR3| |AR2|
+---+ +---+ +---+
A C B
A +---+ B
AAAAAAAAAAA|MN |BBBBBBBBBBBB
+---+
Figure 5. Mobility scenario for MN with multi-CoA and single HoA
When the same SID is used for all the tunneled paths between HA and
MN, special techniques are required. For example, the REPLACE flag
in the QoS NSLP message for path 'A' and 'B' should be unset, so that
QNEs on the common path do not initiate tear-down of the other path.
Problem arises when the signaling message for path 'C' comes in. If
the REPLACE flag is also unset in this message, those QNEs would not
know path 'C' is replacing one of the paths. However, if the REPLACE
flag is set, it might cause QNE to replace state for both path 'A'
and 'B' with that for path 'C'. A more detailed analysis of this
case is available in Mobility Applicability draft section 5.2.5 [5].
Solving this problem might require some extra identifier to indicate
the relationships. The BID introduced in [8] would be a good
candidate for such use.
When different SIDs are used for tunneled paths, signaling message
for path 'C' should take the same SID as that of path 'A' if CoA-c is
Cheng, et al. Expires August 5, 2007 [Page 17]
Internet-Draft NSIS Multihoming Feb 2007
replacing CoA-a. (And, it should take the same SID as that of path
'B' if CoA-c is replacing CoA-b.) The REPLACE flag of the QoS NSLP
message should be set. Therefore, QNEs on the common path would
properly update the QoS states.
Session Binding might pose a problem for the different SIDs case.
When different SIDs are used for path 'A' and 'B', they should be
bound using BOUND_SESSION_ID object. Therefore, when path 'C'
replaces one of the paths, say path 'A', it shall not cause the
removal of the other path, e.g. path 'B'. Therefore, the
BOUND_SESSION_ID also needs to have certain type indication for this
case.
5.2.2. Using Route optimization
In mobility aspect, this case is quite similar to that described in
section 5.2.1. Replacing the HA with CN in Figure 5, it could
represent the possible data path of this case. Therefore, the
problems discussed above would generally apply to this case also.
5.3. Multiple CoAs with a single HoA
This is a complicated scenario that encompasses all possible
combinations of cases described in section 5.1 and 5.2. Therefore,
issues discussed in these sections would also apply here.
Cheng, et al. Expires August 5, 2007 [Page 18]
Internet-Draft NSIS Multihoming Feb 2007
6. Problem statement for NSIS multihoming support
As analyzed in section 4 and 5, current NSIS signaling has some
glitches when dealing with the multihoming systems. A summary of the
functionalities that is lacking or needs to be provided by NSIS is
provided below:
- Reflecting session binding relationship when tunneling is used. As
discussed in section 4.1.1, when bounded session passing through
tunnels separately, the created tunnel sessions should also be bound.
- Interaction with Mobile IP stack should trigger aggregation
mechanism when same MRI is resulted for different sessions. As
discussed in section 4.1.2, it is possible that multiple sessions
have the same MRI when Route Optimization is used. Session
aggregation at end host would be necessary since intermediary QNEs
has no way to separate the flows.
- Signaling multiplexing at Home Agents when multihoming is supports.
As discussed in section 4.2.1, CN could be unaware of the multiple
CoA address used by MN. Therefore, only one session would be
initiated by CN, and HA needs to perform multiplexing accordingly.
- Expedited path query and selection. As discussed in section 4.3,
there could be large number of potential paths used for the
application session. In order to achieve faster transition and less
service interruption, faster path query would be desired.
- Distinguish path relationships in mobile environment. As discussed
in section 5.2.1, signaling message should contain information to
indicate relationship with the existing paths (replace or coexist) in
the multi-path environment.
- Indicating the type of binding for the multihoming support. As
discussed in section 5.2.1, such indicating would be necessary to
avoid accidental removal of the parallel sessions.
Cheng, et al. Expires August 5, 2007 [Page 19]
Internet-Draft NSIS Multihoming Feb 2007
7. Security Considerations
Generally, the signaling security is covered with the current NSIS
protocol design [7][4]. However, when work in the multihoming
environment, a few other security issue arises. For example,
multiple flows from different IP address are bound and share the
resources in multihoming scenarios. This would require authorization
schemes that does not relying on IP address as the user identity.
Other than that, some of the intermediary nodes, e.g. the Home Agent,
may have extended access to the e2e signaling message. This would
require new security measures to counter possible attacks.
These security issues would be considered in future version of the
draft.
Cheng, et al. Expires August 5, 2007 [Page 20]
Internet-Draft NSIS Multihoming Feb 2007
8. Conclusion
This draft provides a scenario by scenario analysis of the NSIS
applicability in multihoming environment. Operation issues were
identified in the discussion. Causes of the issues and relevant
requirements on NSIS are summarized at the end of the draft.
Studying those functionalities identified as lacking in the current
NSIS would provide directions for extending NSIS's coverage for an
emerging area.
Cheng, et al. Expires August 5, 2007 [Page 21]
Internet-Draft NSIS Multihoming Feb 2007
9. Acknowledgements
This section contains the acknowledgements.
Cheng, et al. Expires August 5, 2007 [Page 22]
Internet-Draft NSIS Multihoming Feb 2007
10. References
10.1. Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] IETF, "Mobile Nodes and Multiple Interfaces in IPv6 (monami6)",
WG Charter
http://www.ietf.org/html.charters/monami6-charter.html,
Dec 2006.
[3] IETF, "Site Multihoming by IPv6 Intermediation (shim6)", WG
Charter http://www.ietf.org/html.charters/shim6-charter.html,
May 2006.
[4] Manner, J., "NSLP for Quality-of-Service Signaling", Internet
Draft: draft-ietf-nsis-qos-nslp-12, Work in progress ,
Oct 2006.
[5] Lee, S., "Applicability Statement of NSIS Protocols in Mobile
Environments", Internet Draft:
draft-ietf-nsis-applicability-mobility-signaling-05, Work in
progress , June 2006.
[6] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
multihoming Architectures", BCP 14, RFC 3582, August 2003.
[7] Shen, C., "NSIS Operation Over IP Tunnels", Internet Draft:
draft-ietf-nsis-tunnel-01, Work in Progress , Oct 2006.
[8] Wakikawa, R., "Multiple Care-of-Address Registration", Internet
Draft: draft-ietf-monami6-multiplecoa-01, Work in progress ,
Oct 2006.
10.2. Informative References
[9] Montavont, N., "Analysis of Multihoming in Mobile IPv6",
Internet Draft: draft-ietf-monami6-analysis-01, Work in
progress , Oct 2006.
Cheng, et al. Expires August 5, 2007 [Page 23]
Internet-Draft NSIS Multihoming Feb 2007
Authors' Addresses
Hong Cheng
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534415
Singapore
Phone: +65 6550 5477
Email: hong.cheng@sg.panasonic.com
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
Toyoki Ue
Matsushita Electric Industrial Co., Ltd. (Panasonic)
5-3, Hikarino-oka, Yokosuka City
Kanagawa 239-0847
Japan
Phone: +81 50 3687 6562
Email: ue.toyoki@jp.panasonic.com
Shivanajay Marwaha
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534415
Singapore
Phone: +65 6550 5414
Email: shivanaja.marwaha@sg.panasonic.com
Cheng, et al. Expires August 5, 2007 [Page 24]
Internet-Draft NSIS Multihoming Feb 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).
Cheng, et al. Expires August 5, 2007 [Page 25]
