IETF Next Steps in Signaling S. Lee, Ed Internet-Draft SAMSUNG AIT Expires: January 17, 2005 S. Jeong HUFS H. Tschofenig Siemens AG X. Fu Univ. of Goettingen J. Manner Univ. of Helsinki July 19, 2004 Applicability Statement of NSIS Protocols in Mobile Environments draft-manyfolks-signaling-protocol-mobility-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 17, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Mobility of an IP-based node affects routing paths, and as a result, can have a dramatic effect on protocol operation and state Lee, et al. Expires January 17, 2005 [Page 1] Internet-Draft Applicability Statement July 2004 management. This draft discusses the effects mobility can cause to the NSIS protocols, and how the protocols operate in different scenarios, and together with mobility management protocols. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement and General Considerations . . . . . . . . . 8 3.1 Problem statement . . . . . . . . . . . . . . . . . . . . 8 3.2 General Considerations . . . . . . . . . . . . . . . . . . 10 4. Basic operations for mobility support . . . . . . . . . . . . 11 4.1 Generic Route Changes and Mobility . . . . . . . . . . . . 11 4.2 CRN Discovery . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1 Possible approaches for CRN discovery . . . . . . . . 14 4.2.2 The identifiers for CRN discovery . . . . . . . . . . 15 4.2.3 The procedure of the CRN discovery . . . . . . . . . . 17 4.3 Path update . . . . . . . . . . . . . . . . . . . . . . . 18 4.3.1 State setup and update . . . . . . . . . . . . . . . . 18 4.3.2 State Teardown . . . . . . . . . . . . . . . . . . . . 20 5. Mobility-Related Issues with NSIS Protocols . . . . . . . . . 22 5.1 Specific Issues with NTLP . . . . . . . . . . . . . . . . 22 5.2 Specific Issues with QoS-NSLP . . . . . . . . . . . . . . 23 5.3 Specific Issues with NAT/FW NSLP . . . . . . . . . . . . . 24 5.4 Common issues related to NTLP and NSLP . . . . . . . . . . 25 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 26 6.1 Support for Macro Mobility-based scenarios . . . . . . . . 26 6.1.1 Implications to Mobile IP-related scenarios . . . . . 27 6.1.1.1 Mobile IPv4-specific issues . . . . . . . . . . . 28 6.1.1.2 Mobile IPv6-specific issues . . . . . . . . . . . 30 6.2 Multihoming/make-before-break scenarios . . . . . . . . . 32 6.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 32 6.2.2 NTLP/NSLP support . . . . . . . . . . . . . . . . . . 33 6.3 QoS Performance Considerations in mobility scenarios . . . 33 6.4 Use cases of Identifiers . . . . . . . . . . . . . . . . . 35 6.5 Peer Failure Scenarios . . . . . . . . . . . . . . . . . . 36 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 7.1 MN as data sender . . . . . . . . . . . . . . . . . . . . 38 7.1.1 MN is authorizing entity . . . . . . . . . . . . . . . 38 7.1.2 CN is authorizing entity . . . . . . . . . . . . . . . 40 7.1.2.1 CN asks MN to trigger action (on behalf of the CN) . . . . . . . . . . . . . . . . . . . . . . . 41 7.1.2.2 CN uses installed state to route message backwards . . . . . . . . . . . . . . . . . . . . 42 7.1.2.3 MN and CN are authorized . . . . . . . . . . . . . 43 7.1.3 CN as data sender . . . . . . . . . . . . . . . . . . 43 7.1.3.1 CN is authorizing entity . . . . . . . . . . . . . 43 7.1.3.2 MN is authorizing entity . . . . . . . . . . . . . 45 Lee, et al. Expires January 17, 2005 [Page 2] Internet-Draft Applicability Statement July 2004 7.1.4 Multi-homing Scenarios . . . . . . . . . . . . . . . . 45 7.1.4.1 MN as data sender . . . . . . . . . . . . . . . . 45 7.1.4.2 CN as data sender . . . . . . . . . . . . . . . . 46 7.1.5 Proxy Scenario . . . . . . . . . . . . . . . . . . . . 47 7.1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . 47 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 49 8.1 Interaction with Other Mobility-Related Protocols . . . . 49 8.1.1 Interaction with Seamoby Protocols . . . . . . . . . . 49 8.1.2 Interaction with Local Mobility Management Protocols . . . . . . . . . . . . . . . . . . . . . . 49 8.1.3 State Establishment in Network Mobility Scenarios . . 50 8.2 Additional Issues on CRN discovery and Path Update . . . . 50 8.3 Support for the Ping-Pong Type of Movement . . . . . . . . 50 8.4 When both end-hosts are mobile . . . . . . . . . . . . . . 50 8.5 Bi-directional State Establishment . . . . . . . . . . . . 51 8.6 Priority Reservation . . . . . . . . . . . . . . . . . . . 51 8.7 Aggregation of End-to-End Flows in Mobile Environments . . 51 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 53 9.2 Informative References . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 54 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 B. Anticipated Handover . . . . . . . . . . . . . . . . . . . . . 57 Intellectual Property and Copyright Statements . . . . . . . . 59 Lee, et al. Expires January 17, 2005 [Page 3] Internet-Draft Applicability Statement July 2004 1. Introduction The mobility of IP-based nodes incurs route change, usually at the edge of the network. Route change may also be caused by reasons other than mobility, such as routing protocol adaptation in response to varying network conditions (load sharing, load balancing, etc), or host multi-homing. Normal IP mobility (i.e., macro-mobility) also involves the change of mobile node IP addresses. Since IP addresses are usually part of flow identifiers, the change of IP addresses implies the change of flow identifier. Local mobility usually does not cause the change of the global IP addresses, but affects the routing paths within the local access network. The goals of this draft are to present the effects of mobility on the NSIS Transport Layer Protocol (NTLP) and on the NSIS Signaling Layer Protocols (NSLP). The NTLP is an application independent protocol to transport service-related information between nodes in a network. Each specific service has its own NSLP protocol.This draft also discusses how the NSIS protocols should work in various mobility scenarios. The discussion is divided into two parts. The first part discusses the operation of the NSIS protocols in very basic mobility scenarios (e.g., macro-mobility management protocols such as Mobile IPv4 and Mobile IPv6), including support for multi-homing. The second part takes the discussion to more complex scenarios and issues on interworking with various mobility-related protocols such as Seamoby and local mobility management protocols. Lee, et al. Expires January 17, 2005 [Page 4] Internet-Draft Applicability Statement July 2004 2. 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]. The terminology in this draft is based on [2] and [3]. In addition, the following terms are used. O Downstream The flow from a data sender towards the destination. O Upstream The flow from a data destination towards the sender. O Crossover Node (CRN) A Crossover Node is a node that for a given function is a merging point of two or more separate sets of state information. The CRN may not necessarily be a physical route splitting point. There can be different types of logical (but not necessarily physical) CRNs according to signaling states, flow direction, mobility management, and normal routing (not caused by mobility): From the perspective of NSIS states (i.e., NSLP and NTLP states), the types of CRN are basically classified as follows. NSLP CRN, from the NSLP's point of view, is a signaling application-aware node in the network where the correspondent signaling flows begin to merge or split after route changes and mobility. The NSLP CRN may be different according to the types of NSLP. NTLP CRN, from the NTLP's point of view, is a network node where more than one NTLP states begin to merge or split after route changes and mobility. NSIS CRN is either an NTLP CRN or an NSLP CRN. Note that although the types of CRN differ according to the state information, the CRN required for QoS-NSLP operation is the NSLP CRN which has the corresponding signaling application information to perform the path update. There are some differences between route change and mobility in forming CRN according to the direction of signaling flows followed by data flows Lee, et al. Expires January 17, 2005 [Page 5] Internet-Draft Applicability Statement July 2004 In the mobility scenarios, there are two different types of merging point in the network according to the direction of signaling flows followed by data flows as shown in Figure 2 of Section 4.1, where we assume that the MN is a data sender. Upstream CRN, after a handover, is the node closest to the data receiver from which the state information towards the data sender begins to diverge. Downstream CRN, after a handover, is the node closest to the data sender from which the state information towards the data receiver begins to converge. In this case, the DCRN and the UCRN may be different due to the asymmetric characteristics of routing although the CN is the same. In the route changes, the path change of signaling flows results in forming a chain of two CRNs regardless of the direction of signaling flows followed by data flows as shown in figure 1 of Section 4.1, which is referred to as a divergence-convergence pair: Upstream CRN, after a route changes, is the node at which the state information towards the data sender begins to diverge, or to converge. As a result, a (divergent-convergent) UCRN pair will be formed. Downstream CRN, after a route changes, is the node at which the state information towards the data receiver begins to diverge, or to converge. As a result, a (divergent-convergent) DCRN pair will be formed. From mobility management point of view, mobility CRN is the node where the old and new paths (physically) merge. Note that in general, mobility CRN may be different from the NSLP CRN or NTLP CRN. Routing CRN is the node where using normal routing, the old and new paths (rather physically) merge. Depending on the location of nodes, the routing CRN may not be equal to the NSLP CRN or NTLP CRN. O Path Update and Local Repair Path Update is the procedure for the re-establishment of NSIS Lee, et al. Expires January 17, 2005 [Page 6] Internet-Draft Applicability Statement July 2004 state on the new path, the teardown of NSIS state on the old path, and the update of NSIS state on the common path due to the mobility. This is used to improve mobility handling for the affected flows. Upstream Path Update: Path Update for the upstream signaling flow which is initiated by an upstream signaling initiator. If the MN is a sender, the Path Update is initiated by an NI on the common path (e.g., a CN, an HA, or an MAP). Downstream Path Update: Path Update for the downstream signaling flow which is triggered by a downstream signaling initiator. If the MN is a sender, the Path Update is triggered by an NI on the new path (e.g., an MN, a mobile agent, or an AR). In case of route changes, the update of NSIS state on the common path is not required and it is called Local Repair which localizes the NSIS signaling. Especially, in mobility scenarios, if the NSIS signaling interacts with localized mobility management protocols (e.g., HMIPv6), the Path Update can be localized within the access network. O Dead Peer Discovery (DPD) The procedure for finding a dead NSIS peer due to a link/node failure and due to an MN moving away. O Downlink The direction from the CN towards the MN. O Uplink The direction from the MN towards the CN. Lee, et al. Expires January 17, 2005 [Page 7] Internet-Draft Applicability Statement July 2004 3. Problem Statement and General Considerations 3.1 Problem statement IP mobility in its simplest form only includes route changes. Still, the various protocols that seek to support the mobility of end hosts may use very special techniques to reach their goals. Most of these techniques are common IP mechanisms that can also be found in fixed networks, and therefore, are not by themselves particular. The operation of NSIS signaling protocols are affected by the following issues: O Change of route and possibly change of the MN IP address Topology changes entail the change of routes for data packets sent to or from the MN and may lead to the change of host IP addresses. O Latency of route changes The change of route and IP addresses is typically much faster and frequent than traditional route changes, for example, those due to failure, adding or removal of nodes/links. O Explicit routes Signaling protocols usually expect the data traffic to follow the same path as the signaling traffic, but the data traffic sometimes traverses the path different from the path of signaling traffic due to the adaptation of routing protocol according to varying network conditions such as load balancing, load sharing and mobility. For example,Mobile IP adds the possibility to use routing headers to define explicit routes, which diverts the traffic from an expected path. O IP-in-IP encapsulation Mobility protocols may use IP-in-IP encapsulation on the segmnts of the end-to-end path for routing traffic from the CN to the MN, and vice versa. Encapsulation harms any attempt to identify and filter. Moreover, encapsulation may lead to changes in the routing paths, since the sender and destination IP address differ from the values in the original user data packet. The same considerations apply if the signaling packets are encapsulated, too. O Ping-pong type handover NSIS needs to remove states quickly along the old path in order to Lee, et al. Expires January 17, 2005 [Page 8] Internet-Draft Applicability Statement July 2004 mitigate the waste of resources. However, in a ping-pong type handover, the MN returns to the previous AR after staying with the new AR only for a short while, the prompt removal of state along the old path causes the state to be re-established soon again and it adds overhead. O Upstream Path Update vs. Downstream Path Update Since the upstream and downstream paths may not be equal, the upstream and downstream CRNs may not be equal, either. In this case, Path Update needs to be handled independently for upstream and downstream flows, including, e.g., the discovery of upstream and downstream CRNs. O State identification problem A mobility event may cause the address of flow endpoints to change, and in this case it is desirable that signaling application state is independent of the underlying flow to keep the state from being re-installed completely. Therefore, the session and flow identifiers need to be created separately, and this makes it possible to correlate the session identifier with the signaling application about the different flows with the same network control state. O Double reservation Problem Since the state on the old path (and the common path) still remains as it is after re-establishing the state along the new path due to mobility (or route change), the double reservation problem occurs. Although the existing state on the old path can be torn down by the timeout of soft state, the refresh timer value in the core or wired network is quite long (e.g., 30 seconds in QoS-NSLP). As a result, in case of QoS-NSLP, the double reservation problem leads to the waste of resources and call blocking. O End-to-end signaling Problem The mobility may change the flow identifier, and the change of flow identifier requires state update along the entire path to reflect the physical location of the MN, resulting in the end-to-end signaling. This also incurs a long state setup delay and signaling overhead which affect network performance. Ultimately, the long state setup delay may particularly give rise to the service blackout or degradation for multimedia application in the mobility environment. Lee, et al. Expires January 17, 2005 [Page 9] Internet-Draft Applicability Statement July 2004 In summary, NSIS signaling needs to work with basic mobility which can be considered as an extension to the general route (topological) change, to handle the change of IP address, and to support mobile IP tunnels and multi-homing. In this case, Path Update should be localized, and handled independently for upstream and downstream flows. 3.2 General Considerations At the first step, this draft discusses NSIS state establishment (e.g., QoS-NSLP, NAT/FW, etc) in the macromobility-based scenarios (e.g., basic Mobile IP (v4 and v6) handovers) and the interaction with the specific micromobility protocols leading to performance optimization of NSIS signaling would be discussed further in the next version of the draft. Our assumptions in this document and the general considerations are: O Session-ID is used to index state Even if an MN has a permanent IP address (its home address), it cannot be used to index state in the network since the home address may not easily be visible to interior nodes. Other types of mobile nodes (e.g., using SIP or other application layer techniques) may not have permanent addresses at all. After a movement it obtains a new CoA, which is the basis for routing its data. If signaling-associated state is indexed based on some temporary data plane information, such as CoA, the state indexed by previous CoAs might be inaccessible for the signaling after most handover procedures. O Routing may be asymmetric IP packets arriving to and leaving the MN may be routed differently. This may be due to the basic triangular routing of MIPv4, due to the operation of an LMM protocol, or due to asymmetric routing caused by the basic operation of the IP routing protocols themselves. O The CN is not a mobile device We may later add text to consider a mobile CN, too. Lee, et al. Expires January 17, 2005 [Page 10] Internet-Draft Applicability Statement July 2004 4. Basic operations for mobility support In this section, we discuss the basic operations of NSIS signaling needed after the route changes including the mobility. The basic operations include how an appropriate CRN is discovered and how the Path Update is performed by the NSIS signaling according to the direction of data flows. The procedure of CRN discovery (in Section 4.2.3) can be applied in the same way as for both the generic route changes and mobility. However, the Path Update for the generic route changes is different from that for mobility. This draft mainly discusses the Path Update for the route changes caused by mobility. 4.1 Generic Route Changes and Mobility The generic route changes occurs due to load sharing, load balancing, an link or node failure, but the mobility is associated with the change of the network attachment point. These cause divergence (or convergence) between the old path along which state has already been installed and the new path along which data forwarding will actually happen. Although the mobility may be considered similar to the route changes, the main difference is that the Message Routing Information (MRI: e.g., flow identifier) may not change after the route change while the mobility may cause the change of MRI by having a new network attachment point. Since the session should remain the same after any mobility event, the MRI should not be used to identify the session of any signaling application [4]. The route changes brings on the change of signaling topology and it results in difference according to the types of route change (e.g., the route changes or mobility). The route changes generally forms two common paths, an old path, and a new path, where the old path and the new path begin to diverge from one common path and afterward to converge to another common path for each direction of signaling flows (e.g., downstream or upstream flows) as shown in Figure 1. Old path +---+ +---+ ^ --->|NE | ... |NE | ------V common path ^ +---+ +---+ V common path +--+ +----+ +----+ +--+ |S |-----> |DCRN| |DCRN| -------> |R | | | | | | | | | +--+ +----+ New path +----+ +--+ V +---+ +---+ ^ V --->|NE | ... |NAR| ------^ Lee, et al. Expires January 17, 2005 [Page 11] Internet-Draft Applicability Statement July 2004 +---+ +---+ =======(downstream signaling followed by data flows) ========> (a) The topology for downstream NSIS signaling flow after the route changes Old path +---+ +---+ v <---|NE | ... |NE | ----- ^ common path v +---+ +---+ ^ common path +--+ +----+ +----+ +--+ |S |<----- |UCRN| |UCRN| <------- |R | | | | | | | | | +--+ +----+ New path +----+ +--+ ^ +---+ +---+ v ^ <---|NE | ... |NAR| ----- v +---+ +---+ <=====(upstream signaling followed by data flows) ======== (b) The topology for upstream NSIS signaling flow after the route changes Figure.1 The topology for NSIS signaling in case of the route changes However, the mobility results in creating a common path, an old path, and a new path, and the old and new paths only converge or diverge according to the direction of each signaling flow as shown in Figure 2. Old path +--+ +---+ original |MN|------> |OAR| -------------V address +--+ +---+ V common path | +----+ +--+ | |DCRN| -------> |CN| | | | >>>>> | | v New path +----+ ^ +--+ +--+ +---+ ^ ^ New CoA |MN|------> |NAR|--------------^ ^ +--+ +---+ ^ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^ (Binding process) Lee, et al. Expires January 17, 2005 [Page 12] Internet-Draft Applicability Statement July 2004 ====(downstream signaling followed by data flows) ======> (a) The topology for downstream NSIS signaling flow due to mobility. Old path +--+ +---+ original |MN|<------ |OAR| -------------^ address +--+ +---+ ^ common path | +----+ +--+ | |UCRN| <------- |CN| | | | >>>>> | | v New path +----+ ^ +--+ +--+ +---+ v ^ New CoA |MN|<------ |NAR|--------------v ^ +--+ +---+ ^ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^ (Binding process) <=====(upstream signaling followed by data flows) ===== (b) The topology for upstream NSIS signaling flow due to mobility. Figure.2 The topology for NSIS signaling caused by mobility. Figure 2: Signaling topology by mobility event. These topological changes caused by mobility make the signaling state established on the old path useless and therefore removed (in the end). In addition, the existing NSIS state should also be re-established along the new path and to be updated along the common path. Note that to minimize the impact on seamless service and improve signaling scalability, NSIS signaling should be localized when route changes (including mobility) occur; the localized signaling procedure is referred to as Local Repair in this draft (in case of the interaction with localized mobility protocols: see the terminology section). As an example, in mobility scenarios, although NSIS signaling messages are initiated by an MN or CN and sent to the opposite terminating point of the path, the path in the wireless access network usually changes only partially. Therefore, the NSLP/ NTLP needs to limit the scope of signaling information to a local section of the signaling path. One of the most appropriate nodes to do the Local Repair (or Path Update) can be the Crossover node (CRN) where the old and new session paths meet. The NTLP module (of a node experiencing a topological change) should Lee, et al. Expires January 17, 2005 [Page 13] Internet-Draft Applicability Statement July 2004 detect it through the various mechanisms described in [4] at transport level and triggers the NSLP operation over itself, and then the NSLP should initiate necessary NSIS state establishment (i.e., QoS re-establishment) along the new path and the update or removal of associated states, at the signaling application level. Note that in the case of QoS-NSLP, state re-establishment due to the route changes does not need any state update along the entire signaling path since the flow identifier does not change (in other words, the IP address of endpoint does not change). 4.2 CRN Discovery 4.2.1 Possible approaches for CRN discovery The approaches for CRN discovery can be divided into two classes according to which layer is responsible for the discovery of CRN, and whether the discovery is coupled with the transport of signaling application messages. From the NSIS protocol stack point of view, the CRN can be discovered at both NTLP and NSLP layers. First, the CRN discovery at the NSLP layer is possible using the information contained in NSLP signaling messages sent from the signaling initiator. For example, NSLP can realize that it is a CRN by comparing the Source Identification Information (SII) contained in the incoming signaling message to the one stored previously in the node. However, since NTLP is responsible for detecting the path change of data (or signaling) flow (and the route changes may easily be detected at the NTLP level rather than at the NSLP), CRN discovery can be considered as an extension to the peer discovery at the NTLP level (e.g., using GIMPS query-response [2]). In general, the GIMPS message has message routing state information such as flow/session/signaling application identifier, so signaling application can be identified at the NTLP level. For example, in the connection mode of NTLP, when NTLP establishes a messaging association between two adjacent peers, the NTLP peers exchange message routing state information through GIMPS query and response messages. Therefore, although the CRN can be discovered at the NTLP level, the discovered CRN could be actually NSLP-aware node which has an involved signaling application. There can also be two different approaches for CRN discovery according as whether the discovery is coupled with signaling message or not: the coupled approach and uncoupled approaches. If the signaling to update NSIS state along a new path or the common path, after route changes or mobility, is done simultaneously with the CRN discovery procedure, it is called the coupled approach. If the signaling to do Path Update is done after the CRN discovery is completed, it is called the uncoupled approach. These approaches may Lee, et al. Expires January 17, 2005 [Page 14] Internet-Draft Applicability Statement July 2004 have some effect on security aspect. Generally, the coupled approach would be preferred to the uncoupled approach to reduce the delay for signaling setup. Note that CRN discovery and Path Update described in this draft are based on the coupled approach. 4.2.2 The identifiers for CRN discovery There are some basic identifiers which can be used for CRN discovery at the NTLP level: session identifier, flow identifier (MRI), and signaling application identifier (NSLP_ID) related to message routing state [2]), and NSLP branch identifier related to the direction of NSIS signaling branch. The session identifier in the GIMPS message is used to easily identify the involved session because it remains the same while the MRI may (or may not) change due to handover. The MRI is used to specify the relationship between the address information and the state (e.g., QoS-NSLP state) re-establishment. In other words, the change of MRI indicates topological changes and therefore it represents that the state along the common path should be updated after the CRN discovery. The signaling application identifier (NSLP_ID) is used to refer to the corresponding NSLP at GIMPS level, and in the context of CRN discovery it helps to discover an appropriate NSLP CRN using the GIMPS peer discovery message. The NSLP branch identifier as a virtual branch identifier can be used to establish or delete NSIS associations between peers and it can also be used as an identifier to determine the CRN at the GIMPS layer. The NSLP branch identifier can consist of the location information of peer nodes with the correspondent NSLP ID by the procedure of GIMPS message association. For instance, as shown in Figure 3, for the downstream case, NSLP1 of node A requires a messaging association for sending its messages towards node D after a route changes. In this case, NSIS entity A creates an NSLP branch ID for NSLP 1 toward node D and increases the counter of NSLP branch ID to locally distinguish each virtual interface identifier between adjacent NSLP peers: the corresponding NSLP br.ID is 1-D-#2. Note that the NSLP branch identifier can be included in the NSIS message, but it can also be considered as an implementation issue. This identifier would be more useful when the merging point of the old path and a new path is not an NSLP CRN after the route change. Old path +-----+ +-----+ ^---->|NSLP1| ... |NSLP1| ----V Lee, et al. Expires January 17, 2005 [Page 15] Internet-Draft Applicability Statement July 2004 common path ^ +-----+ +-----+ V common path +-----+ +-----+ C K +-----+ +-----+ --->|NSLP1|--->| | | |--->|NSLP1|--> |NSLP2| |NSLP2| |NSLP2| |NSLP2| +-----+ +-----+ New path +-----+ +-----+ A B V +-----+ +-----+ ^ M N V--->|NSLP1| ... |NSLP1| ----^ +-----+ +-----+ D L =======(Flow direction) ========> (a) NSIS signaling topology for downstream signaling flow after the route changes in the middle of the network +------------------+-------+-------+--------+------------+-------+ | Message Routing |Session| NSLP |Upstream| Downstream | NSLP | | Information | ID | ID | Peer | Peer |Br. ID | +------------------+-------+-------+--------+------------+-------+ | Method = Path | 0xABCD| NSLP1 | Z | Pointer to | 1-D-#1| |Coupled; Flow ID =| | | | A-C | | | {IP-#X, IP-#V, | | | | Pointer to | 1-D-#2| | protocol, ports} | | | | A-D | | | | | | | | 1-U-#1| | Method = Path | | | | | | |Coupled; Flow ID =| 0x1234| NSLP2 | Z | (null) | 2-D-#1| | {IP-#X, IP-#V, | | | | | | | protocol, ports} | | | | | 2-U-#1| +------------------+-------+-------+--------+------------+-------+ (b) Routing state table at node A (NSLP CRN) +------------------+-------+-------+----------+----------+-------+ | Message Routing |Session| NSLP |Upstream |Downstream| NSLP | | Information | ID | ID | Peer | Peer |Br. ID | +------------------+-------+-------+----------+----------+-------+ | Method = Path | 0xABCD| NSLP1 |Pointer to| (null) | 1-U-#1| |Coupled; Flow ID =| | | K-N | | | | {IP-#X, IP-#V, | | |Pointer to| | 1-U-#2| | protocol, ports} | | | L-N | | | | | | | | | 1-D-#1| | Method = Path | | | | | | |Coupled; Flow ID =| 0x1234| NSLP2 | M | (null) | 2-U-#1| | {IP-#X, IP-#V, | | | | | | | protocol, ports} | | | | | 2-D-#1| +------------------+-------+-------+----------+----------+-------+ Lee, et al. Expires January 17, 2005 [Page 16] Internet-Draft Applicability Statement July 2004 (C) Routing state table at node N (NSLP CRN) Figure.3 Routing state table and NSLP branch ID Optionally, the mobility identifier as an object form can also be used for immediate CRN discovery in various mobility scenarios. The mobility object can also be used for other purposes. The more details are discussed further in Section 6.4. 4.2.3 The procedure of the CRN discovery In general, when a mobility event occurs, the CRN can be recognized by comparing the existing message routing information (e.g., the NSLP ID, the session identifier and MRI) and the NSLP branch ID with the message routing information and the NSLP branch ID (with different counter number) included in the NTLP peer discovery message initiated by an NI (e.g., an MN or a CN). For example, if an NTLP message is routed to an NSIS peer node, the following information (shown in Figure 3 (b) and (c)) is checked: - Whether the same NSLP ID exists, - Whether the corresponding CRN is already discovered, - Whether the same session identifier and MRI exist, - Whether the NSLP branch identifier is changed: for example, as shown in Figure 3 (b), it for NSLP 1 changed to 1-D-#2 from 1-D-#1, - Optionally, check the mobility identifier, if any: for example, the Mobility object to know which message is sent due to the latest handover (see Section 6.4). The CRN discovery can be further divided into UCRN discovery and DCRN discovery according to which node is a signaling initiator (by upstream or downstream), or whether the MN is a data sender: - If the MN is a data sender and when a mobility event occurs, the MN begins to transmit signaling messages toward a CN in the downstream direction. In this case, an NSLP-aware node recognizes that the session paths logically converge, and then the NSLP-aware node realizes it is the DCRN through the procedure above: the procedure of CRN discovery is similar to the creation of the routing table of node N except for the unchanged flow ID. - When an MN (as a sender) undergoes handover, the UCRN can be determined for upstream flow by the method above. In this case, Lee, et al. Expires January 17, 2005 [Page 17] Internet-Draft Applicability Statement July 2004 the UCRN should be the first node where the signaling flow begins to logically diverge: it is similar to the creation of the routing table of node A except for the unchanged flow ID. Since the UCRN is determined by whether outgoing path diverges or not, the UCRN discovery is more complex than the DCRN discovery. 4.3 Path update The CRN discovery is different according to the direction of signaling flow in mobility scenarios, and the DCRN operates independently of the UCRN although DCRN and UCRN can be simultaneously ferreted in bi-directional state establishment. Therefore, the procedures for path update may differ according to the direction of signaling flows as defined in terminology section: the upstream Path Update and the downstream Path Update. In this case, each signaling initiator has to be authorized for secure signaling. For both types of path update, NSIS protocol needs to interact with various mobility signaling protocols, if any (during or posterior handover) to obtain performance gains through fast re-establishment of the NSIS states along the new path. In this case, NSIS also needs to monitor the movement of a mobile node through several methods [4].In this section, we assume that an MN is a data sender.In this section, we assume that an MN is a data sender. 4.3.1 State setup and update Before initiating the Path Update, an MN or a CN needs to have its session ownership by the procedure of authentication and authorization and to check the availability of resources on the new path. If the resources along the new path run short of, it needs to keep state previously established for the flows while blocking new requests. In this case, NSIS signaling for the Path Update also needs to have an appropriate priority over local requests for the resources. In the downstream path update, if resource availability is assured, the MN initiates the NSIS signaling for state setup toward a CN along the new path, and the DCRN discovery is implicitly done by this type of signaling initiated by the MN. In this case, the node where the old and new logical session paths converge realizes that it is the DCRN, and afterward the DCRN sends a response message toward the MN to notify of NSLP state installed (e.g., in QoS-NSLP) or installs the NSLP states as responding the NSLP signaling initiated by the MN (e.g., as in RSVP). In this case, the sender-initiated approach (e.g., QoS-NSLP) leads to faster setup than the receiver-initiated approach as RSVP as shown in Figure 4 below. And then, the DCRN sends a refresh message toward the signaling destination to update Lee, et al. Expires January 17, 2005 [Page 18] Internet-Draft Applicability Statement July 2004 the changed MRI on the common path and also sends a teardown message toward the old AR to delete the NSIS states along the obsolete path (if possible). NI (MN) NF NF NR (CN) | | | | | RESERVE | | | +--------->| RESERVE | | | +--------->| RESERVE | | | +--------->| | | | | | | | RESPONSE | | | RESPONSE |<---------+ | RESPONSE |<---------+ | |<---------+ | | | | | | | | | | (a) Sender Initiated Reservation NI (MN) NF NF NR (CN) | | | | | QUERY | | | +--------->| QUERY | | | +--------->| QUERY | | | +--------->| | | | | | | | RESERVE | | | RESERVE |<---------+ | RESERVE |<---------+ | |<---------+ | | | | | | | RESPONSE | | | +--------->| RESPONSE | | | +--------->| RESPONSE | | | +--------->| | | | | b) Receiver Initiated Reservation Figure.4 Sender- vs. Receiver-intiated reservation In the case of upstream path update, the CN (or a HA/ a GFA/MAP) sends a refresh message toward the MN to perform path update. UCRN is discovered implicitly by the CN-initiated signaling along the Lee, et al. Expires January 17, 2005 [Page 19] Internet-Draft Applicability Statement July 2004 common path, and the node from which the common path begins to diverge into the old and new logical session paths realizes that it is the UCRN. In this case, the CN should be informed of the movement event using an NSIS signaling message sent by the MN or monitoring the mobility signaling after detecting a change in its binding entry (see Section 6.1). After the UCRN is determined as described in Section 4.2.3, it may send a refresh message to the MN along the new path while establishing the NSIS association between the updated peers, and afterward the UCRN may send a teardown message toward the old AR to delete the NSIS state on the obsolete path (if possible). The state update in control plane on the common path to reflect the changed MRI brings issues on the end-to-end signaling addressed in Section 3.1. Although the state update does not give rise to re-process AAA and admission control, it may lead to the signaling overhead and latency. One of the goals of path update is to avoid double reservations (in case of QoS signaling) on the common path described in Section 3.1. The double reservation occurred along the common path may be solved by establishing a signaling association using the unique session identifier and by the update of packet classifier/flow identifier. In this case, the NSLP state can be shared for flows with different flow identifiers. 4.3.2 State Teardown After re-establishment of the NSIS state along the new path, the state on the obsolete path need to be quickly removed by path update mechanism to prevent the waste of resources due to double reservation (and resource allocation problem by call blocking) and to reduce the cost of using the resources in the access network as described in Section 3.1. Although the release of the existing state on the old path can be accomplished by timeout of soft state, the refresh timer value may be quite long and the maintenance of the NSIS state on the obsolete path may not be necessary. Therefore, the transmission of a teardown message is particularly preferred to the use of refresh timer to quickly delete the old state. Note that, however, it is not necessary for the GIMPS to be explicitly removed because of the inexpensiveness of the state maintenance. The CRN is an appropriate point to initiate the teardown toward the old AR after re-establishment of the state along the new path. In this case, the release of old state on the obsolete path can be accomplished by comparing the NSLP branch ID and through reverse routing using SII. This can prevent the teardown message from being forwarding toward along the common path. However, whether the teardown message can be sent toward the opposite direction to the Lee, et al. Expires January 17, 2005 [Page 20] Internet-Draft Applicability Statement July 2004 state initiating node is still an open question. This also leads to authorization problem because a node which does not initiate signaling for establishing the NSIS state can delete the state. The immediate removal of state along the old path may not be appropriate for some mobility situations. For instance, in the fast handover of a ping-pong type where an MN may return to the previous AR after staying at a new AR for a short while, it causes signaling overhead and when to delete the state along the obsolete path remains still an open issue and needs to be discussed further in the later version of this draft. Another example is the last node detection problem. If the old AR is the last node due to handover, its NSLP may trigger an error message to indicate that NSLP messages cannot be forwarded any further. This error message may cause the removal of the old states. However, although the error message is initiated, the state on the old path should not be deleted before re-establishing the state along the new path (make-before-break handover). The more details are discussed further in Section 6.5. Lee, et al. Expires January 17, 2005 [Page 21] Internet-Draft Applicability Statement July 2004 5. Mobility-Related Issues with NSIS Protocols 5.1 Specific Issues with NTLP The NTLP protocol maintains a per-flow message routing state and a per-peer messaging association state. The former is installed and maintained by a peer discovery mechanism, while the latter is set up by the normal procedures of transport (and security protocols, when secure channel for C-message transport is desired) that comprise the messaging association. NTLP is responsible for detecting route change, updating its own routing state consistently, and informing NSLPs at affected nodes. In mobility environments, for an end-to-end signaling flow, its signaling path can be changed upon a successful MIP registration. This means a new peer discovery procedure needs to be triggered (e.g., through certain routing interface) and a new NTLP message routing state must be adapted. NTLP provides 5 mechanisms to detect a route change. In uplink signaling case in mobility environments an MN can use the first approach, local trigger, to determine next hop has changed and initiate a new peer discovery until downstream CRN is found. In downlink signaling case mobility environments, most detection mechanisms at CN, HA or other mobility agents (if they support NSIS at all) can only determine a route has "changed", i.e., a binding cache changed. However, these entities do not necessitate an actual NTLP or NSLP CRN, and the latter is the actual node of NSIS interests and needs to be detected. This is an issue related to an NTLP implementation's scale of re-discovery. After detecting a route change has occurred, in addition to updating the message routing state, an NTLP implementation at the downstream CRN needs to notify local NSLP(s) to initiate their own state local repairs. Messaging association state can be ignored as it is per-peer meaningful and not very expensive. NTLP works with general IP tunneling by applying the same encapsulation to NSIS messages as data packets. Most mobility protocols involve IP-in-IP encapsulation in part of the signaling path. As this becomes effective dynamically after a mobility registration, an NTLP implementation should gain the knowledge about the introduction or change of encapsulation methods in the responding node, if NSLPs want to be signaled into these tunnels. Moreover, IP-in-IP encapsulation is simultaneously coupled with route change, thus an NTLP implementation needs to interact with mobility registration carefully. Lee, et al. Expires January 17, 2005 [Page 22] Internet-Draft Applicability Statement July 2004 5.2 Specific Issues with QoS-NSLP The QoS-NSLP protocol establishes and maintains QoS-related state at NSIS aware nodes along the path of data flow to support some forwarding resources required for that flow. In mobility scenarios, as mentioned in Section 4, the QoS-NSLP protocol needs to immediately perform the procedure of the Path Update after an appropriate CRN is discovered to continue to support QoS-related state for that session. In this case, the following basic issues rise when considering interaction with GIMPS layer as well as mobility protocols: - When/how is QoS-NSLP signaling initiated after mobility? For instance, if an MN is a sender and the sender-initiated reservation approach is used, when does the MN send RESERVE message forward CN to do the Path Update (and CRN discovery if coupled approach is used)? In the receiver-initiated reservation, when is Query message sent to a corresponding receiver or node initiating reservation? In this case, QoS-NSLP should know or detect the MN¡¯s movement, e.g., through the SII notified over API between GIMPS and QoS-NSLP (see Sections 5.4 and 6.1). - How/when does an MN know/find out what resources are available before a reservation is made after handover? And If QoS-resources in a new access network are oversubscribed, how is the reservation for required resources made? The QoS-NSLP of MN may be able to know the availability of resources at the new access network using Query message. In this case, the Query message needs to have a priority rather than any other signaling: priority signaling for call setup. If an MN moves an access network which does not have a sufficient resources available, the MN may fail to reserve the resources and it tries to keep the previous state by its mulihomed interfaces. In such an oversubscribed scenario, certain signaling message required for reservation may also be prioritized, but how those signaling messages are dealt with priority is still open and so needs to be discussed further in the later version of this draft. - Which layer should the (NSLP) CRN discovery be performed at, GIMPS or QoS-NSLP? Although a QoS-NSLP can detect the change of signaling path and discover the CRN by keeping track of SII, The CRN discovery may be preferred at the GIMPS layer to at the QoS-NSLP. As mentioned Section 4, since GIMPS detects the CRN as an extension of peer discovery, it does not add processing overhead. - How/by who can RESPONSE message be sent to the corresponding QNI if QNR (e.g., an MN) of the RESPONSE message performs handover before the receipt of the message? If RESERVE (for refresh) Lee, et al. Expires January 17, 2005 [Page 23] Internet-Draft Applicability Statement July 2004 including Response request is sent to the MN from a node but the MN begins to handover the OAR in behalf of the MN may be a proxy to initiate RESPONSE message. In this case, the MN may notify OAR of the handover or error conditions (the-last-node-is-not-detected) using NOTIFY message. This ¡®invalid-NR¡¯ problem is discussed further in Section 6.5. - How is refresh time set up in the situation of frequent handover? The QoS-NSLP uses peer-to-peer refreshing approach to allow QNEs to choose appropriate refresh intervals according to their network environments (e.g., an access network, or a core network). In mobility environments, refresh time intervals-related issues are discussed in Section 6.3 - How does CRN immediately remove the state along the old path after the establishment of state along a new path? The CRN can delete the state along the old path by keeping track of SII or using Request Identification Information (RII). Since the SII object is similar in nature to the RSVP HOP object [5], RESERVE message set with TEAR flag can be forwarded to the direction of reverse path. In route change, the RII contained RESPONSE_REQUEST object (if any) allows the CRN to correctly send back the RESERVE message with TEAR flag to an appropriate (scoped) node. Note that as mentioned in Section 5.1, NTLP state along the old path does not need to be explicitly deleted before the expiration of the refresh time interval because of inexpensive of NTLP state. Some issues according to performance gain, bi-directional reservation, aggregation reservation and various handover scenarios are discussed further in Section 6: for example, refresh reduction, session binding, layering, peer agreement, and so on. 5.3 Specific Issues with NAT/FW NSLP The NAT/Firewall NSLP [6] establishes and maintains firewall pinholes and NAT bindings at NAT/FW NSLP nodes along the data path. With regard to mobility a few issues need to be considered: In case of an IP address change firewall rules and/or NAT bindings become invalid which effectively prevents the end host from sending or receiving data packets. For example, without updating the firewall pinhole by a NSIS aware data sender who is located behind a firewall data packets with a new source IP address are most likely dropped at the firewall. If a data receiver , who is located behind a NAT, changes its IP address then incoming packets are rewritten at the NAT and forwarded to the wrong IP address. The QoS NSLPs might 'only' temporarily experience a weaker quality of service if the installed flow identifier is not uptodate. Lee, et al. Expires January 17, 2005 [Page 24] Internet-Draft Applicability Statement July 2004 Although NSIS applies the soft-state principle and allocated state times out without refresh messages, it is possible that mobility leaves state (such as firewall pinholes) in place for some time. Since the NAT/Firewall NSLP aims to install pinholes (and NAT bindings) it is possible to re-use this installed state once a mobile node roams to a new location. Deleting state along the old path helps to limit this problem. However, this problem exists anyway as identified in [7] due to the capability of IP spoofing since the main problem is the usage of non-cryptographically based IP address filters. Hence, the NAT/Firewall NSLP is (in a mobility environment) not in the same fashion concerned about deletion of state along the old path. There also seem to be some differences between the security functionality required by the QoS NSLP and the NAT/Firewall NSLP (as analysed in [7], in [6] and in [8]. The security solution for the NAT/Firewall NSLP needs to reflect mobility specific security issues. This also has an impact on refresh handling (i.e., peer-to-peer vs. end-to-end), authorization issues, the usage of the session identifier and end-to-end security (with regard to the binding between NSIS and the application layer signaling). 5.4 Common issues related to NTLP and NSLP In mobile environments, mobility related information for path update can be exchanged through the API specified in [NTLP]. For example, when a route change due to mobility occurs, SII-Handle can be provided from GIMPS to an NSLP in order to inform of the route change. The SII-Handle is a handle to a data structure, identifying peer addresses and interfaces. It can be used to identify route changes and for explicit routing to a particular GIMPS next hop. Based on the information, the involved NSLP can initiate path update by sending necessary signaling messages through the API. The details on the API are an implementation issue. Message routing information (MRI) and Session ID are also shared by the GIMPS and NSLP through the API. Whenever there is any route change due to mobility the MRI will be updated although the Session ID will not change. The MRI should be consistent with the SII-Handle described above. Lee, et al. Expires January 17, 2005 [Page 25] Internet-Draft Applicability Statement July 2004 6. Applicability Statement 6.1 Support for Macro Mobility-based scenarios This section considers how should NSIS protocols interact with the basic macro mobility protocols such as Mobile IPv4 and Mobile IPv6, and other global mobility approaches will be discussed further in the next version of this draft. The NSIS signaling needs to consider the following scenarios related to basic Mobile IP to interact with it. (1) A flow associated with an MN, either sent or received by the MN, may desire to be continuely served signaling services after a mobile IP handover. In this case, NSIS needs to be able to signal for such flows upon an MN's movements to seamlessly provide the correspondin service to one (e.g., QoS). The signaling procedure results in creating a new NSIS branch along the new path through an appropriate CRN discovery and a Path Update. (2) Either the sender or the receiver of an MN's flow can initialize an NSIS signaling, and it is essential to require the NSIS signaling initiator to be authorized to initialize the signaling. Note that nodes within the network may also initiate NSIS signaling for the given session, for example, to handle route changes caused by Mobile IP routing in the middle of the network, or to support seamless handovers. (3) Data traffic, in either direction between an MN and a CN, can be routed directly using a routing header, or indirectly by IP-in-IP encapsulation (or the combination of them) in different segments of the data transmission depending on the mobility mode (either route optimization or triangle routing is used; whether reverse tunneling is used; either mobile IPv4 or IPv6 is used; whether LMM is used, etc.). In this case, NSIS signaling needs to immediately be initiated by using a mobility routing interface (e.g., mobility API) between the NSIS protocols and the Mobile IP according to the method of each routing. (4) An MN's handover can be either intra-domain (within an access network domain) or inter-domain (from an access network domain to another), which mainly concerns with topology information exchange, authorization and accounting issues. The interworking with NSIS signaling and some mobility management protocols (i.e., HMIP, FMIP, etc) in various handover scenarios may give rise to some performance gains (see Section 6.3). (5) In mobile IPv6, an MN can support multiple care-of-addresses at Lee, et al. Expires January 17, 2005 [Page 26] Internet-Draft Applicability Statement July 2004 one time, if it is connected to multiple access networks simultaneously (or even if it is connected to one access network). Although only one primary care-of-address will be used for routing traffic from the CN to the MN, this multi-homing feature potentially can be used to enhance the NSIS signaling performance (see Section 6.2). The inter-domain handover, for instance, may require additional latency to perform the NSIS signaling procedure including authentication and authorization rather than the intra-domain handover, but the latency penalty of NSIS signaling can be mitigated if the MN is multi-homed. 6.1.1 Implications to Mobile IP-related scenarios As NSIS is path-coupled signaling, one imposed requirement here is that the NSIS protocols are to be typically associated with a route changes for route optimization between the CN & the MN and an IP-in-IP encapsulation from the HA to the MN as well as mobility, and those interaction also needs to be notified to all NSLPs by the API between GIMPS and NSLP for the CRN discovery and the Path Update as described in Section 4. Therefore, NTLP or NSLP needs to have an interface with the Mobile IP to immediately react to the mobility event. In other words, NSIS implementation needs to be designed to react based on the endpoint notification of which behaviour of Mobile IP has taken place and probably, when the timer of Mobile IP refreshes (to keep corresponding NSLPs reacting to it). An ideal interface between NSIS signaling and the Mobile IP should make that NSIS signaling is able to react to the mobility event as soon as possible whenever Mobile IP changes its characteristics in any place for the flows, In general, it is appropriate that NTLP is involved in the interaction with the Mobile IP rahter than NSLP, because NTLP is responsible for detecting the mobility and routing NSIS messages. Therefore, it is reasonable to assume NTLP should be able to notify NSLP of the update of state when mobiity is detected. Here also are some issues which rise when the API between the NSIS and the Mobile IP is considered. - Which information does the NTLP detect the movement based on? After an MN arrives at a new network attachment point, current reachability information is transferred from the MN to its HA as the last procedure of handover. It indicates that NTLP may need to interact with the start/completion of a binding process (e.g., registration request in Mobile IPv4 and Binding Update in Mobile IPv6) to detect the IP address change and refer to the tunnel information of Mobile IP. Therefore, provided the NTLP detects the mobility using the information of binding process, faster state establishment and removal can be performed. However, in the fast or ping-pong handover, it may result in considerable Lee, et al. Expires January 17, 2005 [Page 27] Internet-Draft Applicability Statement July 2004 signaling overhead and some possible errors. - How and what information can the NSLP expect from NTLP, or directly from the routing interface after mobility? - How to coordinate the mobility binding update interval and NSIS signaling interval? Since the Binding Update or the Registration request message occur periodically even for the MN with the same point of attachment, the movement detection based on the binding process sometimes causes the NTLP/NSLP to inappropriately initiate the CRN discovery and the Path Update. Although the issue is closely related to implementation, it needs to be considered to have the performance gain of NSIS signaling. An overall coordination/synchronization about the interworking with the NSIS and the Mobile IP is still open and needs to be discussed further. 6.1.1.1 Mobile IPv4-specific issues The data flows of Mobile IPv4 are forwarded based on the triangular routing (even if route optimization is considered an extended option), and an MN retains a new CoA from the FA (or the external method such as DHCP) in the corresponding access network unlike the Mobile IPv6 whenever the MN arrives at the new network attachment point (e.g., a FA or a foreign link)[9]. When the MN is a sender, the downstream data flows from the MN are directly transferred to the CN not necessarily through the HA or indirectly through the HA using the reverse routing. On the other hand, upstream data flows from the CN are routed through the IP tunneling between the HA and the FA (or the HA and the MN in the case of the Co-located CoA). In this case of such a routing which is dependent on the HA, it represents that the NSIS signaling needs to interact with the IP tunneling of Mobile IP to provide an appropriate signaling service for that flow. The following figures 5 (a)-(e) show the NSIS signaling flows required according to the direction of data flows and the routing methods . MN FA (or FL) CN | | | | IPv4-based Standard IP routing | |------------ |------------------------------>| | | | (a) MIPv4: MN-->CN, no reverse tunnel Lee, et al. Expires January 17, 2005 [Page 28] Internet-Draft Applicability Statement July 2004 MN FA HA CN | IPv4 (normal) | | | |--------------->| IPv4(tunnel) | | | |--------------->| IPv4 (normal) | | | |-------------->| (b) MIPv4: MN-->CN, the reverse tunnel with FA Care-of-Address MN (FL) HA CN | | | | | IPv4(tunnel) | | |------------------------------->|IPv4 (normal) | | | |-------------->| (c) MIPv4: MN-->CN, the reverse tunnel with Co-located Care-of-address CN HA FA MN |IPv4 (normal) | | | |-------------->| | | | | MIPv4 (tunnel) | | | |---------------->| IPv4 (normal)| | | |------------->| (d) MIPv4: CN-->MN, Foreign agent Care-of-address CN HA (FL) MN |IPv4(normal ) | | | |-------------->| | | | | MIPv4 (tunnel) | | | |------------------------------->| | | | | (e) MIPv4: CN-->MN with Co-located Care-of-address Figure 5. Implications for signaling under different Mobile IPv4 scenarios When an MN (as a sender) arrives at a new FA and the corresponding binding process for the FA CoA is completed: - For downstream signaling flow, the MN needs to perform the CRN discovery (DCRN) and the (downstream) Path Update toward the CN as described in Section 4 to establish the NSIS state along the new path between the MN and the CN as shown in Figure 6 (a). If the reverse tunnel is used and the state along the tunneling path does not exist, the NSIS state may be established along the tunneling Lee, et al. Expires January 17, 2005 [Page 29] Internet-Draft Applicability Statement July 2004 path from the FA to the HA as shown in Figure 6 (b). In this case, the DCRN may be discovered on the tunneling path and the new flow identifier for the tunneling state update may need to be created. - For upstream signaling flow, the CN may initiate the NSIS signaling to update the existing state between the CN and the HA, and then NSIS signaling may need to interact with IP tunneling to also update the state along the tunneling segment from the HA to the FA as shown in Figure 6 (d). In this case, the UCRN may be discovered somewhere on the tunneling path, and the new flow identifier for the tunneling state update may be created. When the MN (as a sender) arrives at a new foreign link and the corresponding binding process for the co-located CoA is completed: - For downstream signaling flow, the NSIS signaling for the DCRN discovery and the Path Update is equal to the case for FA CoA above (as shown in Figure (a)) except that in case of using the reverse tunnel, the NSIS state may be established along the tunneling path from the MN to the HA as shown in Figure 6 (C). - For upstream signaling flow, the CN may initiate the NSIS signaling to update the existing state between the CN and the HA and then NSIS signaling may need to interact with IP tunneling to also update the state along the tunneling segment from the HA to the MN as shown in Figure 6 (e). In this case, the UCRN may eventually be discovered somewhere on the tunneling path, and the new flow identifier for the tunneling state update may also be created. Note that in the case of interaction with IP tunneling, DCRN and UCRN may be identified at the same node on the tunneling path. For example, NSIS CRN may usually be the HA if the HA and the FA are NSIS-aware and the NSIS state along the tunneling path is not established. Therefore, the CRN discovery may be affected according to the interaction with NSIS signaling and IP tunneling, and the FA and the HA should be NSIS-aware to do the Path Update along the appropriate path. However, the effect that the IP tunneling has on the CRN discovery and the Path Update needs to be discussed further. 6.1.1.2 Mobile IPv6-specific issues The Mobile IPv6 case differs from Mobile IPv4 in that an FA is not required in the data path and the Route Optimization process between the MN and CN is basically used to avoid the triangular routing in the Mobile IPv4 scenarios as shown in Figure 6 [10]. Therefore, if the use of route optimization is not mandatory, data flow routing and Lee, et al. Expires January 17, 2005 [Page 30] Internet-Draft Applicability Statement July 2004 NSIS signaling procedure (including the CRN discovery and the Path Update) of Mobile IPv6 would be similar to that of the Mobile IPv4 described in Section 6.1.2.1. When an MN (as a sender) arrives at a new AR and the binding process is successfully completed, for downstream signaling flow, the MN may initiate NSIS signaling for DCRN discovery and the (downstream) Path Update to establish the state along the new path between the MN and the CN or the tunneling path from the MN to the HA if the reverse tunnel is used, as shown in Figure 6 (a) & (b), repectively. for upstream signaling flow, the CN may also update the state along the common path toward the HA through the Path Update and afterward the NSIS state along the tunneling segment from the HA to the MN may be updated by interaction with IP tunneling as shown in Figure 6 (d). However, if the route optimization is performed successfully between the CN and the MN, for upstream flow, CN needs to newly initiate NSIS signaling to discover an appropriate UCRN and do the Path Update along a new path between the CN and the MN as shown in Figure 6 (c): bidirectional state establishment may be required. In this case, the obsolete path of the existing tunneling segments needs to appropriately be removed after re-establishment of NSIS state along the optimized path. However, when to remove the tunneling segment and/or how to tear it down through the interworking with the IP-tunneling is still an open issue. Although the routing of Mobile IPv4 with the co-located CoA is similar to that of Mobile IPv6 as shown in Figure 5 (a), (c) and (e), one of the differences between the Mobile IPv6 and the Mobile IPv4 is the method to acquire the CoA. That is, the Mobile IPv6 can usually acquire the CoA from the corresponding access router or external method through the stateless autoconfiguration or the stateful autoconfiguration (e.g., DHCPv6), respectively , and the Mobile IPv4 obtains the co-located CoA using an external method such as DHCP. This difference may have some effects on the creation of flow identifier and make NSIS signaling performed differently according to Mobile IP mode. However, it is still open and needs to be discussed further in the later version of this draft. MN CN | | |IPv6+HomeAdressOpt | |--------------------------------------------->| | | (a) MIPv6: MN-->CN, no reverse tunnel Lee, et al. Expires January 17, 2005 [Page 31] Internet-Draft Applicability Statement July 2004 MN HA CN |IPv6(tunnel) | | |------------->| IPv6(normal) | | |------------------------------>| | | | (b) MIPv6: MN-->CN, with reverse tunnel CN MN | | | MIPv6(RH Type 2) | |--------------------------------------------->| | | (c) MIPv6: CN-->MN, route optimization CN HA MN |IPv6(normal) | | |------------->| | | | MIPv6(tunnel) | | |------------------------------>| | | | (d) MIPv6: CN-->MN, no route optimization Figure 6. Implications for signaling under different Mobile IPv6 scenarios 6.2 Multihoming/make-before-break scenarios 6.2.1 Overview A host that is an initiator or responder of signaling messages may be either multi-homed or mobile in some cases. Especially, when current activities in the multi6 WG are considered, multi-homed hosts and scenarios may be very common in a future IPv6 Internet. Such scenarios may also include load balancing techniques, i.e., when multiple connections to different providers are used simultaneously. Therefore, multi-homed hosts may use different paths that converge at some CRN. If load balancing is active, the paths are used at the same time, but if multi-homing is used for resilience only, the active path changes during fail-over. For mobile hosts flow paths are changed when the point of network attachment is changed. This may also require a change of state in network elements along the old and new paths.The term "seamless mobility" is often referred to mean that the MN is able to keep an ongoing session seamlessly (without experiencing perceivable service Lee, et al. Expires January 17, 2005 [Page 32] Internet-Draft Applicability Statement July 2004 interruption or performance penalty) during and after moving from one access network to another. Measures to achieve seamless mobility include soft handover and anticipated handover [QoSSig4G]. The former requires the MN to keep the old path, while data is received over the new path. This approach is only possible if the MN is multi-homed. Appendix B discusses fast state installation by using anticipated handovers, in which the MN signals the new path while still connected to the old one. 6.2.2 NTLP/NSLP support NTLP uses endpoint address to install message routing state, thus the new address for an MN introduced in MIP has to invoke a change of message routing state. In multihomed MN scenarios, both new address and old address can be valid during a certain period of time, the new data path may co-exist with the old one. It is theoretically possible to perform certain NSIS state update in the new path during this period, however the signaling ends need to be careful, so that the correct routing information will be delivered for setting up new or updating existing message routing state in the correct path segment. Furthermore, performing such actions should not cause NSLP service interruption, protocol misbehaviors or security holes and thus should be discouraged. 6.3 QoS Performance Considerations in mobility scenarios The routing characteristics of mobile IP system described in Section 6.1 cause the session path to be changed and in this case the exiting protocols which do not support signaling in dynamic environment where route change or mobility event occurs can cause the problems addressed in Section 3.1. Particularly, in mobile/wireless environments, QoS parameters such as resource utilization and signaling latency need to be considered so that how NSIS protocols should interact with mobility protocols is correctly evaluated. In the perspective of resource utilization, the double reservation problem leading to the waste of resource and call blocking is generally known in handover scenarios and it may be alleviated by the procedure of the CRN discovery and the Path Update described in Section 4. In this section, we take into consideration on how the resource utilization of the NSIS signaling flow itself can be managed: The adjustment of refresh time interval and refresh reduction. The NSIS protocol suite normally use a soft-state approach based on the peer-to-peer refreshing to manage state in NEs. At the GIMPS layer, the state is maintained through the exchange of GIMPS query/ response messages between adjacent peers [2]. In this case, the peer relationship is maintained using a timer which implies how long the Lee, et al. Expires January 17, 2005 [Page 33] Internet-Draft Applicability Statement July 2004 association between the peers can be considered valid. That is, if it has not been refreshed until the timer expires (e.g., after 30 seconds as a default value), the peer relationship is removed. The management of state (i.e., routing state and messaging association) can be controlled in this way. In case of QoS-NSLP, states are also set up and then maintained for the reservation of desired resources using the peer-to-peer refresh messages. The peer-to-peer based refreshment allows the QoS-NSLP to appropriately select the refresh time by considering the current network environment. For example, it may set the refresh timer value in the mobile/wireless (access) network to a smaller value than that in the core (wired) network by the method described in [11]. In the situation of frequent handover, the adjustment of the refresh time results in minimizing the waste of resources. Note that, however, unlike the QoS-NSLP, the refresh time of NTLP state doesn't need to be adjusted according to the type of the network from the perspective of resource utilization. Furthermore, NTLP state along the obsolete path does not also need to be explicitly removed before the expiration of refresh timer. In mobile and wireless networks, the QoS-NSLP (rather than the NTLP) is able to set the refresh timer value depending on the handover type (e.g., make-before-break or break-before-make handovers ) or the reservation style (e.g., pre-establishment or re-establishment) to optimize the resources utilization. For example, in the make-before-break handover, appropriate refresh time intervals are able to be notified using the reserved field of REFRESH object, and if the refresh time value is set to a little higher value than the estimated handover latency, the MN can be provided with seamless QoS service using the pre-reserved resources, and the resources which are pre-reserved but unused will be timely released after handover [12]. After the state along a new path established, QNEs along the signaling path may send refresh message to the neighboring peer node before the expiration of refresh timer to only update the state previously installed along the path or the changed flow ID along the common path after the CRN discovery. In this case, the overhead required to perform refreshes can be reduced, in similar way to that proposed for RSVP [Refresh Reduction]: Refresh Reduction. Once a RESPONSE message has been received indicating the successful installation of a reservation, subsequent refreshing RESERVE messages can simply refer to the existing reservation, rather than including the complete reservation specification. For example, only the Session_ID and the SII with no QSPEC at all are sent to just refresh the state (e.g., reservation) previously installed and additionally the changed flow ID with together those ID is only sent to update it along the common path. Especially, the use of reduced refresh messages over wireless channels or in access networks as well as in core networks results in having the advantage of efficient Lee, et al. Expires January 17, 2005 [Page 34] Internet-Draft Applicability Statement July 2004 utilization of resources. As mentioned in Section 3.1, in the mobility scenarios unlike the route change, the end-to-end signaling problem according to the Path Update gives rise to the deterioration of network performance such as the signaling overhead, service blackout, and so on. To reduce signaling latency in the Mobile IP-based scenarios, the NSIS protocol suit needs to interwork with localized mobility management (LMM). If the GIMPS/QoS-NSLP protocols operate over Hierarchical Mobile IPv6 and the CRN is discovered between an MN and MAP, the procedure of the Path Update can be localized. However, it needs to be discussed further how the Path Update is performed with scoped signaling messages within the access network under the MAP. In the inter-domain handover, additional latency occurs to perform the NSIS signaling procedure including authentication and authorization rather than that in the intra-domain handover. In this case, a possible scenario for mitigation of the latency penalty may be that the MN is multi-homed, or the NSIS protocols interact with mobility protocols such as Seamoby protocols (e.g., CARD and CTP) and FMIP. Another scenario is to use peering agreement which allows that for an aggregate reservation, aggregation authorization is performed once on an inter-domain link without the check of the authorization of each individual session. However, those issues are still open how those approaches can be used by the NSIS protocol suit. 6.4 Use cases of Identifiers The current NTLP and QoS-NSLP drafts have defined important identifiers including Session Identifier (SID), flow identifier, signaling application identifier (NSLPID), Source Identification Information (SII), Reservation Sequence Number (RSN), and so on. These IDs are useful for different purposes in NSIS signaling. When an NSIS signaling message (e.g., RESERVE) with an existing SID and a different SII is received, an NE (e.g., QNE) knows its upstream peer has changed. In mobile environments, the SID and SII can be used to detect the CRN. For example, after the handover of an MN, if an NE (e.g., QNE) on the data path receives an NSLP message (e.g., RESERVE) with an SID for which it already has state installed but with a different SII, the QNE can determine that it is a merging point (i.e., an NSLP CRN) of the old and new paths, accordingly, involve state setup in the new path and teardown of the state on the old path. However, if an NE (e.g., QNE) receives an NSIS message (e.g., RESERVE) with a special flag (e.g., NO_REPLACE flag) set but with the different SII, teardown of the state on the old path should not happen. This may apply to a ping-pong type of handover where an MN wishes to keep state to its old attachment point in case it moves Lee, et al. Expires January 17, 2005 [Page 35] Internet-Draft Applicability Statement July 2004 back there. It is also possible to discover the CRN using message the routing information (MRI) and SID at the GIMPS level. The MRI is used by GIMPS in determining the correct next GIMPS hop for the signaling message [2]. Whether the CRN is discovered by NTLP or NSLP is still an open question. If the CRN is discovered using the MRI, the SII may be redundant in terms of CRN discovery. In any case, the MRI should be consistent with the SII. The data flow will typically be classified by the flow identifier at NEs. The flow identifier may change due to mobility. In this case, it should be updated on the common path so that the data flow can get necessary treatment. The RSN may be useful in detecting duplicate messages in the mobile environment. For example, it is possible for the MN to move to the 2nd NAR soon after being attached to the 1st NAR. In this case, an NSIS node may receive the RESERVE message twice. The problem arises without using RSN, when the RESERVE message from the 1st NAR arrives later than the RESERVE message from the 2nd NAR. Optionally, although a mobility object has not been defined in the NTLP/NSLP drafts, it may be used to inform of the handover of an MN or a route change [12] and therefore to expedite the CRN discovery. The mobility object may be defined in the NTLP (e.g., in GIMPS payload) or NSLP messages to notify of any mobility event explicitly, and it may contain various mobility-related fields, e.g., mobility_event_counter and handover_init fields. The mobility_event_counter field can be used to detect the latest handover event to avoid any confusion about where to send a confirmation message and to handle the ping-pong type of movement described in Section 6.7. The handover_init field can be used to explicitly inform that a handover is now initiated for fast state re-establishment and to handle the invalid NR problem described in Section 6.5. 6.5 Peer Failure Scenarios A dead peer can occur either because a link or a network node, or because the MN moved away without informing NSLP/NTLP (it is recommended to link mobility- and NSIS signaling such that this does not happen). Dead peers of interest in mobility scenarios include CRN, MN, and AR. In general, it is possible that only NSIS functions (i.e., NTLP/NSLP) of the node may fail, or the physical hardware. Lee, et al. Expires January 17, 2005 [Page 36] Internet-Draft Applicability Statement July 2004 An MN may either fail or move. When it fails, it becomes a dead peer. When it moves, it either retains or changes its IP address (e.g., CoA). If it moves and changes its IP address without notifying NSLP/NTLP, it also becomes a dead peer. The failure of a (potential) NSIS CRN may result in incomplete state re-establishment on the new path and incomplete teardown on the old path after handover. In this case, a new CRN should be discovered immediately by the CRN discovery procedure described above. The failure or movement of an MN may cause the 'invalid NR' problem [12] where the NR is the MN. If the MN moves, care should be taken to prevent the teardown of NSIS state on the old path before the NSIS state is re-established on the new path. In this case, an error message should not be generated/sent to avoid any teardown on the old path. It may be possible that the MN is not the NR, but a router in the access network (possibly the AR) is proxying for the MN instead. The failure of an AR may make the interactions with seamoby protocols (such as CARD and CT) impossible. In this case, the neighboring peer closest to the dead AR may need to interact with such protocols. In any case, dead peers should be discovered fast to minimize service interruption. The procedures for dead peer discovery (DPD) should be the same no matter why a peer is dead, because an NE discovering a dead peer cannot judge the specific reason. The procedures for DPD should be handled by the NTLP. In fact, the DPD can be considered as an extension to the GIMPS peer discovery. A peer discovery message can be periodically transmitted to the neighboring peer (e.g., responding node in [2]), and the responding node can send a response message. To determine if the peer is alive, the use of a timer may be helpful. For example, the response message may need to be received by the sender (e.g.,querying node in [2]) before the timer expires. Otherwise, the responding node can be considered dead. Lee, et al. Expires January 17, 2005 [Page 37] Internet-Draft Applicability Statement July 2004 7. Security Considerations This section describes authorization issues for mobility scenarios in NSIS. It tries to raise additional questions beyond those discussed in [13]. For the discussion of various authorization problems we assume that initial authorization is strongly coupled to authorization handling in subsequent message interactions. Making this assumption has some implication to the signaling message behavior. It is certainly possible that the entities who request the initial reservation or a firewall pinhole and those who subsequently cause modifications are not the same entities. NSIS NSLPs define a flexible authorization scheme. As argued in [14] it is necessary to consider cases where the sender, the receiver or both are authorizing a reservation. For NAT and Firewall signaling it is necessary that, the sender and the receiver, authorize the creation of a NAT binding and the creation of a firewall pinhole. Subsequently, we will consider the case where the mobile node acts as a data sender followed by a discussion of the CN as a data sender. 7.1 MN as data sender This section refers to Figure 2 where the MN acts as a data sender which moves from one point of attachment to another. This description starts with an initial flow setup triggered by the MN which is also authorized by the MN. 7.1.1 MN is authorizing entity This scenario considers the initial flow setup executed by the MN whereby the MN provides authorization for the initial flow setup. The initial setup might be used to create state for subsequent authorization actions by the MN. It is obvious that the authorization for the NSLP application (e.g., QoS NSLP) has to provided. Depending on the underlying authorization model it might be either peer-to-peer or end-to-middle. This authorization decision can possibly be treated independent of the authorization issues discussed in this section. MN CN ------>----->------>------>------>------>------> + ACTION (MN is authz) | Lee, et al. Expires January 17, 2005 [Page 38] Internet-Draft Applicability Statement July 2004 | <-----<-----<------<------<------<------<------- | Flow ACK | Setup | | ===============================================> + Traffic Figure 7: MN authorized initial reservation The following questions seem to be interesting: - Should the MN indicate that it is the authorizing entity for subsequent actions to all entities along the path? - What information should be used for this purpose? - Who should add this information? Should the visited network of the MN add something to the signaling message during the initial flow setup? - How do other entities along the path learn this information? Next, the case for a mobile node authorizing the DCRN is considered. This communication is illustrated in Figure 8. The movement of the mobile node after the initial flow setup requires authorization. Various session ownership authorization issues are illustrated in [13]. MN DCRN CN + E.g. ------>----->------>------>------>------>------> | Movement ACTION | with state | creation at <-----<-----<------<------<------<------<------- + new path ACK Figure 8: MN authorizes DCRN The following questions are of interest: - Why should the DCRN execute something on behalf of the MN? (i.e., why should it trust the MN and what information can the DCRN use for verification?) As an example, the DCRN might delete state along the old segment. Lee, et al. Expires January 17, 2005 [Page 39] Internet-Draft Applicability Statement July 2004 - Should the DCOR alone be able to start signaling (the DCOR might be a designed node in some mobility protocols (e.g., MAP)) since it is the node which has more information that other nodes based on the mobility signaling protocols? - How should other nodes between the MN and the DCRN and the nodes between the DCNR and the CN know that the DCRN is now acting on behalf of the MN? The case of a corresponding node triggering an action is discussed. shows the exchange graphically. In this scenario the CN wants to, for example, tear-down a reservation. MN DCNR CN <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + TRIGGER | E.g. | Tear | Down ------>----->------>------>------>------>------> | ACTION | | <-----<-----<------<------<------<------<------- + ACK Figure 9: CN triggers action The following questions arise: - Why should the MN trust the trigger? - Is it possible to specify the security properties of the trigger message in more detail? Is this an NSIS signaling message? - The discussions about an indicator which entity to charge for the reservation might be relevant (see [14]). - Should the CN restrict the actions of the MN (e.g., delete, update, create)? On the shared segment it might, for example, be possible to restrict the allowed action to a flow identifier update. 7.1.2 CN is authorizing entity This scenario is similar to the CN triggering in Section 7.1.1. Two Lee, et al. Expires January 17, 2005 [Page 40] Internet-Draft Applicability Statement July 2004 slightly different protocol variations will be considered. Authorizing some actions in the reverse data flow direction is more difficult as it can easily be seen in Figure 10. 7.1.2.1 CN asks MN to trigger action (on behalf of the CN) In Figure 10 the CN authorizes the MN to start signaling after, for example, a movement. After receiving the trigger message (and some authorization information) the mobile node starts signaling along the new segment and automatically discovers the DCRN. The message travels along the shared segment to the CN and updates the flow identifier (if necessary). The MN might additionally allow the DCRN to delete the reservation along the old segment. MN DCRN CN <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + TRIGGER | | ------>----->------>------>------>------>------> | ACTION (CN is authz; MN on behalf of CN) | +-----------------+ +-----------------+ | | Action: | | Action: | | | 'create' along)| | 'update' along)| | | new segment) | | shared segment)| | Action +-----------------+ +-----------------+ | <------<------<------- | +-----------------+ | | Action: | | | 'delete' along)| | | old segment) | | +-----------------+ | <-----<-----<------<------<------<------<------- | ACK | | | ===============================================> | Traffic + Figure 10: CN asks MN to trigger an action (on behalf of the CN) The following questions need to be considered: - How should the "delegation" mechanism work such that intermediate nodes believe the MN that it is acting on behalf of the CN? - Is it possible to carry this information with the trigger message Lee, et al. Expires January 17, 2005 [Page 41] Internet-Draft Applicability Statement July 2004 from the CN and the MN? 7.1.2.2 CN uses installed state to route message backwards As a second variant the CN uses NSIS installed state to route a signaling message backwards along the path. In some rare cases the DCNR node might be known already. In this case it is possible to stop the update process along the shared segment and to possibly mark installed state along the old segment for deletion. When the MN receives the message it again has to install state along the new segment towards the DCOR. The mobile node might also trigger the deletion of resources along the old segment together with this state creation (pessimistic delete). An optimistic delete operation is certainly more error prone. MN DCNR CN [ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> ] + [ TRIGGER (e.g., MIP) ] | | ------<-----<------<------<------<------<------< | ACTION (CN is authz) | +--------------------+ +-----------------+ | | Action:optimistic | | Action: | | | 'delete' along | | 'update' along)| | | old segment) | | shared segment)| | +--------------------+ +-----------------+ | >------>------>----------->------>------>------- | +-----------------+ ACK | | Action: | | Action | 'create' along)| | | new segment) | | +-----------------+ | <------<------<------- | +-------------------+ | | Action:pessimistic| | | 'delete' along) | | | old segment) | | +-------------------+ | | ===============================================> | Traffic + Figure 11: CN uses installed state to route message backwards Figure 11 raises a few questions: Lee, et al. Expires January 17, 2005 [Page 42] Internet-Draft Applicability Statement July 2004 The security properties of the trigger message need to be evaluated. It is not always possible to route signaling message backwards from the CN to the MN: - state at the new path might not be established (hence the signaling message cannot travel backwards) - the signaling message might not reach the MN via the old segment. In the multi-homing case where the mobile node can be reached via more than one path it is possible to execute this exchange. The same might be true for some local repair cases. The messages triggered by the MN (namely create state along the new segment and the pessimistic 'delete along the old segment) still need to be executed on behalf of the CN. Compared to the first variant there might be some room for optimization since the first message was transmitted by the CN. 7.1.2.3 MN and CN are authorized If we argue that the authorization at the NSLP layer is somehow tight to the authorization for certain protocol actions then we also have to consider the case where the MN and the CN have to contribute to the authorization decision. This situation appears, for example, in the NAT/Firewall signaling case but also in the area of QoS reservation where both parties might need to share the cost of a reservation. If both end hosts are authorized then some signaling message exchanges are less difficult since the trigger message does not need to include authorization information. Some problems, however, do not disappear such as the session ownership problem and additional problems might be caused by certain solution approaches. Since this section does not discuss solutions the reader is referred to the [13] draft which lists a few strawman proposals for addressing the session ownership problem. 7.1.3 CN as data sender In this section we consider the scenarios where the CN acts as a data sender. Figure 2 shows the topology and the participating entities. 7.1.3.1 CN is authorizing entity Lee, et al. Expires January 17, 2005 [Page 43] Internet-Draft Applicability Statement July 2004 This scenario is similar to the one described in Section 7.1.1. No additional problems arise with a scenario where the CN is both data sender and also the authorizing entity. In Figure 8 the CN authorizes the UCNR to delete the old segment and to establish a new reservation along the new segment. Furthermore, at the shared segment only an update of the flow identifier might be necessary. MN UCNR CN + E.g. <-----<-----<------<------<------<------<------- | Create ACTION | new +-----------------+ | +-----------------+ | State | Action: | | | Action: | | | 'create' along)| | | 'update' along)| | | new segment) | | | shared segment)| | +-----------------+ | +-----------------+ | <------<------<--------+ | +-----------------+ | | Action: | | | 'delete' along)| | | old segment) | | +-----------------+ | | >----->----->------>------>------>------>------> | ACK (along new path) | | <=============================================== + Traffic Figure 12: CN as data sender is authorized Since the mobile node first detects the route change. A trigger to the CN allows the CN to quickly react on the route change. There are three variants: - The MN sends a trigger to the CN and the CN starts signaling as shown in Figure 12. - The MN routes the message back along the reverse path using the previously established state along the old route. This mechanism only works if the MN is able to send messages along the old path. As a generic mechanism this is not suggested. - An intermediate node act on its own. This might be possible that the UCRN is an entity which participates in the mobility signaling (e.g., Mobility Anchor Point (MAP)) exchange. Depending on the Lee, et al. Expires January 17, 2005 [Page 44] Internet-Draft Applicability Statement July 2004 message exchange it needs to be studied whether the signaling message provides sufficient authorization to trigger the NSIS exchange. 7.1.3.2 MN is authorizing entity In this scenario we consider the case where the CN is the data sender but the MN authorizes actions. The considerations are similar to those elaborated in Section 7.1.3 where the MN is the data sender but the CN is the authorizing entity. 7.1.4 Multi-homing Scenarios Multi-homing scenarios have the property that the more than one path belongs to a signaling session. In Figure 13 the MN uses two interfaces to route NSIS message towards the CN. The two individual sessions are tight together with the same session identifier. The MN needs to indicate that both reservations need to be kept alive (and the DCRN should not delete a reservation). At the shared segment only a single reservation is stored. From an authorization point of view the session ownership issues is applicable since the DCRN needs to merge the two reservations into a single one along the shared segment. 7.1.4.1 MN as data sender This section shows the multi-homing scenario with the MN as a data sender. segment 2 +---+ ^>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>V ^ +---+ V +----+ +----+ +--+ | MN | |DCNR|>>>>>>>>>>|CN| |UCNR| | |>>>>>>>>>>| | +----+ +----+ +--+ v +---+ ^ shared v>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>^ segment +---+ segment 1 ===============================================================> Traffic Figure 13: Multi-homed MN as data sender Lee, et al. Expires January 17, 2005 [Page 45] Internet-Draft Applicability Statement July 2004 If the MN is the authorizing entity then the session ownership problem needs to be solved. Without solving this type of authorization problem it is possible for an adversary to "join" the reservation at the shared segment. Furthermore, it is an open issue whether reservation merging is allowed only for cases where one flow identifier is used at different interfaces or even with different flow identifiers. If the CN is the authorizing entity then, again, some message needs to be sent from the CN to the MN to trigger the exchange or to route the request backwards along the established path. The MN is reachable via the two paths. Mobility handling might be smoother since it is possible that only one interface experiences an IP address change with all the previously discussed implications. 7.1.4.2 CN as data sender This section shows the multi-homing scenario with the CN as a data sender. The scenario is simpler (for the CN authorizing case) than the one described in Section 7.1 since the signaling message along the shared segment travels the previously established path. It shows some similarities with a route change scenario. At the mobile node itself the two paths merge which again leads to a session ownership problem. How should the MN know whether a signaling message with the same session identifier hitting a different interface belongs to the indicated session authorized by the CN? If the MN is the authorizing entity then again communication between the end hosts is required as a trigger. Routing the signaling messages in the reverse path might, in some cases, also be possible. segment 2 +---+ v<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<<^ v +---+ ^ +----+ +----+ +--+ | MN | |UCRN|<<<<<<<<<<|CN| |DCRN| | |<<<<<<<<<<| | +----+ +----+ +--+ ^ +---+ v shared ^<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<