Internet DRAFT - draft-lee-nsis-multihoming-mobility
draft-lee-nsis-multihoming-mobility
IETF Next Steps in Signaling S. Lee
Internet-Draft S. Lee
Expires: January 12, 2006 Samsung AIT
S. Jeong
HUFS
J. Bang
BJ. Lee
Samsung AIT
July 11, 2005
NSIS Signaling Protocols in Multihomed Mobile Networks
draft-lee-nsis-multihoming-mobility-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 January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
A host that is an initiator or responder of NSIS signaling messages
can be not only mobile but also multihomed. Multihomed hosts and
scenarios may be common in the future IPv6-based Internet. Benefits
Lee, et al. Expires January 12, 2006 [Page 1]
Internet-Draft NSIS Signaling in Multihoming July 2005
of multihoming include increased bandwidth, load balancing, load
sharing, ubiquitous access, bi-casting, resilience, and etc. NSIS
signaling should be able to support various multihoming scenarios.
This draft describes NSIS operations and applicability in multihomed
environments.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation and Terminology . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. NSIS operations in multihomed networks . . . . . . . . . . . . 6
4.1 Considerations on multihomed mobile networks . . . . . . . 6
4.2 Receiver-initiated reservation in the multihomed
environment . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1 BU and QUERY message transmission . . . . . . . . . . 7
4.2.2 Intermediate node operation . . . . . . . . . . . . . 8
4.2.3 Primary CoA selection . . . . . . . . . . . . . . . . 9
4.2.4 Reservation re-establishment and teardown . . . . . . 9
4.3 Sender-initiated reservation in the multihomed
environment . . . . . . . . . . . . . . . . . . . . . . . 10
5. NSIS Applicability in multihomed scenarios . . . . . . . . . . 10
5.1 Link/node failure . . . . . . . . . . . . . . . . . . . . 10
5.2 Load balancing . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Load Sharing . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1 Normative References . . . . . . . . . . . . . . . . . . . 13
6.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 16
Lee, et al. Expires January 12, 2006 [Page 2]
Internet-Draft NSIS Signaling in Multihoming July 2005
1. Introduction
Multihoming refers to a situation where an end node has several
parallel communication paths to use. An end node (e.g., mobile node
(MN) in mobile environments) may integrate several wireless access
technologies (thus, multiple interfaces). One of the main purposes
of having multiple interfaces is to utilize all means of
communications to access the Internet ubiquitously. In such
multihomed environments, flows may be redirected from one interface
to the other due to the sudden lack of connectivity or change of the
network conditions.
Multiple interfaces can also be used in order to increase bandwidth
availability or to select the most appropriate interface according to
the type of flow or choices of the user [8]. Basically, each network
interface has different performance, bandwidth, access range, and
reliability. Users may want to select the most appropriate set of
network interface(s) depending on the network environment,
particularly in wireless networks which are less reliable than wired
networks. Users may also want to select the most appropriate
interface based on certain criteria or to combine a set of interfaces
to get sufficient bandwidth [8]. Other benefits of multihoming
include load balancing, bi-casting, preference, load sharing, and
etc.
In multihomed environments, multiple addresses can be allocated to
either a single interface or multiple interfaces to provide
ubiquitous, permanent and fault-tolerant access to the Internet,
particularly on mobile nodes which are prone to failure or loss of
connectivity.
NSIS signaling should be able to support various multihoming
scenarios as described in [3],[5]. This draft describes NSIS
operations and applicability in multihomed environments. The
remainder of this draft is organized as follows. Section 2 defines
the terms used in the draft, and Section 3 illustrates the problems
regarding multihoming in mobile environments from the NSIS point of
view. Section 4 analyzes NSIS operations in multihomed environments,
and Section 5 describes a few NSIS applicability scenarios in the
multihomed networks.
2. Requirements Notation and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
Lee, et al. Expires January 12, 2006 [Page 3]
Internet-Draft NSIS Signaling in Multihoming July 2005
This draft is based on the terminology defined in [2], [3], [4], [5].
In addition, the following terms are used.
(1) Interface
A node's point of attachment to a link
(2) Multihomed Node
A node (either a host or a router) is multihomed when it has
multiple homogeneous/heterogeneous interfaces.
(3) Multihomed Network
A network is multihomed when either the network is simultaneously
connected to the Internet via more than one router, or when a
router is multi-interfaced.
3. Problem Statement
This section describes possible issues on NSIS signaling in the
multihomed environments.
The general problems caused by mobility are as follows.
o Notification of alternative path
A mechanism is needed to inform the other end (HA or CN) of the
communication about the alternative path that is to be used for a
certain purpose, e.g., load balancing or bandwidth increase.
Alternative paths may be represented by alternative CoAs in
mobility scenarios. The mechanism should provide a way to convey
such alternative CoAs.
o Path Failure Detection
When an active path (for NSIS signaling and data flows) failure
occurs, the MN should be able to detect outages in the path that
is currently being used.
o Registration of Multiple CoAs
With MIPv6, an MN may have several CoAs, but only one, termed the
primary CoA, can be registered with its home agent (HA) and the
correspondent nodes (CNs). However, for purposes of bandwidth,
delay, or others, it is useful for the MN to get Internet access
Lee, et al. Expires January 12, 2006 [Page 4]
Internet-Draft NSIS Signaling in Multihoming July 2005
through multiple access media simultaneously, in which case
multiple active CoAs would be assigned to the MN.
o Interworking between resource reservation and binding update
When the MN has multiple CoAs, those CoAs may be sent to the HA
together with the binding update request message for immediate QoS
re-establishment. When to send the CoAs during the binding update
procedure should be optimized for reducing state setup delay.
o Media detection
IPv6 has no clearly defined mechanism for detecting the
availability or loss of media except through the ability or
inability to receive router advertisements within a stipulated
period. An efficient way to detect media loss should be provided
so that the redirection between interfaces can be performed
quickly to support seamless services. Media detection can be used
to trigger necessary NSIS operations.
o Heterogeneous wireless interfaces
Several heterogeneous wireless interfaces can be integrated to
increase bandwidth availability or to select the most appropriate
technology (or interface) according to the type of flow or choices
of the user. It should be possible to select the most appropriate
interface based on certain criteria or to combine a set of
interfaces to get sufficient bandwidth.
o Selection of the Optimal CoAs for QoS
AIn a scenario where an MN has multiple registered CoAs, it might
be necessary to select the optimal CoAs associated with the
optimal paths for QoS purposes (e.g., bandwidth, delay, etc.). In
this case, HAs should be able to decide the optimal CoAs before
the binding update is completed. The choice of CoAs should be
based on certain criteria.
o Route Optimization in multihomed environments
In the situation where route optimization is used to avoid the
triangular routing and tunneling-related problems, the CN should
be able to perform the registration of multiple CoAs, selection of
the best CoA to determine the route optimization path.
o Anticipated handover support
An MN may have access to multiple interfaces in heterogeneous
Lee, et al. Expires January 12, 2006 [Page 5]
Internet-Draft NSIS Signaling in Multihoming July 2005
networks, and it can be connected to the old access router through
the existing interfaces during handover to support seamless
services. Therefore, multihoming can be used in the situation
where the anticipated handover is needed. This approach is more
plausible in heterogeneous network rather than in homogeneous
networks.
4. NSIS operations in multihomed networks
In multihomed environment, multiple interfaces and addresses (i.e.,
CoAs and HoAs) are available and thus how to select or acquire most
appropriate interface and/or address is of great concern [9]. One of
the NSIS's goals is to achieve end-to-end signaling for various
signaling applications. However, some reasons such as existence of
NAT/FW, scarce wireless resources, usage of tunneling, and frequent
change of end host's address make it difficult for NSIS signaling to
achieve end-to-end signaling. In this case, the interaction with the
multihoming schemes and NSIS signaling protocols could alleviate
issues caused by wireless bottleneck and mobility events. In this
section, we discuss some NSIS signaling issues on interworking with
multihomed networks and also present on how NSIS signaling should
perform multihomed signaling in mobility scenarios.
4.1 Considerations on multihomed mobile networks
In order to achieve the multihomed QoS signaling, the MN would need
to register several CoAs with unique HoA. However, since the present
specification of MIPv6 only allows the MN to register a single CoA
per HoA, a solution like [6] needs to be used for multiple CoAs
registration. On the other hand when the MN has more than one HoA
given either by one HA or multiple HAs, multiple CoAs registration
may not happen because each CoA could be bound with single HoA.
Throughout the scenario in this draft, we assumed that an appropriate
multiple CoAs registration mechanism is provided.
When a route optimization is used a direct connection is established
between an MN and a CN, in which case another reservation needs to be
made while releasing the existing reservation engaged in the HA. In
order to avoid this situation, the NSIS signaling for resource
reservation needs to be performed only after finishing the route
optimization, which is the way assumed in the following scenarios.
On the other hand, without route optimization the resource
reservation could be performed immediately after establishing reverse
tunnel.
In this section we are detailing the two scenarios for multihomed QoS
Lee, et al. Expires January 12, 2006 [Page 6]
Internet-Draft NSIS Signaling in Multihoming July 2005
signaling: receiver-initiated reservation and sender-initiated
reservation. Figure 1 depicts the multihomed environment where an MN
with multiple interfaces moves to new area in which several ARs could
possibly serve the MN. After handover, the MN checks the strength of
the beacon signal and the available link bandwidth that neighboring
ARs provide, and chooses the most stable several ARs. An MN acquires
multiple CoAs from the chosen ARs each of which is advertising single
prefix, and then each CoA is assigned to one of the interfaces of the
MN.
...........................
. +---+ . +---+ +---+
+--.----------+ R1|----------.----+ CR+------------+ R3|
| . +-----+-+-+-----+ . +---+ +------+-+-+
+---+ . | | | . | |
| . | | | . +-+-+ +-+-+
+-+-+ . +-+-+ +-+-+ +-+-+ . | HA| | CN|
|OAR| . |AR1| |AR2| |AR3| . +---+ +---+
+---+ . +---+ +---+ +---+ .
. .
+---+ . +---+ .
| MN| =====> | MN| .
+---+ . +---+ .
...........................
Figure 1. Illustration of the Multihomed environment
We assumed homogeneous wireless interfaces in this draft though
multihoming with multiple interfaces would be more efficient on
heterogeneous interfaces due to the increased path diversity. The
issues on heterogeneous interfaces are for further study.
Seamoby protocols such as CARD [10] and CTP [11] are not considered
in this draft because anticipated handover mechanism is not used. As
a first step, this draft discusses interaction with basic
macromobility management protocols (e.g., Mobile IPv4/6). The
interaction with mircomobility are for further study for performance
optimization.
4.2 Receiver-initiated reservation in the multihomed environment
4.2.1 BU and QUERY message transmission
Lee, et al. Expires January 12, 2006 [Page 7]
Internet-Draft NSIS Signaling in Multihoming July 2005
|--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 | | |
|<=================->|<===================->|<=============>|
| | | | | | | | |
Figure 2. Receiver-initiated reservation in the multihomed
environment
After handover, an MN acquires multiple CoAs through aforementioned
procedure and immediately sends a Binding Update to the CN for each
of newly acquired CoAs. The CN acknowledges the binding update (BU)
by sending a binding acknowledgment (BA) to the MN.
On receiving each BA, the MN immediately sends a QUERY message toward
the CN through the interface associated with the CoA, to probe the
network for information about the data path (the procedure (1)-(3) in
Figure 2). The available resource on the path is recorded in the
`QoS Available' object of QSPEC contained in the QUERY message.
4.2.2 Intermediate node operation
The intermediate node inspects the 'QoS Available' object of the
received QUERY message, and if its available resource is less than
what 'QoS Available' says currently, the node adapts it accordingly.
Therefore, when the QUERY message reaches the CN `QoS available'
reflects the bottleneck of the resource currently available on the
path.
It is note worthy that the intermediate nodes between the CRN and the
Lee, et al. Expires January 12, 2006 [Page 8]
Internet-Draft NSIS Signaling in Multihoming July 2005
CN would not take the bandwidth reserved by the same session of the
old path into account when measuring the available bandwidth, so that
the new path having large overlapped portion with the old one might
be at disadvantage during the Primary CoA selection.
4.2.3 Primary CoA selection
On receiving the QUERY messages the CN performs the Primary CoA
determination procedure for the MN (4). The QUERY messages received
no later than a certain time period after the reception of the first
QUERY message are taken into account for the procedure. The time
period is used to prevent the QUERY messages that arrive too late or
have been dropped on the way from delaying the decision procedure.
Though the small waiting time might exclude several messages from the
procedure it would be desirable to maintain the time period to be
small because the QUERY messages along the path with good condition
would have been arrived earlier than others. On the other hand, the
procedure could be immediately started even before the time period
elapses when all Query messages are received, which is possible
because the CN is aware of the total number of QUERY messages to
receive beforehand through the number of BU messages.
The CN determines the Primary CoA based first on the available
bandwidth and second on the arrival time of Query messages. When the
available resource pertained in a QUERY message is conforming to the
MN's BW requirement, the CoA delivered in the QUERY message is
selected as the Primary CoA. In the case of more than one conforming
QUERY messages, the message arrived first is selected.
4.2.4 Reservation re-establishment and teardown
The CN sends a RESERVE message toward the MN to reserve resource
along the path the Primary CoA takes. In this case, the RESERVE
message activates two different actions: flow ID update and resource
reservation. A flow ID consisting of source and destination
addresses is used to identify the data communication route. On
receiving RESERVE message, the nodes between the CN and the CRN
updates the existing flow ID by replacing the old CoA with the new
one, and uses the existing reservations for new path (5). On the
other hand, resource reservations are performed between the CRN and
new AR to establish new path (6). If the reservation is not
successful the CN transmits another RESERVE message using the CoA
with the next highest priority.
The CRN initiates a Teardown message toward old access router (OAR)
to release the reserved resource (8).
4.3 Sender-initiated reservation in the multihomed environment
Lee, et al. Expires January 12, 2006 [Page 9]
Internet-Draft NSIS Signaling in Multihoming July 2005
Sender-initiated reservation shares the procedure of receiver-
initiated approach except for the reversed entity for the generation
of Query and RESERVE messages. In sender-initiated reservation, the
QUERY and RESERVE messages are initiated by a CN and an MN
respectively, where the MN selects the Primary CoA based on the
information delivered by the QUERY message. The CN can send QUERY
message immediately after transmitting BA because the received BU
message indicates MN's new CoA. As in the receiver-initiated
reservation, the teardown message is initiated by the CRN to release
the reservation in the obsolete path. It is note worthy that unlike
the sender-initiated reservation in NSIS the CN needs to send a QUERY
message toward the MN.
5. NSIS Applicability in multihomed scenarios
As mentioned above, the multihomed networks enable NSIS signaling to
be performed with several benefits in dynamic scenarios such as link
failure, load balancing, load sharing, etc. Especially, support for
multihoming in mobility scenarios makes it possible for NSIS
signaling to overcome wireless link bottleneck caused by scarce
bandwidth. This section describes possible applicability scenarios
in case of NSIS signaling operation in the multihomed networks.
5.1 Link/node failure
In case of some link or node failures due to congestion in the
networks or re-booting of system, NSIS state on the involved path
will be removed by responding to such error events. In this case,
NSIS state immediately needs to be recovered to provide seamless
service for the applications. If on-going session, for instance, is
disconnected due to a wireless link failure in multihomed networks,
an MN needs to look for alternative paths through other available
interfaces to re-establish the session. As described in Section 4,
if an MN can have access to three stable wireless links with wholly
or partially different routes and one of the wireless links fails,
the MN again selects one interface (or multiple interfaces) with
paths which are able to guarantee MN's specific requirements and re-
establishes NSIS states along the new paths. The path selection and
NSIS signaling procedure are same except for the absence of teardown
message for the obsolete path. The detailed procedure of NSIS
signaling flow on link/node failure is shown in Fig. 3.
|--Handover-->|
MN OAR AR1 AR2 AR3 CRN CRN CRN CN
(OAR/AR1)(OAR/AR2)(OAR/AR3)
Lee, et al. Expires January 12, 2006 [Page 10]
Internet-Draft NSIS Signaling in Multihoming July 2005
| | | | | | | | |
|---QUERY(1)->|-------------------->|---------------------->|
| | | | | | | | |
| | | | | | | | |
|---QUERY(2)--------------->|---------------------->|------>|
| | | | | | | | |
| | | | | | | | Primary CoA
| | | | | | | | Decision
| | | | | | | | |
| | | | | | |<--RESERVE(2)--|
| | |<-------------RESERVE(2)-----| (Flow ID |
| | | | (Actual reservation) | Update) |
|<-RESERVE(2)-| | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | Multimedia Traffic | | |
|<=================->|<===================->|<=============>|
| | | | | | | | |
Figure 3. NSIS signaling flow procedure on load sharing
5.2 Load balancing
When an MN moves to a new network attachment point in multihomed
networks, it can acquire multiple CoAs through multiple different
interfaces. However, any route connected to the interfaces may not
fully guarantee the MN's bandwidth requirement. In this case, the MN
needs to share its traffic load to all the routes connected to all
accessible interfaces although the traffic load is only from one
application. It is called load balancing. To support the data
flows, the MN should initiate and forward QUERY messages to all the
accessible interfaces to establish NSIS state on all the routes
connected to the interfaces: it can be considered as a kind of load
balancing for signaling. Note that the path selection is performed
by choosing multiple paths, not only one optimized path.
As described in Section 4, for example, the MN wants to setup QoS-
NSLP [2] state path being able to support the bandwidth requirement
of 10Mbps after it undergoes handover in multihomed networks.
However, any accessible path does not guarantee MN's requirements:
each path can only support maximum 5Mbps for the MN's flows,
respectively. In this case, QoS-NSLP should create partial QoS spec.
(e.g., QSPEC) based on the available resources of each path, and the
same NSIS state may be managed with three different flow identifiers
for a unique session identifier if the NSIS states are aggregated in
somewhere of networks. The procedure of NSIS signaling flow on this
Lee, et al. Expires January 12, 2006 [Page 11]
Internet-Draft NSIS Signaling in Multihoming July 2005
approach is shown in Fig 4.
|--Handover-->|
MN OAR AR1 AR2 AR3 CRN CRN CRN CN
(OAR/AR1)(OAR/AR2)(OAR/AR3)
| | | | | | | | |
|---QUERY(1)->|-------------------->|---------------------->|
| | | | | | | | |
|---QUERY(2)-------->|--------------------->|-------------->|
| | | | | | | | |
|---QUERY(3)--------------->|---------------------->|------>|
| | | | | | | | |
| | | | | | | | multiple CoA
| | | | | | | | Decision
| | | | | | | | |
| | | | | | |<--RESERVE(2)--|
| | | |<------RESERVE(2)-----| (Flow ID |
| | | | (Actual reservation) | Update) |
|<----RESERVE(2)-----| | | | |<-R(3)-|
| | | | |<-------RESERVE(3)-----| |
|<---RESERVE(3)-------------| | | | |
| | | | | |<------RESERVE(1)------|
| | |<-----RESERVE(1)-----| | | |
|<---R(1)-----| | | | | | |
| | | | Multimedia Traffic | | |
|<=================->|<===================->|<=============>|
| | | | | | | | |
Figure 4. NSIS signaling flow procedure on load balancing
This approach introduces some new traffic treatment mechanisms. At
first, senders should allocate multiple CoAs to data packets for the
same application and distribute traffic flows to each interface
according to partial QoS spec. allocated to each path. Next,
intermittent nodes or routers can support aggregated signaling if
any. That is, the nodes or routers would aggregate data flows with
different flow identifiers for the same session identifier if the
flows are merged. Finally, receivers would assemble and re-order
data packets with different CoAs, or HoAs for the same session. The
detailed analysis on those mechanisms is for further study.
5.3 Load Sharing
While an MN sends real-time data packets through one interface (or
multiple interfaces) after path selection caused by mobility, it may
also want to simultaneously run some other applications. However,
Lee, et al. Expires January 12, 2006 [Page 12]
Internet-Draft NSIS Signaling in Multihoming July 2005
the current path may not support MN's additional requirements any
more due to scarce link or node resources. In this case, the
additional traffic loads generated by other applications need to be
forwarded to networks through other accessible interfaces in the
multihomed networks: it is called load sharing. As discussed in
Section 4, optimized paths are chosen by the method of signaling path
selection. NSIS state needs to be newly established on new paths
through other accessible interfaces in an end-to-end manner while
maintaining the existing NSIS state for the current application at
the same time. If the additional traffic loads are forwarded to the
same CN, the existing and the new NSIS states may be aggregated
depending on the number of HoAs mapped to multiple CoAs. In this
case, BOUND_SESSION_ID is required to aggregate data packets with
different session identifiers contrary to the approach in Section 5.2
[2]. The procedure of NSIS signaling flow on this approach is the
same as in Fig. 3 shown in Section 5.1.
6. References
6.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
6.2 Informative References
[2] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-
of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in
progress), February 2005.
[3] Hancock, R., "Next Steps in Signaling: Framework",
draft-ietf-nsis-fw-07 (work in progress), December 2004.
[4] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-06
(work in progress), May 2005.
[5] Lee, S., "Applicability Statement of NSIS Protocols in Mobile
Environments",
draft-ietf-nsis-applicability-mobility-signaling-01 (work in
progress), February 2005.
[6] Wakikawa, R., "Multiple Care-of Addresses Registration",
Lee, et al. Expires January 12, 2006 [Page 13]
Internet-Draft NSIS Signaling in Multihoming July 2005
draft-wakikawa-mobileip-multiplecoa-04 (work in progress),
June 2005.
[7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[8] Ernst, T., "Goals and Benefits of Multihoming",
draft-ernst-generic-goals-and-benefits-01 (work in progress),
February 2005.
[9] Montavont, N., "Analysis of Multihoming in Mobile IPv6",
draft-montavont-mobileip-multihoming-pb-statement-04 (work in
progress), June 2005.
[10] Liebsch, M., "Candidate Access Router Discovery",
draft-ietf-seamoby-card-protocol-08 (work in progress),
September 2004.
[11] Loughney, J., "Context Transfer Protocol",
draft-ietf-seamoby-ctp-11 (work in progress), August 2004.
Authors' Addresses
Suwon Lee
SAMSUNG Advanced Institute of Technology
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9585
Email: su.won.lee@samsung.com
Sung-Hyuck Lee
SAMSUNG Advanced Institute of Technology
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9585
Email: starsu.lee@samsung.com
Seong-Ho Jeong
Hankuk University of FS
89 Wangsan Mohyun
Yongin-si, Gyeonggi-do 449-791
Lee, et al. Expires January 12, 2006 [Page 14]
Internet-Draft NSIS Signaling in Multihoming July 2005
KOREA
Phone: +82 31 330 4642
Email: shjeong@hufs.ac.kr
Jong Ho Bang
Samsung Advanced Institute of Technology
Comm. and Network Lab.
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9585
Email: jh0278.bang@samsung.com
Byoung-Joon Lee
Samsung Advanced Institute of Technology
Comm. and Network Lab.
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9626
Email: bj33.lee@samsung.com
Lee, et al. Expires January 12, 2006 [Page 15]
Internet-Draft NSIS Signaling in Multihoming July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lee, et al. Expires January 12, 2006 [Page 16]
