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]