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]