idnits 2.17.1 draft-manyfolks-signaling-protocol-mobility-01.txt: -(978): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1013): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2560. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2576), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 783 has weird spacing: '...p state previ...' == Line 1076 has weird spacing: '...ier and end-t...' == Line 1161 has weird spacing: '...ization betwe...' == Line 1283 has weird spacing: '...S state along...' == Line 1348 has weird spacing: '...nneling as sh...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 19, 2004) is 7213 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'NTLP' on line 1082 -- Looks like a reference, but probably isn't: 'QoSSig4G' on line 1430 -- Looks like a reference, but probably isn't: 'LMM' on line 2193 -- Looks like a reference, but probably isn't: 'HMIPv6' on line 2196 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-02 == Outdated reference: A later version (-07) exists of draft-ietf-nsis-fw-06 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-02 == Outdated reference: A later version (-02) exists of draft-fessi-nsis-natfw-threats-00 == Outdated reference: A later version (-10) exists of draft-ietf-mip4-rfc3344bis-00 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '10') (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-03 -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 15 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Next Steps in Signaling S. Lee, Ed. 2 Internet-Draft SAMSUNG AIT 3 Expires: January 17, 2005 S. Jeong 4 HUFS 5 H. Tschofenig 6 Siemens AG 7 X. Fu 8 Univ. of Goettingen 9 J. Manner 10 Univ. of Helsinki 11 July 19, 2004 13 Applicability Statement of NSIS Protocols in Mobile Environments 14 draft-manyfolks-signaling-protocol-mobility-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, 20 and any of which I become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 17, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). All Rights Reserved. 45 Abstract 47 Mobility of an IP-based node affects routing paths, and as a result, 48 can have a dramatic effect on protocol operation and state 49 management. This draft discusses the effects mobility can cause to 50 the NSIS protocols, and how the protocols operate in different 51 scenarios, and together with mobility management protocols. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Problem Statement and General Considerations . . . . . . . . . 8 58 3.1 Problem statement . . . . . . . . . . . . . . . . . . . . 8 59 3.2 General Considerations . . . . . . . . . . . . . . . . . . 10 60 4. Basic operations for mobility support . . . . . . . . . . . . 11 61 4.1 Generic Route Changes and Mobility . . . . . . . . . . . . 11 62 4.2 CRN Discovery . . . . . . . . . . . . . . . . . . . . . . 14 63 4.2.1 Possible approaches for CRN discovery . . . . . . . . 14 64 4.2.2 The identifiers for CRN discovery . . . . . . . . . . 15 65 4.2.3 The procedure of the CRN discovery . . . . . . . . . . 17 66 4.3 Path update . . . . . . . . . . . . . . . . . . . . . . . 18 67 4.3.1 State setup and update . . . . . . . . . . . . . . . . 18 68 4.3.2 State Teardown . . . . . . . . . . . . . . . . . . . . 20 69 5. Mobility-Related Issues with NSIS Protocols . . . . . . . . . 22 70 5.1 Specific Issues with NTLP . . . . . . . . . . . . . . . . 22 71 5.2 Specific Issues with QoS-NSLP . . . . . . . . . . . . . . 23 72 5.3 Specific Issues with NAT/FW NSLP . . . . . . . . . . . . . 24 73 5.4 Common issues related to NTLP and NSLP . . . . . . . . . . 25 74 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 26 75 6.1 Support for Macro Mobility-based scenarios . . . . . . . . 26 76 6.1.1 Implications to Mobile IP-related scenarios . . . . . 27 77 6.1.1.1 Mobile IPv4-specific issues . . . . . . . . . . . 28 78 6.1.1.2 Mobile IPv6-specific issues . . . . . . . . . . . 30 79 6.2 Multihoming/make-before-break scenarios . . . . . . . . . 32 80 6.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 32 81 6.2.2 NTLP/NSLP support . . . . . . . . . . . . . . . . . . 33 82 6.3 QoS Performance Considerations in mobility scenarios . . . 33 83 6.4 Use cases of Identifiers . . . . . . . . . . . . . . . . . 35 84 6.5 Peer Failure Scenarios . . . . . . . . . . . . . . . . . . 36 85 6.6 Guidelines for design of NTLP and NSLPs . . . . . . . . . 37 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 87 7.1 MN as data sender . . . . . . . . . . . . . . . . . . . . 38 88 7.1.1 MN is authorizing entity . . . . . . . . . . . . . . . 38 89 7.1.2 CN is authorizing entity . . . . . . . . . . . . . . . 40 90 7.1.2.1 CN asks MN to trigger action (on behalf of the 91 CN) . . . . . . . . . . . . . . . . . . . . . . . 41 92 7.1.2.2 CN uses installed state to route message 93 backwards . . . . . . . . . . . . . . . . . . . . 42 94 7.1.2.3 MN and CN are authorized . . . . . . . . . . . . . 43 95 7.1.3 CN as data sender . . . . . . . . . . . . . . . . . . 43 96 7.1.3.1 CN is authorizing entity . . . . . . . . . . . . . 43 97 7.1.3.2 MN is authorizing entity . . . . . . . . . . . . . 45 98 7.1.4 Multi-homing Scenarios . . . . . . . . . . . . . . . . 45 99 7.1.4.1 MN as data sender . . . . . . . . . . . . . . . . 45 100 7.1.4.2 CN as data sender . . . . . . . . . . . . . . . . 46 101 7.1.5 Proxy Scenario . . . . . . . . . . . . . . . . . . . . 47 102 7.1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . 47 103 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 49 104 8.1 Interaction with Other Mobility-Related Protocols . . . . 49 105 8.1.1 Interaction with Seamoby Protocols . . . . . . . . . . 49 106 8.1.2 Interaction with Local Mobility Management 107 Protocols . . . . . . . . . . . . . . . . . . . . . . 49 108 8.1.3 State Establishment in Network Mobility Scenarios . . 50 109 8.2 Additional Issues on CRN discovery and Path Update . . . . 50 110 8.3 Support for the Ping-Pong Type of Movement . . . . . . . . 50 111 8.4 When both end-hosts are mobile . . . . . . . . . . . . . . 50 112 8.5 Bi-directional State Establishment . . . . . . . . . . . . 51 113 8.6 Priority Reservation . . . . . . . . . . . . . . . . . . . 51 114 8.7 Aggregation of End-to-End Flows in Mobile Environments . . 51 115 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 116 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 53 117 9.2 Informative References . . . . . . . . . . . . . . . . . . . 53 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 54 119 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 120 B. Anticipated Handover . . . . . . . . . . . . . . . . . . . . . 57 121 Intellectual Property and Copyright Statements . . . . . . . . 59 123 1. Introduction 125 The mobility of IP-based nodes incurs route change, usually at the 126 edge of the network. Route change may also be caused by reasons 127 other than mobility, such as routing protocol adaptation in response 128 to varying network conditions (load sharing, load balancing, etc), or 129 host multi-homing. Normal IP mobility (i.e., macro-mobility) also 130 involves the change of mobile node IP addresses. Since IP addresses 131 are usually part of flow identifiers, the change of IP addresses 132 implies the change of flow identifier. Local mobility usually does 133 not cause the change of the global IP addresses, but affects the 134 routing paths within the local access network. 136 The goals of this draft are to present the effects of mobility on the 137 NSIS Transport Layer Protocol (NTLP) and on the NSIS Signaling Layer 138 Protocols (NSLP). The NTLP is an application independent protocol to 139 transport service-related information between nodes in a network. 140 Each specific service has its own NSLP protocol.This draft also 141 discusses how the NSIS protocols should work in various mobility 142 scenarios. 144 The discussion is divided into two parts. The first part discusses 145 the operation of the NSIS protocols in very basic mobility scenarios 146 (e.g., macro-mobility management protocols such as Mobile IPv4 and 147 Mobile IPv6), including support for multi-homing. The second part 148 takes the discussion to more complex scenarios and issues on 149 interworking with various mobility-related protocols such as Seamoby 150 and local mobility management protocols. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [1]. 158 The terminology in this draft is based on [2] and [3]. In addition, 159 the following terms are used. 161 O Downstream 163 The flow from a data sender towards the destination. 165 O Upstream 167 The flow from a data destination towards the sender. 169 O Crossover Node (CRN) 171 A Crossover Node is a node that for a given function is a merging 172 point of two or more separate sets of state information. The CRN 173 may not necessarily be a physical route splitting point. There 174 can be different types of logical (but not necessarily physical) 175 CRNs according to signaling states, flow direction, mobility 176 management, and normal routing (not caused by mobility): 178 From the perspective of NSIS states (i.e., NSLP and NTLP 179 states), the types of CRN are basically classified as follows. 181 NSLP CRN, from the NSLP's point of view, is a signaling 182 application-aware node in the network where the 183 correspondent signaling flows begin to merge or split after 184 route changes and mobility. The NSLP CRN may be different 185 according to the types of NSLP. 187 NTLP CRN, from the NTLP's point of view, is a network node 188 where more than one NTLP states begin to merge or split 189 after route changes and mobility. 191 NSIS CRN is either an NTLP CRN or an NSLP CRN. Note that 192 although the types of CRN differ according to the state 193 information, the CRN required for QoS-NSLP operation is the 194 NSLP CRN which has the corresponding signaling application 195 information to perform the path update. 197 There are some differences between route change and mobility in 198 forming CRN according to the direction of signaling flows 199 followed by data flows 200 In the mobility scenarios, there are two different types of 201 merging point in the network according to the direction of 202 signaling flows followed by data flows as shown in Figure 2 203 of Section 4.1, where we assume that the MN is a data 204 sender. 206 Upstream CRN, after a handover, is the node closest to 207 the data receiver from which the state information 208 towards the data sender begins to diverge. 210 Downstream CRN, after a handover, is the node closest to 211 the data sender from which the state information towards 212 the data receiver begins to converge. 214 In this case, the DCRN and the UCRN may be different due 215 to the asymmetric characteristics of routing although the 216 CN is the same. 218 In the route changes, the path change of signaling flows 219 results in forming a chain of two CRNs regardless of the 220 direction of signaling flows followed by data flows as shown 221 in figure 1 of Section 4.1, which is referred to as a 222 divergence-convergence pair: 224 Upstream CRN, after a route changes, is the node at which 225 the state information towards the data sender begins to 226 diverge, or to converge. As a result, a 227 (divergent-convergent) UCRN pair will be formed. 229 Downstream CRN, after a route changes, is the node at 230 which the state information towards the data receiver 231 begins to diverge, or to converge. As a result, a 232 (divergent-convergent) DCRN pair will be formed. 234 From mobility management point of view, mobility CRN is the 235 node where the old and new paths (physically) merge. Note that 236 in general, mobility CRN may be different from the NSLP CRN or 237 NTLP CRN. 239 Routing CRN is the node where using normal routing, the old and 240 new paths (rather physically) merge. Depending on the location 241 of nodes, the routing CRN may not be equal to the NSLP CRN or 242 NTLP CRN. 244 O Path Update and Local Repair 246 Path Update is the procedure for the re-establishment of NSIS 247 state on the new path, the teardown of NSIS state on the old path, 248 and the update of NSIS state on the common path due to the 249 mobility. This is used to improve mobility handling for the 250 affected flows. 252 Upstream Path Update: Path Update for the upstream signaling 253 flow which is initiated by an upstream signaling initiator. If 254 the MN is a sender, the Path Update is initiated by an NI on 255 the common path (e.g., a CN, an HA, or an MAP). 257 Downstream Path Update: Path Update for the downstream 258 signaling flow which is triggered by a downstream signaling 259 initiator. If the MN is a sender, the Path Update is triggered 260 by an NI on the new path (e.g., an MN, a mobile agent, or an 261 AR). 263 In case of route changes, the update of NSIS state on the common 264 path is not required and it is called Local Repair which localizes 265 the NSIS signaling. Especially, in mobility scenarios, if the 266 NSIS signaling interacts with localized mobility management 267 protocols (e.g., HMIPv6), the Path Update can be localized within 268 the access network. 270 O Dead Peer Discovery (DPD) 272 The procedure for finding a dead NSIS peer due to a link/node 273 failure and due to an MN moving away. 275 O Downlink 277 The direction from the CN towards the MN. 279 O Uplink 281 The direction from the MN towards the CN. 283 3. Problem Statement and General Considerations 285 3.1 Problem statement 287 IP mobility in its simplest form only includes route changes. Still, 288 the various protocols that seek to support the mobility of end hosts 289 may use very special techniques to reach their goals. Most of these 290 techniques are common IP mechanisms that can also be found in fixed 291 networks, and therefore, are not by themselves particular. The 292 operation of NSIS signaling protocols are affected by the following 293 issues: 295 O Change of route and possibly change of the MN IP address 297 Topology changes entail the change of routes for data packets sent 298 to or from the MN and may lead to the change of host IP addresses. 300 O Latency of route changes 302 The change of route and IP addresses is typically much faster and 303 frequent than traditional route changes, for example, those due to 304 failure, adding or removal of nodes/links. 306 O Explicit routes 308 Signaling protocols usually expect the data traffic to follow the 309 same path as the signaling traffic, but the data traffic sometimes 310 traverses the path different from the path of signaling traffic 311 due to the adaptation of routing protocol according to varying 312 network conditions such as load balancing, load sharing and 313 mobility. For example,Mobile IP adds the possibility to use 314 routing headers to define explicit routes, which diverts the 315 traffic from an expected path. 317 O IP-in-IP encapsulation 319 Mobility protocols may use IP-in-IP encapsulation on the segmnts 320 of the end-to-end path for routing traffic from the CN to the MN, 321 and vice versa. Encapsulation harms any attempt to identify and 322 filter. Moreover, encapsulation may lead to changes in the 323 routing paths, since the sender and destination IP address differ 324 from the values in the original user data packet. The same 325 considerations apply if the signaling packets are encapsulated, 326 too. 328 O Ping-pong type handover 330 NSIS needs to remove states quickly along the old path in order to 331 mitigate the waste of resources. However, in a ping-pong type 332 handover, the MN returns to the previous AR after staying with the 333 new AR only for a short while, the prompt removal of state along 334 the old path causes the state to be re-established soon again and 335 it adds overhead. 337 O Upstream Path Update vs. Downstream Path Update 339 Since the upstream and downstream paths may not be equal, the 340 upstream and downstream CRNs may not be equal, either. In this 341 case, Path Update needs to be handled independently for upstream 342 and downstream flows, including, e.g., the discovery of upstream 343 and downstream CRNs. 345 O State identification problem 347 A mobility event may cause the address of flow endpoints to 348 change, and in this case it is desirable that signaling 349 application state is independent of the underlying flow to keep 350 the state from being re-installed completely. Therefore, the 351 session and flow identifiers need to be created separately, and 352 this makes it possible to correlate the session identifier with 353 the signaling application about the different flows with the same 354 network control state. 356 O Double reservation Problem 358 Since the state on the old path (and the common path) still 359 remains as it is after re-establishing the state along the new 360 path due to mobility (or route change), the double reservation 361 problem occurs. Although the existing state on the old path can 362 be torn down by the timeout of soft state, the refresh timer value 363 in the core or wired network is quite long (e.g., 30 seconds in 364 QoS-NSLP). As a result, in case of QoS-NSLP, the double 365 reservation problem leads to the waste of resources and call 366 blocking. 368 O End-to-end signaling Problem 370 The mobility may change the flow identifier, and the change of 371 flow identifier requires state update along the entire path to 372 reflect the physical location of the MN, resulting in the 373 end-to-end signaling. This also incurs a long state setup delay 374 and signaling overhead which affect network performance. 375 Ultimately, the long state setup delay may particularly give rise 376 to the service blackout or degradation for multimedia application 377 in the mobility environment. 379 In summary, NSIS signaling needs to work with basic mobility which 380 can be considered as an extension to the general route (topological) 381 change, to handle the change of IP address, and to support mobile IP 382 tunnels and multi-homing. In this case, Path Update should be 383 localized, and handled independently for upstream and downstream 384 flows. 386 3.2 General Considerations 388 At the first step, this draft discusses NSIS state establishment 389 (e.g., QoS-NSLP, NAT/FW, etc) in the macromobility-based scenarios 390 (e.g., basic Mobile IP (v4 and v6) handovers) and the interaction 391 with the specific micromobility protocols leading to performance 392 optimization of NSIS signaling would be discussed further in the next 393 version of the draft. 395 Our assumptions in this document and the general considerations are: 397 O Session-ID is used to index state 399 Even if an MN has a permanent IP address (its home address), it 400 cannot be used to index state in the network since the home 401 address may not easily be visible to interior nodes. Other types 402 of mobile nodes (e.g., using SIP or other application layer 403 techniques) may not have permanent addresses at all. After a 404 movement it obtains a new CoA, which is the basis for routing its 405 data. If signaling-associated state is indexed based on some 406 temporary data plane information, such as CoA, the state indexed 407 by previous CoAs might be inaccessible for the signaling after 408 most handover procedures. 410 O Routing may be asymmetric 412 IP packets arriving to and leaving the MN may be routed 413 differently. This may be due to the basic triangular routing of 414 MIPv4, due to the operation of an LMM protocol, or due to 415 asymmetric routing caused by the basic operation of the IP routing 416 protocols themselves. 418 O The CN is not a mobile device 420 We may later add text to consider a mobile CN, too. 422 4. Basic operations for mobility support 424 In this section, we discuss the basic operations of NSIS signaling 425 needed after the route changes including the mobility. The basic 426 operations include how an appropriate CRN is discovered and how the 427 Path Update is performed by the NSIS signaling according to the 428 direction of data flows. The procedure of CRN discovery (in Section 429 4.2.3) can be applied in the same way as for both the generic route 430 changes and mobility. However, the Path Update for the generic route 431 changes is different from that for mobility. This draft mainly 432 discusses the Path Update for the route changes caused by mobility. 434 4.1 Generic Route Changes and Mobility 436 The generic route changes occurs due to load sharing, load balancing, 437 an link or node failure, but the mobility is associated with the 438 change of the network attachment point. These cause divergence (or 439 convergence) between the old path along which state has already been 440 installed and the new path along which data forwarding will actually 441 happen. 443 Although the mobility may be considered similar to the route changes, 444 the main difference is that the Message Routing Information (MRI: 445 e.g., flow identifier) may not change after the route change while 446 the mobility may cause the change of MRI by having a new network 447 attachment point. Since the session should remain the same after any 448 mobility event, the MRI should not be used to identify the session of 449 any signaling application [4]. 451 The route changes brings on the change of signaling topology and it 452 results in difference according to the types of route change (e.g., 453 the route changes or mobility). The route changes generally forms 454 two common paths, an old path, and a new path, where the old path and 455 the new path begin to diverge from one common path and afterward to 456 converge to another common path for each direction of signaling flows 457 (e.g., downstream or upstream flows) as shown in Figure 1. 459 Old path 460 +---+ +---+ 461 ^ --->|NE | ... |NE | ------V 462 common path ^ +---+ +---+ V common path 463 +--+ +----+ +----+ +--+ 464 |S |-----> |DCRN| |DCRN| -------> |R | 465 | | | | | | | | 466 +--+ +----+ New path +----+ +--+ 467 V +---+ +---+ ^ 468 V --->|NE | ... |NAR| ------^ 469 +---+ +---+ 471 =======(downstream signaling followed by data flows) ========> 473 (a) The topology for downstream NSIS signaling flow after the 474 route changes 476 Old path 477 +---+ +---+ 478 v <---|NE | ... |NE | ----- ^ 479 common path v +---+ +---+ ^ common path 480 +--+ +----+ +----+ +--+ 481 |S |<----- |UCRN| |UCRN| <------- |R | 482 | | | | | | | | 483 +--+ +----+ New path +----+ +--+ 484 ^ +---+ +---+ v 485 ^ <---|NE | ... |NAR| ----- v 486 +---+ +---+ 488 <=====(upstream signaling followed by data flows) ======== 490 (b) The topology for upstream NSIS signaling flow after the 491 route changes 493 Figure.1 The topology for NSIS signaling in case of the route changes 495 However, the mobility results in creating a common path, an old path, 496 and a new path, and the old and new paths only converge or diverge 497 according to the direction of each signaling flow as shown in Figure 498 2. 500 Old path 501 +--+ +---+ 502 original |MN|------> |OAR| -------------V 503 address +--+ +---+ V common path 504 | +----+ +--+ 505 | |DCRN| -------> |CN| 506 | | | >>>>> | | 507 v New path +----+ ^ +--+ 508 +--+ +---+ ^ ^ 509 New CoA |MN|------> |NAR|--------------^ ^ 510 +--+ +---+ ^ 511 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^ 512 (Binding process) 514 ====(downstream signaling followed by data flows) ======> 516 (a) The topology for downstream NSIS signaling flow due to 517 mobility. 519 Old path 520 +--+ +---+ 521 original |MN|<------ |OAR| -------------^ 522 address +--+ +---+ ^ common path 523 | +----+ +--+ 524 | |UCRN| <------- |CN| 525 | | | >>>>> | | 526 v New path +----+ ^ +--+ 527 +--+ +---+ v ^ 528 New CoA |MN|<------ |NAR|--------------v ^ 529 +--+ +---+ ^ 530 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^ 531 (Binding process) 533 <=====(upstream signaling followed by data flows) ===== 535 (b) The topology for upstream NSIS signaling flow due to 536 mobility. 538 Figure.2 The topology for NSIS signaling caused by mobility. 540 Figure 2: Signaling topology by mobility event. 542 These topological changes caused by mobility make the signaling state 543 established on the old path useless and therefore removed (in the 544 end). In addition, the existing NSIS state should also be 545 re-established along the new path and to be updated along the common 546 path. Note that to minimize the impact on seamless service and 547 improve signaling scalability, NSIS signaling should be localized 548 when route changes (including mobility) occur; the localized 549 signaling procedure is referred to as Local Repair in this draft (in 550 case of the interaction with localized mobility protocols: see the 551 terminology section). As an example, in mobility scenarios, although 552 NSIS signaling messages are initiated by an MN or CN and sent to the 553 opposite terminating point of the path, the path in the wireless 554 access network usually changes only partially. Therefore, the NSLP/ 555 NTLP needs to limit the scope of signaling information to a local 556 section of the signaling path. One of the most appropriate nodes to 557 do the Local Repair (or Path Update) can be the Crossover node (CRN) 558 where the old and new session paths meet. 560 The NTLP module (of a node experiencing a topological change) should 561 detect it through the various mechanisms described in [4] at 562 transport level and triggers the NSLP operation over itself, and then 563 the NSLP should initiate necessary NSIS state establishment (i.e., 564 QoS re-establishment) along the new path and the update or removal of 565 associated states, at the signaling application level. Note that in 566 the case of QoS-NSLP, state re-establishment due to the route changes 567 does not need any state update along the entire signaling path since 568 the flow identifier does not change (in other words, the IP address 569 of endpoint does not change). 571 4.2 CRN Discovery 573 4.2.1 Possible approaches for CRN discovery 575 The approaches for CRN discovery can be divided into two classes 576 according to which layer is responsible for the discovery of CRN, and 577 whether the discovery is coupled with the transport of signaling 578 application messages. 580 From the NSIS protocol stack point of view, the CRN can be discovered 581 at both NTLP and NSLP layers. First, the CRN discovery at the NSLP 582 layer is possible using the information contained in NSLP signaling 583 messages sent from the signaling initiator. For example, NSLP can 584 realize that it is a CRN by comparing the Source Identification 585 Information (SII) contained in the incoming signaling message to the 586 one stored previously in the node. However, since NTLP is 587 responsible for detecting the path change of data (or signaling) flow 588 (and the route changes may easily be detected at the NTLP level 589 rather than at the NSLP), CRN discovery can be considered as an 590 extension to the peer discovery at the NTLP level (e.g., using GIMPS 591 query-response [2]). In general, the GIMPS message has message 592 routing state information such as flow/session/signaling application 593 identifier, so signaling application can be identified at the NTLP 594 level. For example, in the connection mode of NTLP, when NTLP 595 establishes a messaging association between two adjacent peers, the 596 NTLP peers exchange message routing state information through GIMPS 597 query and response messages. Therefore, although the CRN can be 598 discovered at the NTLP level, the discovered CRN could be actually 599 NSLP-aware node which has an involved signaling application. 601 There can also be two different approaches for CRN discovery 602 according as whether the discovery is coupled with signaling message 603 or not: the coupled approach and uncoupled approaches. If the 604 signaling to update NSIS state along a new path or the common path, 605 after route changes or mobility, is done simultaneously with the CRN 606 discovery procedure, it is called the coupled approach. If the 607 signaling to do Path Update is done after the CRN discovery is 608 completed, it is called the uncoupled approach. These approaches may 609 have some effect on security aspect. Generally, the coupled approach 610 would be preferred to the uncoupled approach to reduce the delay for 611 signaling setup. Note that CRN discovery and Path Update described 612 in this draft are based on the coupled approach. 614 4.2.2 The identifiers for CRN discovery 616 There are some basic identifiers which can be used for CRN discovery 617 at the NTLP level: session identifier, flow identifier (MRI), and 618 signaling application identifier (NSLP_ID) related to message routing 619 state [2]), and NSLP branch identifier related to the direction of 620 NSIS signaling branch. 622 The session identifier in the GIMPS message is used to easily 623 identify the involved session because it remains the same while the 624 MRI may (or may not) change due to handover. The MRI is used to 625 specify the relationship between the address information and the 626 state (e.g., QoS-NSLP state) re-establishment. In other words, the 627 change of MRI indicates topological changes and therefore it 628 represents that the state along the common path should be updated 629 after the CRN discovery. 631 The signaling application identifier (NSLP_ID) is used to refer to 632 the corresponding NSLP at GIMPS level, and in the context of CRN 633 discovery it helps to discover an appropriate NSLP CRN using the 634 GIMPS peer discovery message. 636 The NSLP branch identifier as a virtual branch identifier can be used 637 to establish or delete NSIS associations between peers and it can 638 also be used as an identifier to determine the CRN at the GIMPS 639 layer. The NSLP branch identifier can consist of the location 640 information of peer nodes with the correspondent NSLP ID by the 641 procedure of GIMPS message association. For instance, as shown in 642 Figure 3, for the downstream case, NSLP1 of node A requires a 643 messaging association for sending its messages towards node D after a 644 route changes. In this case, NSIS entity A creates an NSLP branch ID 645 for NSLP 1 toward node D and increases the counter of NSLP branch ID 646 to locally distinguish each virtual interface identifier between 647 adjacent NSLP peers: the corresponding NSLP br.ID is 1-D-#2. Note 648 that the NSLP branch identifier can be included in the NSIS message, 649 but it can also be considered as an implementation issue. This 650 identifier would be more useful when the merging point of the old 651 path and a new path is not an NSLP CRN after the route change. 653 Old path 654 +-----+ +-----+ 655 ^---->|NSLP1| ... |NSLP1| ----V 657 common path ^ +-----+ +-----+ V common path 658 +-----+ +-----+ C K +-----+ +-----+ 659 --->|NSLP1|--->| | | |--->|NSLP1|--> 660 |NSLP2| |NSLP2| |NSLP2| |NSLP2| 661 +-----+ +-----+ New path +-----+ +-----+ 662 A B V +-----+ +-----+ ^ M N 663 V--->|NSLP1| ... |NSLP1| ----^ 664 +-----+ +-----+ 665 D L 667 =======(Flow direction) ========> 669 (a) NSIS signaling topology for downstream signaling flow after the 670 route changes in the middle of the network 672 +------------------+-------+-------+--------+------------+-------+ 673 | Message Routing |Session| NSLP |Upstream| Downstream | NSLP | 674 | Information | ID | ID | Peer | Peer |Br. ID | 675 +------------------+-------+-------+--------+------------+-------+ 676 | Method = Path | 0xABCD| NSLP1 | Z | Pointer to | 1-D-#1| 677 |Coupled; Flow ID =| | | | A-C | | 678 | {IP-#X, IP-#V, | | | | Pointer to | 1-D-#2| 679 | protocol, ports} | | | | A-D | | 680 | | | | | | 1-U-#1| 681 | Method = Path | | | | | | 682 |Coupled; Flow ID =| 0x1234| NSLP2 | Z | (null) | 2-D-#1| 683 | {IP-#X, IP-#V, | | | | | | 684 | protocol, ports} | | | | | 2-U-#1| 685 +------------------+-------+-------+--------+------------+-------+ 687 (b) Routing state table at node A (NSLP CRN) 689 +------------------+-------+-------+----------+----------+-------+ 690 | Message Routing |Session| NSLP |Upstream |Downstream| NSLP | 691 | Information | ID | ID | Peer | Peer |Br. ID | 692 +------------------+-------+-------+----------+----------+-------+ 693 | Method = Path | 0xABCD| NSLP1 |Pointer to| (null) | 1-U-#1| 694 |Coupled; Flow ID =| | | K-N | | | 695 | {IP-#X, IP-#V, | | |Pointer to| | 1-U-#2| 696 | protocol, ports} | | | L-N | | | 697 | | | | | | 1-D-#1| 698 | Method = Path | | | | | | 699 |Coupled; Flow ID =| 0x1234| NSLP2 | M | (null) | 2-U-#1| 700 | {IP-#X, IP-#V, | | | | | | 701 | protocol, ports} | | | | | 2-D-#1| 702 +------------------+-------+-------+----------+----------+-------+ 704 (C) Routing state table at node N (NSLP CRN) 706 Figure.3 Routing state table and NSLP branch ID 708 Optionally, the mobility identifier as an object form can also be 709 used for immediate CRN discovery in various mobility scenarios. The 710 mobility object can also be used for other purposes. The more 711 details are discussed further in Section 6.4. 713 4.2.3 The procedure of the CRN discovery 715 In general, when a mobility event occurs, the CRN can be recognized 716 by comparing the existing message routing information (e.g., the NSLP 717 ID, the session identifier and MRI) and the NSLP branch ID with the 718 message routing information and the NSLP branch ID (with different 719 counter number) included in the NTLP peer discovery message initiated 720 by an NI (e.g., an MN or a CN). For example, if an NTLP message is 721 routed to an NSIS peer node, the following information (shown in 722 Figure 3 (b) and (c)) is checked: 724 - Whether the same NSLP ID exists, 726 - Whether the corresponding CRN is already discovered, 728 - Whether the same session identifier and MRI exist, 730 - Whether the NSLP branch identifier is changed: for example, as 731 shown in Figure 3 (b), it for NSLP 1 changed to 1-D-#2 from 732 1-D-#1, 734 - Optionally, check the mobility identifier, if any: for example, 735 the Mobility object to know which message is sent due to the 736 latest handover (see Section 6.4). 738 The CRN discovery can be further divided into UCRN discovery and DCRN 739 discovery according to which node is a signaling initiator (by 740 upstream or downstream), or whether the MN is a data sender: 742 - If the MN is a data sender and when a mobility event occurs, the 743 MN begins to transmit signaling messages toward a CN in the 744 downstream direction. In this case, an NSLP-aware node recognizes 745 that the session paths logically converge, and then the NSLP-aware 746 node realizes it is the DCRN through the procedure above: the 747 procedure of CRN discovery is similar to the creation of the 748 routing table of node N except for the unchanged flow ID. 750 - When an MN (as a sender) undergoes handover, the UCRN can be 751 determined for upstream flow by the method above. In this case, 752 the UCRN should be the first node where the signaling flow begins 753 to logically diverge: it is similar to the creation of the routing 754 table of node A except for the unchanged flow ID. Since the UCRN 755 is determined by whether outgoing path diverges or not, the UCRN 756 discovery is more complex than the DCRN discovery. 758 4.3 Path update 760 The CRN discovery is different according to the direction of 761 signaling flow in mobility scenarios, and the DCRN operates 762 independently of the UCRN although DCRN and UCRN can be 763 simultaneously ferreted in bi-directional state establishment. 764 Therefore, the procedures for path update may differ according to the 765 direction of signaling flows as defined in terminology section: the 766 upstream Path Update and the downstream Path Update. In this case, 767 each signaling initiator has to be authorized for secure signaling. 769 For both types of path update, NSIS protocol needs to interact with 770 various mobility signaling protocols, if any (during or posterior 771 handover) to obtain performance gains through fast re-establishment 772 of the NSIS states along the new path. In this case, NSIS also needs 773 to monitor the movement of a mobile node through several methods 774 [4].In this section, we assume that an MN is a data sender.In this 775 section, we assume that an MN is a data sender. 777 4.3.1 State setup and update 779 Before initiating the Path Update, an MN or a CN needs to have its 780 session ownership by the procedure of authentication and 781 authorization and to check the availability of resources on the new 782 path. If the resources along the new path run short of, it needs to 783 keep state previously established for the flows while blocking new 784 requests. In this case, NSIS signaling for the Path Update also 785 needs to have an appropriate priority over local requests for the 786 resources. 788 In the downstream path update, if resource availability is assured, 789 the MN initiates the NSIS signaling for state setup toward a CN along 790 the new path, and the DCRN discovery is implicitly done by this type 791 of signaling initiated by the MN. In this case, the node where the 792 old and new logical session paths converge realizes that it is the 793 DCRN, and afterward the DCRN sends a response message toward the MN 794 to notify of NSLP state installed (e.g., in QoS-NSLP) or installs the 795 NSLP states as responding the NSLP signaling initiated by the MN 796 (e.g., as in RSVP). In this case, the sender-initiated approach 797 (e.g., QoS-NSLP) leads to faster setup than the receiver-initiated 798 approach as RSVP as shown in Figure 4 below. And then, the DCRN 799 sends a refresh message toward the signaling destination to update 800 the changed MRI on the common path and also sends a teardown message 801 toward the old AR to delete the NSIS states along the obsolete path 802 (if possible). 804 NI (MN) NF NF NR (CN) 805 | | | | 806 | RESERVE | | | 807 +--------->| RESERVE | | 808 | +--------->| RESERVE | 809 | | +--------->| 810 | | | | 811 | | | RESPONSE | 812 | | RESPONSE |<---------+ 813 | RESPONSE |<---------+ | 814 |<---------+ | | 815 | | | | 816 | | | | 818 (a) Sender Initiated Reservation 820 NI (MN) NF NF NR (CN) 821 | | | | 822 | QUERY | | | 823 +--------->| QUERY | | 824 | +--------->| QUERY | 825 | | +--------->| 826 | | | | 827 | | | RESERVE | 828 | | RESERVE |<---------+ 829 | RESERVE |<---------+ | 830 |<---------+ | | 831 | | | | 832 | RESPONSE | | | 833 +--------->| RESPONSE | | 834 | +--------->| RESPONSE | 835 | | +--------->| 836 | | | | 838 b) Receiver Initiated Reservation 840 Figure.4 Sender- vs. Receiver-intiated reservation 842 In the case of upstream path update, the CN (or a HA/ a GFA/MAP) 843 sends a refresh message toward the MN to perform path update. UCRN 844 is discovered implicitly by the CN-initiated signaling along the 845 common path, and the node from which the common path begins to 846 diverge into the old and new logical session paths realizes that it 847 is the UCRN. In this case, the CN should be informed of the movement 848 event using an NSIS signaling message sent by the MN or monitoring 849 the mobility signaling after detecting a change in its binding entry 850 (see Section 6.1). After the UCRN is determined as described in 851 Section 4.2.3, it may send a refresh message to the MN along the new 852 path while establishing the NSIS association between the updated 853 peers, and afterward the UCRN may send a teardown message toward the 854 old AR to delete the NSIS state on the obsolete path (if possible). 856 The state update in control plane on the common path to reflect the 857 changed MRI brings issues on the end-to-end signaling addressed in 858 Section 3.1. Although the state update does not give rise to 859 re-process AAA and admission control, it may lead to the signaling 860 overhead and latency. 862 One of the goals of path update is to avoid double reservations (in 863 case of QoS signaling) on the common path described in Section 3.1. 864 The double reservation occurred along the common path may be solved 865 by establishing a signaling association using the unique session 866 identifier and by the update of packet classifier/flow identifier. 867 In this case, the NSLP state can be shared for flows with different 868 flow identifiers. 870 4.3.2 State Teardown 872 After re-establishment of the NSIS state along the new path, the 873 state on the obsolete path need to be quickly removed by path update 874 mechanism to prevent the waste of resources due to double reservation 875 (and resource allocation problem by call blocking) and to reduce the 876 cost of using the resources in the access network as described in 877 Section 3.1. Although the release of the existing state on the old 878 path can be accomplished by timeout of soft state, the refresh timer 879 value may be quite long and the maintenance of the NSIS state on the 880 obsolete path may not be necessary. Therefore, the transmission of a 881 teardown message is particularly preferred to the use of refresh 882 timer to quickly delete the old state. Note that, however, it is not 883 necessary for the GIMPS to be explicitly removed because of the 884 inexpensiveness of the state maintenance. 886 The CRN is an appropriate point to initiate the teardown toward the 887 old AR after re-establishment of the state along the new path. In 888 this case, the release of old state on the obsolete path can be 889 accomplished by comparing the NSLP branch ID and through reverse 890 routing using SII. This can prevent the teardown message from being 891 forwarding toward along the common path. However, whether the 892 teardown message can be sent toward the opposite direction to the 893 state initiating node is still an open question. This also leads to 894 authorization problem because a node which does not initiate 895 signaling for establishing the NSIS state can delete the state. 897 The immediate removal of state along the old path may not be 898 appropriate for some mobility situations. For instance, in the fast 899 handover of a ping-pong type where an MN may return to the previous 900 AR after staying at a new AR for a short while, it causes signaling 901 overhead and when to delete the state along the obsolete path remains 902 still an open issue and needs to be discussed further in the later 903 version of this draft. Another example is the last node detection 904 problem. If the old AR is the last node due to handover, its NSLP 905 may trigger an error message to indicate that NSLP messages cannot be 906 forwarded any further. This error message may cause the removal of 907 the old states. However, although the error message is initiated, 908 the state on the old path should not be deleted before 909 re-establishing the state along the new path (make-before-break 910 handover). The more details are discussed further in Section 6.5. 912 5. Mobility-Related Issues with NSIS Protocols 914 5.1 Specific Issues with NTLP 916 The NTLP protocol maintains a per-flow message routing state and a 917 per-peer messaging association state. The former is installed and 918 maintained by a peer discovery mechanism, while the latter is set up 919 by the normal procedures of transport (and security protocols, when 920 secure channel for C-message transport is desired) that comprise the 921 messaging association. 923 NTLP is responsible for detecting route change, updating its own 924 routing state consistently, and informing NSLPs at affected nodes. 925 In mobility environments, for an end-to-end signaling flow, its 926 signaling path can be changed upon a successful MIP registration. 927 This means a new peer discovery procedure needs to be triggered 928 (e.g., through certain routing interface) and a new NTLP message 929 routing state must be adapted. 931 NTLP provides 5 mechanisms to detect a route change. In uplink 932 signaling case in mobility environments an MN can use the first 933 approach, local trigger, to determine next hop has changed and 934 initiate a new peer discovery until downstream CRN is found. In 935 downlink signaling case mobility environments, most detection 936 mechanisms at CN, HA or other mobility agents (if they support NSIS 937 at all) can only determine a route has "changed", i.e., a binding 938 cache changed. However, these entities do not necessitate an actual 939 NTLP or NSLP CRN, and the latter is the actual node of NSIS interests 940 and needs to be detected. This is an issue related to an NTLP 941 implementation's scale of re-discovery. 943 After detecting a route change has occurred, in addition to updating 944 the message routing state, an NTLP implementation at the downstream 945 CRN needs to notify local NSLP(s) to initiate their own state local 946 repairs. Messaging association state can be ignored as it is 947 per-peer meaningful and not very expensive. 949 NTLP works with general IP tunneling by applying the same 950 encapsulation to NSIS messages as data packets. Most mobility 951 protocols involve IP-in-IP encapsulation in part of the signaling 952 path. As this becomes effective dynamically after a mobility 953 registration, an NTLP implementation should gain the knowledge about 954 the introduction or change of encapsulation methods in the responding 955 node, if NSLPs want to be signaled into these tunnels. Moreover, 956 IP-in-IP encapsulation is simultaneously coupled with route change, 957 thus an NTLP implementation needs to interact with mobility 958 registration carefully. 960 5.2 Specific Issues with QoS-NSLP 962 The QoS-NSLP protocol establishes and maintains QoS-related state at 963 NSIS aware nodes along the path of data flow to support some 964 forwarding resources required for that flow. In mobility scenarios, 965 as mentioned in Section 4, the QoS-NSLP protocol needs to immediately 966 perform the procedure of the Path Update after an appropriate CRN is 967 discovered to continue to support QoS-related state for that session. 968 In this case, the following basic issues rise when considering 969 interaction with GIMPS layer as well as mobility protocols: 971 - When/how is QoS-NSLP signaling initiated after mobility? For 972 instance, if an MN is a sender and the sender-initiated 973 reservation approach is used, when does the MN send RESERVE 974 message forward CN to do the Path Update (and CRN discovery if 975 coupled approach is used)? In the receiver-initiated reservation, 976 when is Query message sent to a corresponding receiver or node 977 initiating reservation? In this case, QoS-NSLP should know or 978 detect the MN��s movement, e.g., through the SII notified over API 979 between GIMPS and QoS-NSLP (see Sections 5.4 and 6.1). 981 - How/when does an MN know/find out what resources are available 982 before a reservation is made after handover? And If QoS-resources 983 in a new access network are oversubscribed, how is the reservation 984 for required resources made? The QoS-NSLP of MN may be able to 985 know the availability of resources at the new access network using 986 Query message. In this case, the Query message needs to have a 987 priority rather than any other signaling: priority signaling for 988 call setup. If an MN moves an access network which does not have 989 a sufficient resources available, the MN may fail to reserve the 990 resources and it tries to keep the previous state by its mulihomed 991 interfaces. In such an oversubscribed scenario, certain signaling 992 message required for reservation may also be prioritized, but how 993 those signaling messages are dealt with priority is still open and 994 so needs to be discussed further in the later version of this 995 draft. 997 - Which layer should the (NSLP) CRN discovery be performed at, GIMPS 998 or QoS-NSLP? Although a QoS-NSLP can detect the change of 999 signaling path and discover the CRN by keeping track of SII, The 1000 CRN discovery may be preferred at the GIMPS layer to at the 1001 QoS-NSLP. As mentioned Section 4, since GIMPS detects the CRN as 1002 an extension of peer discovery, it does not add processing 1003 overhead. 1005 - How/by who can RESPONSE message be sent to the corresponding QNI 1006 if QNR (e.g., an MN) of the RESPONSE message performs handover 1007 before the receipt of the message? If RESERVE (for refresh) 1008 including Response request is sent to the MN from a node but the 1009 MN begins to handover the OAR in behalf of the MN may be a proxy 1010 to initiate RESPONSE message. In this case, the MN may notify OAR 1011 of the handover or error conditions 1012 (the-last-node-is-not-detected) using NOTIFY message. This 1013 ��invalid-NR�� problem is discussed further in Section 6.5. 1015 - How is refresh time set up in the situation of frequent handover? 1016 The QoS-NSLP uses peer-to-peer refreshing approach to allow QNEs 1017 to choose appropriate refresh intervals according to their network 1018 environments (e.g., an access network, or a core network). In 1019 mobility environments, refresh time intervals-related issues are 1020 discussed in Section 6.3 1022 - How does CRN immediately remove the state along the old path after 1023 the establishment of state along a new path? The CRN can delete 1024 the state along the old path by keeping track of SII or using 1025 Request Identification Information (RII). Since the SII object is 1026 similar in nature to the RSVP HOP object [5], RESERVE message set 1027 with TEAR flag can be forwarded to the direction of reverse path. 1028 In route change, the RII contained RESPONSE_REQUEST object (if 1029 any) allows the CRN to correctly send back the RESERVE message 1030 with TEAR flag to an appropriate (scoped) node. Note that as 1031 mentioned in Section 5.1, NTLP state along the old path does not 1032 need to be explicitly deleted before the expiration of the refresh 1033 time interval because of inexpensive of NTLP state. 1035 Some issues according to performance gain, bi-directional 1036 reservation, aggregation reservation and various handover scenarios 1037 are discussed further in Section 6: for example, refresh reduction, 1038 session binding, layering, peer agreement, and so on. 1040 5.3 Specific Issues with NAT/FW NSLP 1042 The NAT/Firewall NSLP [6] establishes and maintains firewall pinholes 1043 and NAT bindings at NAT/FW NSLP nodes along the data path. With 1044 regard to mobility a few issues need to be considered: 1046 In case of an IP address change firewall rules and/or NAT bindings 1047 become invalid which effectively prevents the end host from 1048 sending or receiving data packets. For example, without updating 1049 the firewall pinhole by a NSIS aware data sender who is located 1050 behind a firewall data packets with a new source IP address are 1051 most likely dropped at the firewall. If a data receiver , who is 1052 located behind a NAT, changes its IP address then incoming packets 1053 are rewritten at the NAT and forwarded to the wrong IP address. 1054 The QoS NSLPs might 'only' temporarily experience a weaker quality 1055 of service if the installed flow identifier is not uptodate. 1057 Although NSIS applies the soft-state principle and allocated state 1058 times out without refresh messages, it is possible that mobility 1059 leaves state (such as firewall pinholes) in place for some time. 1060 Since the NAT/Firewall NSLP aims to install pinholes (and NAT 1061 bindings) it is possible to re-use this installed state once a 1062 mobile node roams to a new location. Deleting state along the old 1063 path helps to limit this problem. However, this problem exists 1064 anyway as identified in [7] due to the capability of IP spoofing 1065 since the main problem is the usage of non-cryptographically based 1066 IP address filters. Hence, the NAT/Firewall NSLP is (in a 1067 mobility environment) not in the same fashion concerned about 1068 deletion of state along the old path. 1070 There also seem to be some differences between the security 1071 functionality required by the QoS NSLP and the NAT/Firewall NSLP 1072 (as analysed in [7], in [6] and in [8]. The security solution for 1073 the NAT/Firewall NSLP needs to reflect mobility specific security 1074 issues. This also has an impact on refresh handling (i.e., 1075 peer-to-peer vs. end-to-end), authorization issues, the usage of 1076 the session identifier and end-to-end security (with regard to 1077 the binding between NSIS and the application layer signaling). 1079 5.4 Common issues related to NTLP and NSLP 1081 In mobile environments, mobility related information for path update 1082 can be exchanged through the API specified in [NTLP]. For example, 1083 when a route change due to mobility occurs, SII-Handle can be 1084 provided from GIMPS to an NSLP in order to inform of the route 1085 change. The SII-Handle is a handle to a data structure, identifying 1086 peer addresses and interfaces. It can be used to identify route 1087 changes and for explicit routing to a particular GIMPS next hop. 1088 Based on the information, the involved NSLP can initiate path update 1089 by sending necessary signaling messages through the API. The details 1090 on the API are an implementation issue. 1092 Message routing information (MRI) and Session ID are also shared by 1093 the GIMPS and NSLP through the API. Whenever there is any route 1094 change due to mobility the MRI will be updated although the Session 1095 ID will not change. The MRI should be consistent with the SII-Handle 1096 described above. 1098 6. Applicability Statement 1100 6.1 Support for Macro Mobility-based scenarios 1102 This section considers how should NSIS protocols interact with the 1103 basic macro mobility protocols such as Mobile IPv4 and Mobile IPv6, 1104 and other global mobility approaches will be discussed further in the 1105 next version of this draft. 1107 The NSIS signaling needs to consider the following scenarios related 1108 to basic Mobile IP to interact with it. 1110 (1) A flow associated with an MN, either sent or received by the MN, 1111 may desire to be continuely served signaling services after a 1112 mobile IP handover. In this case, NSIS needs to be able to signal 1113 for such flows upon an MN's movements to seamlessly provide the 1114 correspondin service to one (e.g., QoS). The signaling procedure 1115 results in creating a new NSIS branch along the new path through 1116 an appropriate CRN discovery and a Path Update. 1118 (2) Either the sender or the receiver of an MN's flow can initialize 1119 an NSIS signaling, and it is essential to require the NSIS 1120 signaling initiator to be authorized to initialize the signaling. 1121 Note that nodes within the network may also initiate NSIS 1122 signaling for the given session, for example, to handle route 1123 changes caused by Mobile IP routing in the middle of the network, 1124 or to support seamless handovers. 1126 (3) Data traffic, in either direction between an MN and a CN, can be 1127 routed directly using a routing header, or indirectly by IP-in-IP 1128 encapsulation (or the combination of them) in different segments 1129 of the data transmission depending on the mobility mode (either 1130 route optimization or triangle routing is used; whether reverse 1131 tunneling is used; either mobile IPv4 or IPv6 is used; whether LMM 1132 is used, etc.). In this case, NSIS signaling needs to immediately 1133 be initiated by using a mobility routing interface (e.g., mobility 1134 API) between the NSIS protocols and the Mobile IP according to the 1135 method of each routing. 1137 (4) An MN's handover can be either intra-domain (within an access 1138 network domain) or inter-domain (from an access network domain to 1139 another), which mainly concerns with topology information 1140 exchange, authorization and accounting issues. The interworking 1141 with NSIS signaling and some mobility management protocols (i.e., 1142 HMIP, FMIP, etc) in various handover scenarios may give rise to 1143 some performance gains (see Section 6.3). 1145 (5) In mobile IPv6, an MN can support multiple care-of-addresses at 1146 one time, if it is connected to multiple access networks 1147 simultaneously (or even if it is connected to one access network). 1148 Although only one primary care-of-address will be used for routing 1149 traffic from the CN to the MN, this multi-homing feature 1150 potentially can be used to enhance the NSIS signaling performance 1151 (see Section 6.2). The inter-domain handover, for instance, may 1152 require additional latency to perform the NSIS signaling procedure 1153 including authentication and authorization rather than the 1154 intra-domain handover, but the latency penalty of NSIS signaling 1155 can be mitigated if the MN is multi-homed. 1157 6.1.1 Implications to Mobile IP-related scenarios 1159 As NSIS is path-coupled signaling, one imposed requirement here is 1160 that the NSIS protocols are to be typically associated with a route 1161 changes for route optimization between the CN & the MN and an 1162 IP-in-IP encapsulation from the HA to the MN as well as mobility, and 1163 those interaction also needs to be notified to all NSLPs by the API 1164 between GIMPS and NSLP for the CRN discovery and the Path Update as 1165 described in Section 4. Therefore, NTLP or NSLP needs to have an 1166 interface with the Mobile IP to immediately react to the mobility 1167 event. In other words, NSIS implementation needs to be designed to 1168 react based on the endpoint notification of which behaviour of Mobile 1169 IP has taken place and probably, when the timer of Mobile IP 1170 refreshes (to keep corresponding NSLPs reacting to it). 1172 An ideal interface between NSIS signaling and the Mobile IP should 1173 make that NSIS signaling is able to react to the mobility event as 1174 soon as possible whenever Mobile IP changes its characteristics in 1175 any place for the flows, In general, it is appropriate that NTLP is 1176 involved in the interaction with the Mobile IP rahter than NSLP, 1177 because NTLP is responsible for detecting the mobility and routing 1178 NSIS messages. Therefore, it is reasonable to assume NTLP should be 1179 able to notify NSLP of the update of state when mobiity is detected. 1180 Here also are some issues which rise when the API between the NSIS 1181 and the Mobile IP is considered. 1183 - Which information does the NTLP detect the movement based on? 1184 After an MN arrives at a new network attachment point, current 1185 reachability information is transferred from the MN to its HA as 1186 the last procedure of handover. It indicates that NTLP may need 1187 to interact with the start/completion of a binding process (e.g., 1188 registration request in Mobile IPv4 and Binding Update in Mobile 1189 IPv6) to detect the IP address change and refer to the tunnel 1190 information of Mobile IP. Therefore, provided the NTLP detects 1191 the mobility using the information of binding process, faster 1192 state establishment and removal can be performed. However, in the 1193 fast or ping-pong handover, it may result in considerable 1194 signaling overhead and some possible errors. 1196 - How and what information can the NSLP expect from NTLP, or 1197 directly from the routing interface after mobility? 1199 - How to coordinate the mobility binding update interval and NSIS 1200 signaling interval? Since the Binding Update or the Registration 1201 request message occur periodically even for the MN with the same 1202 point of attachment, the movement detection based on the binding 1203 process sometimes causes the NTLP/NSLP to inappropriately initiate 1204 the CRN discovery and the Path Update. Although the issue is 1205 closely related to implementation, it needs to be considered to 1206 have the performance gain of NSIS signaling. 1208 An overall coordination/synchronization about the interworking with 1209 the NSIS and the Mobile IP is still open and needs to be discussed 1210 further. 1212 6.1.1.1 Mobile IPv4-specific issues 1214 The data flows of Mobile IPv4 are forwarded based on the triangular 1215 routing (even if route optimization is considered an extended 1216 option), and an MN retains a new CoA from the FA (or the external 1217 method such as DHCP) in the corresponding access network unlike the 1218 Mobile IPv6 whenever the MN arrives at the new network attachment 1219 point (e.g., a FA or a foreign link)[9]. When the MN is a sender, 1220 the downstream data flows from the MN are directly transferred to the 1221 CN not necessarily through the HA or indirectly through the HA using 1222 the reverse routing. On the other hand, upstream data flows from the 1223 CN are routed through the IP tunneling between the HA and the FA (or 1224 the HA and the MN in the case of the Co-located CoA). In this case 1225 of such a routing which is dependent on the HA, it represents that 1226 the NSIS signaling needs to interact with the IP tunneling of Mobile 1227 IP to provide an appropriate signaling service for that flow. 1229 The following figures 5 (a)-(e) show the NSIS signaling flows 1230 required according to the direction of data flows and the routing 1231 methods . 1233 MN FA (or FL) CN 1234 | | | 1235 | IPv4-based Standard IP routing | 1236 |------------ |------------------------------>| 1237 | | | 1239 (a) MIPv4: MN-->CN, no reverse tunnel 1240 MN FA HA CN 1241 | IPv4 (normal) | | | 1242 |--------------->| IPv4(tunnel) | | 1243 | |--------------->| IPv4 (normal) | 1244 | | |-------------->| 1246 (b) MIPv4: MN-->CN, the reverse tunnel with FA Care-of-Address 1248 MN (FL) HA CN 1249 | | | | 1250 | IPv4(tunnel) | | 1251 |------------------------------->|IPv4 (normal) | 1252 | | |-------------->| 1254 (c) MIPv4: MN-->CN, the reverse tunnel with Co-located 1255 Care-of-address 1257 CN HA FA MN 1258 |IPv4 (normal) | | | 1259 |-------------->| | | 1260 | | MIPv4 (tunnel) | | 1261 | |---------------->| IPv4 (normal)| 1262 | | |------------->| 1264 (d) MIPv4: CN-->MN, Foreign agent Care-of-address 1266 CN HA (FL) MN 1267 |IPv4(normal ) | | | 1268 |-------------->| | | 1269 | | MIPv4 (tunnel) | | 1270 | |------------------------------->| 1271 | | | | 1273 (e) MIPv4: CN-->MN with Co-located Care-of-address 1275 Figure 5. Implications for signaling under different Mobile IPv4 1276 scenarios 1278 When an MN (as a sender) arrives at a new FA and the corresponding 1279 binding process for the FA CoA is completed: 1281 - For downstream signaling flow, the MN needs to perform the CRN 1282 discovery (DCRN) and the (downstream) Path Update toward the CN as 1283 described in Section 4 to establish the NSIS state along the new 1284 path between the MN and the CN as shown in Figure 6 (a). If the 1285 reverse tunnel is used and the state along the tunneling path does 1286 not exist, the NSIS state may be established along the tunneling 1287 path from the FA to the HA as shown in Figure 6 (b). In this 1288 case, the DCRN may be discovered on the tunneling path and the new 1289 flow identifier for the tunneling state update may need to be 1290 created. 1292 - For upstream signaling flow, the CN may initiate the NSIS 1293 signaling to update the existing state between the CN and the HA, 1294 and then NSIS signaling may need to interact with IP tunneling to 1295 also update the state along the tunneling segment from the HA to 1296 the FA as shown in Figure 6 (d). In this case, the UCRN may be 1297 discovered somewhere on the tunneling path, and the new flow 1298 identifier for the tunneling state update may be created. 1300 When the MN (as a sender) arrives at a new foreign link and the 1301 corresponding binding process for the co-located CoA is completed: 1303 - For downstream signaling flow, the NSIS signaling for the DCRN 1304 discovery and the Path Update is equal to the case for FA CoA 1305 above (as shown in Figure (a)) except that in case of using the 1306 reverse tunnel, the NSIS state may be established along the 1307 tunneling path from the MN to the HA as shown in Figure 6 (C). 1309 - For upstream signaling flow, the CN may initiate the NSIS 1310 signaling to update the existing state between the CN and the HA 1311 and then NSIS signaling may need to interact with IP tunneling to 1312 also update the state along the tunneling segment from the HA to 1313 the MN as shown in Figure 6 (e). In this case, the UCRN may 1314 eventually be discovered somewhere on the tunneling path, and the 1315 new flow identifier for the tunneling state update may also be 1316 created. 1318 Note that in the case of interaction with IP tunneling, DCRN and UCRN 1319 may be identified at the same node on the tunneling path. For 1320 example, NSIS CRN may usually be the HA if the HA and the FA are 1321 NSIS-aware and the NSIS state along the tunneling path is not 1322 established. Therefore, the CRN discovery may be affected according 1323 to the interaction with NSIS signaling and IP tunneling, and the FA 1324 and the HA should be NSIS-aware to do the Path Update along the 1325 appropriate path. However, the effect that the IP tunneling has on 1326 the CRN discovery and the Path Update needs to be discussed further. 1328 6.1.1.2 Mobile IPv6-specific issues 1330 The Mobile IPv6 case differs from Mobile IPv4 in that an FA is not 1331 required in the data path and the Route Optimization process between 1332 the MN and CN is basically used to avoid the triangular routing in 1333 the Mobile IPv4 scenarios as shown in Figure 6 [10]. Therefore, if 1334 the use of route optimization is not mandatory, data flow routing and 1335 NSIS signaling procedure (including the CRN discovery and the Path 1336 Update) of Mobile IPv6 would be similar to that of the Mobile IPv4 1337 described in Section 6.1.2.1. 1339 When an MN (as a sender) arrives at a new AR and the binding process 1340 is successfully completed, for downstream signaling flow, the MN may 1341 initiate NSIS signaling for DCRN discovery and the (downstream) Path 1342 Update to establish the state along the new path between the MN and 1343 the CN or the tunneling path from the MN to the HA if the reverse 1344 tunnel is used, as shown in Figure 6 (a) & (b), repectively. for 1345 upstream signaling flow, the CN may also update the state along the 1346 common path toward the HA through the Path Update and afterward the 1347 NSIS state along the tunneling segment from the HA to the MN may be 1348 updated by interaction with IP tunneling as shown in Figure 6 (d). 1349 However, if the route optimization is performed successfully between 1350 the CN and the MN, for upstream flow, CN needs to newly initiate NSIS 1351 signaling to discover an appropriate UCRN and do the Path Update 1352 along a new path between the CN and the MN as shown in Figure 6 (c): 1353 bidirectional state establishment may be required. In this case, the 1354 obsolete path of the existing tunneling segments needs to 1355 appropriately be removed after re-establishment of NSIS state along 1356 the optimized path. However, when to remove the tunneling segment 1357 and/or how to tear it down through the interworking with the 1358 IP-tunneling is still an open issue. 1360 Although the routing of Mobile IPv4 with the co-located CoA is 1361 similar to that of Mobile IPv6 as shown in Figure 5 (a), (c) and (e), 1362 one of the differences between the Mobile IPv6 and the Mobile IPv4 is 1363 the method to acquire the CoA. That is, the Mobile IPv6 can usually 1364 acquire the CoA from the corresponding access router or external 1365 method through the stateless autoconfiguration or the stateful 1366 autoconfiguration (e.g., DHCPv6), respectively , and the Mobile IPv4 1367 obtains the co-located CoA using an external method such as DHCP. 1368 This difference may have some effects on the creation of flow 1369 identifier and make NSIS signaling performed differently according to 1370 Mobile IP mode. However, it is still open and needs to be discussed 1371 further in the later version of this draft. 1373 MN CN 1374 | | 1375 |IPv6+HomeAdressOpt | 1376 |--------------------------------------------->| 1377 | | 1379 (a) MIPv6: MN-->CN, no reverse tunnel 1380 MN HA CN 1381 |IPv6(tunnel) | | 1382 |------------->| IPv6(normal) | 1383 | |------------------------------>| 1384 | | | 1386 (b) MIPv6: MN-->CN, with reverse tunnel 1388 CN MN 1389 | | 1390 | MIPv6(RH Type 2) | 1391 |--------------------------------------------->| 1392 | | 1394 (c) MIPv6: CN-->MN, route optimization 1396 CN HA MN 1397 |IPv6(normal) | | 1398 |------------->| | 1399 | | MIPv6(tunnel) | 1400 | |------------------------------>| 1401 | | | 1403 (d) MIPv6: CN-->MN, no route optimization 1405 Figure 6. Implications for signaling under different Mobile IPv6 1406 scenarios 1408 6.2 Multihoming/make-before-break scenarios 1410 6.2.1 Overview 1412 A host that is an initiator or responder of signaling messages may be 1413 either multi-homed or mobile in some cases. Especially, when current 1414 activities in the multi6 WG are considered, multi-homed hosts and 1415 scenarios may be very common in a future IPv6 Internet. Such 1416 scenarios may also include load balancing techniques, i.e., when 1417 multiple connections to different providers are used simultaneously. 1418 Therefore, multi-homed hosts may use different paths that converge at 1419 some CRN. If load balancing is active, the paths are used at the 1420 same time, but if multi-homing is used for resilience only, the 1421 active path changes during fail-over. 1423 For mobile hosts flow paths are changed when the point of network 1424 attachment is changed. This may also require a change of state in 1425 network elements along the old and new paths.The term "seamless 1426 mobility" is often referred to mean that the MN is able to keep an 1427 ongoing session seamlessly (without experiencing perceivable service 1428 interruption or performance penalty) during and after moving from one 1429 access network to another. Measures to achieve seamless mobility 1430 include soft handover and anticipated handover [QoSSig4G]. The 1431 former requires the MN to keep the old path, while data is received 1432 over the new path. This approach is only possible if the MN is 1433 multi-homed. Appendix B discusses fast state installation by using 1434 anticipated handovers, in which the MN signals the new path while 1435 still connected to the old one. 1437 6.2.2 NTLP/NSLP support 1439 NTLP uses endpoint address to install message routing state, thus the 1440 new address for an MN introduced in MIP has to invoke a change of 1441 message routing state. In multihomed MN scenarios, both new address 1442 and old address can be valid during a certain period of time, the new 1443 data path may co-exist with the old one. It is theoretically 1444 possible to perform certain NSIS state update in the new path during 1445 this period, however the signaling ends need to be careful, so that 1446 the correct routing information will be delivered for setting up new 1447 or updating existing message routing state in the correct path 1448 segment. Furthermore, performing such actions should not cause NSLP 1449 service interruption, protocol misbehaviors or security holes and 1450 thus should be discouraged. 1452 6.3 QoS Performance Considerations in mobility scenarios 1454 The routing characteristics of mobile IP system described in Section 1455 6.1 cause the session path to be changed and in this case the exiting 1456 protocols which do not support signaling in dynamic environment where 1457 route change or mobility event occurs can cause the problems 1458 addressed in Section 3.1. Particularly, in mobile/wireless 1459 environments, QoS parameters such as resource utilization and 1460 signaling latency need to be considered so that how NSIS protocols 1461 should interact with mobility protocols is correctly evaluated. In 1462 the perspective of resource utilization, the double reservation 1463 problem leading to the waste of resource and call blocking is 1464 generally known in handover scenarios and it may be alleviated by the 1465 procedure of the CRN discovery and the Path Update described in 1466 Section 4. In this section, we take into consideration on how the 1467 resource utilization of the NSIS signaling flow itself can be 1468 managed: The adjustment of refresh time interval and refresh 1469 reduction. 1471 The NSIS protocol suite normally use a soft-state approach based on 1472 the peer-to-peer refreshing to manage state in NEs. At the GIMPS 1473 layer, the state is maintained through the exchange of GIMPS query/ 1474 response messages between adjacent peers [2]. In this case, the peer 1475 relationship is maintained using a timer which implies how long the 1476 association between the peers can be considered valid. That is, if 1477 it has not been refreshed until the timer expires (e.g., after 30 1478 seconds as a default value), the peer relationship is removed. The 1479 management of state (i.e., routing state and messaging association) 1480 can be controlled in this way. In case of QoS-NSLP, states are also 1481 set up and then maintained for the reservation of desired resources 1482 using the peer-to-peer refresh messages. The peer-to-peer based 1483 refreshment allows the QoS-NSLP to appropriately select the refresh 1484 time by considering the current network environment. For example, it 1485 may set the refresh timer value in the mobile/wireless (access) 1486 network to a smaller value than that in the core (wired) network by 1487 the method described in [11]. In the situation of frequent handover, 1488 the adjustment of the refresh time results in minimizing the waste of 1489 resources. Note that, however, unlike the QoS-NSLP, the refresh time 1490 of NTLP state doesn't need to be adjusted according to the type of 1491 the network from the perspective of resource utilization. 1492 Furthermore, NTLP state along the obsolete path does not also need to 1493 be explicitly removed before the expiration of refresh timer. 1495 In mobile and wireless networks, the QoS-NSLP (rather than the NTLP) 1496 is able to set the refresh timer value depending on the handover type 1497 (e.g., make-before-break or break-before-make handovers ) or the 1498 reservation style (e.g., pre-establishment or re-establishment) to 1499 optimize the resources utilization. For example, in the 1500 make-before-break handover, appropriate refresh time intervals are 1501 able to be notified using the reserved field of REFRESH object, and 1502 if the refresh time value is set to a little higher value than the 1503 estimated handover latency, the MN can be provided with seamless QoS 1504 service using the pre-reserved resources, and the resources which are 1505 pre-reserved but unused will be timely released after handover [12]. 1507 After the state along a new path established, QNEs along the 1508 signaling path may send refresh message to the neighboring peer node 1509 before the expiration of refresh timer to only update the state 1510 previously installed along the path or the changed flow ID along the 1511 common path after the CRN discovery. In this case, the overhead 1512 required to perform refreshes can be reduced, in similar way to that 1513 proposed for RSVP [Refresh Reduction]: Refresh Reduction. Once a 1514 RESPONSE message has been received indicating the successful 1515 installation of a reservation, subsequent refreshing RESERVE messages 1516 can simply refer to the existing reservation, rather than including 1517 the complete reservation specification. For example, only the 1518 Session_ID and the SII with no QSPEC at all are sent to just refresh 1519 the state (e.g., reservation) previously installed and additionally 1520 the changed flow ID with together those ID is only sent to update it 1521 along the common path. Especially, the use of reduced refresh 1522 messages over wireless channels or in access networks as well as in 1523 core networks results in having the advantage of efficient 1524 utilization of resources. 1526 As mentioned in Section 3.1, in the mobility scenarios unlike the 1527 route change, the end-to-end signaling problem according to the Path 1528 Update gives rise to the deterioration of network performance such as 1529 the signaling overhead, service blackout, and so on. To reduce 1530 signaling latency in the Mobile IP-based scenarios, the NSIS protocol 1531 suit needs to interwork with localized mobility management (LMM). If 1532 the GIMPS/QoS-NSLP protocols operate over Hierarchical Mobile IPv6 1533 and the CRN is discovered between an MN and MAP, the procedure of the 1534 Path Update can be localized. However, it needs to be discussed 1535 further how the Path Update is performed with scoped signaling 1536 messages within the access network under the MAP. 1538 In the inter-domain handover, additional latency occurs to perform 1539 the NSIS signaling procedure including authentication and 1540 authorization rather than that in the intra-domain handover. In this 1541 case, a possible scenario for mitigation of the latency penalty may 1542 be that the MN is multi-homed, or the NSIS protocols interact with 1543 mobility protocols such as Seamoby protocols (e.g., CARD and CTP) and 1544 FMIP. Another scenario is to use peering agreement which allows that 1545 for an aggregate reservation, aggregation authorization is performed 1546 once on an inter-domain link without the check of the authorization 1547 of each individual session. However, those issues are still open how 1548 those approaches can be used by the NSIS protocol suit. 1550 6.4 Use cases of Identifiers 1552 The current NTLP and QoS-NSLP drafts have defined important 1553 identifiers including Session Identifier (SID), flow identifier, 1554 signaling application identifier (NSLPID), Source Identification 1555 Information (SII), Reservation Sequence Number (RSN), and so on. 1556 These IDs are useful for different purposes in NSIS signaling. 1558 When an NSIS signaling message (e.g., RESERVE) with an existing SID 1559 and a different SII is received, an NE (e.g., QNE) knows its upstream 1560 peer has changed. In mobile environments, the SID and SII can be 1561 used to detect the CRN. For example, after the handover of an MN, if 1562 an NE (e.g., QNE) on the data path receives an NSLP message (e.g., 1563 RESERVE) with an SID for which it already has state installed but 1564 with a different SII, the QNE can determine that it is a merging 1565 point (i.e., an NSLP CRN) of the old and new paths, accordingly, 1566 involve state setup in the new path and teardown of the state on the 1567 old path. However, if an NE (e.g., QNE) receives an NSIS message 1568 (e.g., RESERVE) with a special flag (e.g., NO_REPLACE flag) set but 1569 with the different SII, teardown of the state on the old path should 1570 not happen. This may apply to a ping-pong type of handover where an 1571 MN wishes to keep state to its old attachment point in case it moves 1572 back there. 1574 It is also possible to discover the CRN using message the routing 1575 information (MRI) and SID at the GIMPS level. The MRI is used by 1576 GIMPS in determining the correct next GIMPS hop for the signaling 1577 message [2]. Whether the CRN is discovered by NTLP or NSLP is still 1578 an open question. If the CRN is discovered using the MRI, the SII 1579 may be redundant in terms of CRN discovery. In any case, the MRI 1580 should be consistent with the SII. 1582 The data flow will typically be classified by the flow identifier at 1583 NEs. The flow identifier may change due to mobility. In this case, 1584 it should be updated on the common path so that the data flow can get 1585 necessary treatment. 1587 The RSN may be useful in detecting duplicate messages in the mobile 1588 environment. For example, it is possible for the MN to move to the 1589 2nd NAR soon after being attached to the 1st NAR. In this case, an 1590 NSIS node may receive the RESERVE message twice. The problem arises 1591 without using RSN, when the RESERVE message from the 1st NAR arrives 1592 later than the RESERVE message from the 2nd NAR. 1594 Optionally, although a mobility object has not been defined in the 1595 NTLP/NSLP drafts, it may be used to inform of the handover of an MN 1596 or a route change [12] and therefore to expedite the CRN discovery. 1597 The mobility object may be defined in the NTLP (e.g., in GIMPS 1598 payload) or NSLP messages to notify of any mobility event explicitly, 1599 and it may contain various mobility-related fields, e.g., 1600 mobility_event_counter and handover_init fields. The 1601 mobility_event_counter field can be used to detect the latest 1602 handover event to avoid any confusion about where to send a 1603 confirmation message and to handle the ping-pong type of movement 1604 described in Section 6.7. The handover_init field can be used to 1605 explicitly inform that a handover is now initiated for fast state 1606 re-establishment and to handle the invalid NR problem described in 1607 Section 6.5. 1609 6.5 Peer Failure Scenarios 1611 A dead peer can occur either because a link or a network node, or 1612 because the MN moved away without informing NSLP/NTLP (it is 1613 recommended to link mobility- and NSIS signaling such that this does 1614 not happen). 1616 Dead peers of interest in mobility scenarios include CRN, MN, and AR. 1617 In general, it is possible that only NSIS functions (i.e., NTLP/NSLP) 1618 of the node may fail, or the physical hardware. 1620 An MN may either fail or move. When it fails, it becomes a dead 1621 peer. When it moves, it either retains or changes its IP address 1622 (e.g., CoA). If it moves and changes its IP address without 1623 notifying NSLP/NTLP, it also becomes a dead peer. 1625 The failure of a (potential) NSIS CRN may result in incomplete state 1626 re-establishment on the new path and incomplete teardown on the old 1627 path after handover. In this case, a new CRN should be discovered 1628 immediately by the CRN discovery procedure described above. 1630 The failure or movement of an MN may cause the 'invalid NR' problem 1631 [12] where the NR is the MN. If the MN moves, care should be taken 1632 to prevent the teardown of NSIS state on the old path before the NSIS 1633 state is re-established on the new path. In this case, an error 1634 message should not be generated/sent to avoid any teardown on the old 1635 path. It may be possible that the MN is not the NR, but a router in 1636 the access network (possibly the AR) is proxying for the MN instead. 1638 The failure of an AR may make the interactions with seamoby protocols 1639 (such as CARD and CT) impossible. In this case, the neighboring peer 1640 closest to the dead AR may need to interact with such protocols. 1642 In any case, dead peers should be discovered fast to minimize service 1643 interruption. The procedures for dead peer discovery (DPD) should be 1644 the same no matter why a peer is dead, because an NE discovering a 1645 dead peer cannot judge the specific reason. The procedures for DPD 1646 should be handled by the NTLP. In fact, the DPD can be considered as 1647 an extension to the GIMPS peer discovery. A peer discovery message 1648 can be periodically transmitted to the neighboring peer (e.g., 1649 responding node in [2]), and the responding node can send a response 1650 message. To determine if the peer is alive, the use of a timer may 1651 be helpful. For example, the response message may need to be 1652 received by the sender (e.g.,querying node in [2]) before the timer 1653 expires. Otherwise, the responding node can be considered dead. 1655 6.6 Guidelines for design of NTLP and NSLPs 1657 (XF) My interpretion is: in this whole doc we emphasis on the 1658 judging/stating whether/how current NTLP/NSLPs support mobility 1659 scenarios. If we keep 6.6 here, we should keep it rather short and 1660 avoid long description of new solutions. Or just a summary of which 1661 features are not supported in current protoocls (and need to be taken 1662 care) and general considerations for new NSLPs. 1664 7. Security Considerations 1666 This section describes authorization issues for mobility scenarios in 1667 NSIS. It tries to raise additional questions beyond those discussed 1668 in [13]. 1670 For the discussion of various authorization problems we assume that 1671 initial authorization is strongly coupled to authorization handling 1672 in subsequent message interactions. Making this assumption has some 1673 implication to the signaling message behavior. It is certainly 1674 possible that the entities who request the initial reservation or a 1675 firewall pinhole and those who subsequently cause modifications are 1676 not the same entities. 1678 NSIS NSLPs define a flexible authorization scheme. As argued in [14] 1679 it is necessary to consider cases where the sender, the receiver or 1680 both are authorizing a reservation. For NAT and Firewall signaling 1681 it is necessary that, the sender and the receiver, authorize the 1682 creation of a NAT binding and the creation of a firewall pinhole. 1684 Subsequently, we will consider the case where the mobile node acts as 1685 a data sender followed by a discussion of the CN as a data sender. 1687 7.1 MN as data sender 1689 This section refers to Figure 2 where the MN acts as a data sender 1690 which moves from one point of attachment to another. 1692 This description starts with an initial flow setup triggered by the 1693 MN which is also authorized by the MN. 1695 7.1.1 MN is authorizing entity 1697 This scenario considers the initial flow setup executed by the MN 1698 whereby the MN provides authorization for the initial flow setup. 1699 The initial setup might be used to create state for subsequent 1700 authorization actions by the MN. It is obvious that the 1701 authorization for the NSLP application (e.g., QoS NSLP) has to 1702 provided. Depending on the underlying authorization model it might 1703 be either peer-to-peer or end-to-middle. This authorization decision 1704 can possibly be treated independent of the authorization issues 1705 discussed in this section. 1707 MN CN 1709 ------>----->------>------>------>------>------> + 1710 ACTION (MN is authz) | 1711 | 1712 <-----<-----<------<------<------<------<------- | Flow 1713 ACK | Setup 1714 | 1715 | 1716 ===============================================> + 1717 Traffic 1719 Figure 7: MN authorized initial reservation 1721 The following questions seem to be interesting: 1723 - Should the MN indicate that it is the authorizing entity for 1724 subsequent actions to all entities along the path? 1726 - What information should be used for this purpose? 1728 - Who should add this information? Should the visited network of the 1729 MN add something to the signaling message during the initial flow 1730 setup? 1732 - How do other entities along the path learn this information? 1734 Next, the case for a mobile node authorizing the DCRN is considered. 1735 This communication is illustrated in Figure 8. 1737 The movement of the mobile node after the initial flow setup requires 1738 authorization. Various session ownership authorization issues are 1739 illustrated in [13]. 1741 MN DCRN CN 1743 + E.g. 1744 ------>----->------>------>------>------>------> | Movement 1745 ACTION | with state 1746 | creation at 1747 <-----<-----<------<------<------<------<------- + new path 1748 ACK 1750 Figure 8: MN authorizes DCRN 1752 The following questions are of interest: 1754 - Why should the DCRN execute something on behalf of the MN? (i.e., 1755 why should it trust the MN and what information can the DCRN use 1756 for verification?) As an example, the DCRN might delete state 1757 along the old segment. 1759 - Should the DCOR alone be able to start signaling (the DCOR might 1760 be a designed node in some mobility protocols (e.g., MAP)) since 1761 it is the node which has more information that other nodes based 1762 on the mobility signaling protocols? 1764 - How should other nodes between the MN and the DCRN and the nodes 1765 between the DCNR and the CN know that the DCRN is now acting on 1766 behalf of the MN? 1768 The case of a corresponding node triggering an action is discussed. 1769 shows the exchange graphically. 1771 In this scenario the CN wants to, for example, tear-down a 1772 reservation. 1774 MN DCNR CN 1776 <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 1777 TRIGGER | E.g. 1778 | Tear 1779 | Down 1780 ------>----->------>------>------>------>------> | 1781 ACTION | 1782 | 1783 <-----<-----<------<------<------<------<------- + 1784 ACK 1786 Figure 9: CN triggers action 1788 The following questions arise: 1790 - Why should the MN trust the trigger? 1792 - Is it possible to specify the security properties of the trigger 1793 message in more detail? Is this an NSIS signaling message? 1795 - The discussions about an indicator which entity to charge for the 1796 reservation might be relevant (see [14]). 1798 - Should the CN restrict the actions of the MN (e.g., delete, 1799 update, create)? On the shared segment it might, for example, be 1800 possible to restrict the allowed action to a flow identifier 1801 update. 1803 7.1.2 CN is authorizing entity 1805 This scenario is similar to the CN triggering in Section 7.1.1. Two 1806 slightly different protocol variations will be considered. 1807 Authorizing some actions in the reverse data flow direction is more 1808 difficult as it can easily be seen in Figure 10. 1810 7.1.2.1 CN asks MN to trigger action (on behalf of the CN) 1812 In Figure 10 the CN authorizes the MN to start signaling after, for 1813 example, a movement. After receiving the trigger message (and some 1814 authorization information) the mobile node starts signaling along the 1815 new segment and automatically discovers the DCRN. The message 1816 travels along the shared segment to the CN and updates the flow 1817 identifier (if necessary). The MN might additionally allow the DCRN 1818 to delete the reservation along the old segment. 1820 MN DCRN CN 1822 <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 1823 TRIGGER | 1824 | 1825 ------>----->------>------>------>------>------> | 1826 ACTION (CN is authz; MN on behalf of CN) | 1827 +-----------------+ +-----------------+ | 1828 | Action: | | Action: | | 1829 | 'create' along)| | 'update' along)| | 1830 | new segment) | | shared segment)| | Action 1831 +-----------------+ +-----------------+ | 1832 <------<------<------- | 1833 +-----------------+ | 1834 | Action: | | 1835 | 'delete' along)| | 1836 | old segment) | | 1837 +-----------------+ | 1838 <-----<-----<------<------<------<------<------- | 1839 ACK | 1840 | 1841 | 1842 ===============================================> | 1843 Traffic + 1845 Figure 10: CN asks MN to trigger an action (on behalf of the CN) 1847 The following questions need to be considered: 1849 - How should the "delegation" mechanism work such that intermediate 1850 nodes believe the MN that it is acting on behalf of the CN? 1852 - Is it possible to carry this information with the trigger message 1853 from the CN and the MN? 1855 7.1.2.2 CN uses installed state to route message backwards 1857 As a second variant the CN uses NSIS installed state to route a 1858 signaling message backwards along the path. In some rare cases the 1859 DCNR node might be known already. In this case it is possible to 1860 stop the update process along the shared segment and to possibly mark 1861 installed state along the old segment for deletion. When the MN 1862 receives the message it again has to install state along the new 1863 segment towards the DCOR. The mobile node might also trigger the 1864 deletion of resources along the old segment together with this state 1865 creation (pessimistic delete). An optimistic delete operation is 1866 certainly more error prone. 1868 MN DCNR CN 1870 [ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> ] + 1871 [ TRIGGER (e.g., MIP) ] | 1872 | 1873 ------<-----<------<------<------<------<------< | 1874 ACTION (CN is authz) | 1875 +--------------------+ +-----------------+ | 1876 | Action:optimistic | | Action: | | 1877 | 'delete' along | | 'update' along)| | 1878 | old segment) | | shared segment)| | 1879 +--------------------+ +-----------------+ | 1880 >------>------>----------->------>------>------- | 1881 +-----------------+ ACK | 1882 | Action: | | Action 1883 | 'create' along)| | 1884 | new segment) | | 1885 +-----------------+ | 1886 <------<------<------- | 1887 +-------------------+ | 1888 | Action:pessimistic| | 1889 | 'delete' along) | | 1890 | old segment) | | 1891 +-------------------+ | 1892 | 1893 ===============================================> | 1894 Traffic + 1896 Figure 11: CN uses installed state to route message backwards 1898 Figure 11 raises a few questions: 1900 The security properties of the trigger message need to be 1901 evaluated. 1903 It is not always possible to route signaling message backwards 1904 from the CN to the MN: 1906 - state at the new path might not be established (hence the 1907 signaling message cannot travel backwards) 1909 - the signaling message might not reach the MN via the old 1910 segment. 1912 In the multi-homing case where the mobile node can be reached via 1913 more than one path it is possible to execute this exchange. The 1914 same might be true for some local repair cases. 1916 The messages triggered by the MN (namely create state along the 1917 new segment and the pessimistic 'delete along the old segment) 1918 still need to be executed on behalf of the CN. Compared to the 1919 first variant there might be some room for optimization since the 1920 first message was transmitted by the CN. 1922 7.1.2.3 MN and CN are authorized 1924 If we argue that the authorization at the NSLP layer is somehow tight 1925 to the authorization for certain protocol actions then we also have 1926 to consider the case where the MN and the CN have to contribute to 1927 the authorization decision. This situation appears, for example, in 1928 the NAT/Firewall signaling case but also in the area of QoS 1929 reservation where both parties might need to share the cost of a 1930 reservation. 1932 If both end hosts are authorized then some signaling message 1933 exchanges are less difficult since the trigger message does not need 1934 to include authorization information. Some problems, however, do not 1935 disappear such as the session ownership problem and additional 1936 problems might be caused by certain solution approaches. Since this 1937 section does not discuss solutions the reader is referred to the [13] 1938 draft which lists a few strawman proposals for addressing the session 1939 ownership problem. 1941 7.1.3 CN as data sender 1943 In this section we consider the scenarios where the CN acts as a data 1944 sender. Figure 2 shows the topology and the participating entities. 1946 7.1.3.1 CN is authorizing entity 1947 This scenario is similar to the one described in Section 7.1.1. No 1948 additional problems arise with a scenario where the CN is both data 1949 sender and also the authorizing entity. In Figure 8 the CN 1950 authorizes the UCNR to delete the old segment and to establish a new 1951 reservation along the new segment. Furthermore, at the shared 1952 segment only an update of the flow identifier might be necessary. 1954 MN UCNR CN 1956 + E.g. 1957 <-----<-----<------<------<------<------<------- | Create 1958 ACTION | new 1959 +-----------------+ | +-----------------+ | State 1960 | Action: | | | Action: | | 1961 | 'create' along)| | | 'update' along)| | 1962 | new segment) | | | shared segment)| | 1963 +-----------------+ | +-----------------+ | 1964 <------<------<--------+ | 1965 +-----------------+ | 1966 | Action: | | 1967 | 'delete' along)| | 1968 | old segment) | | 1969 +-----------------+ | 1970 | 1971 >----->----->------>------>------>------>------> | 1972 ACK (along new path) | 1973 | 1974 <=============================================== + 1975 Traffic 1977 Figure 12: CN as data sender is authorized 1979 Since the mobile node first detects the route change. A trigger to 1980 the CN allows the CN to quickly react on the route change. There are 1981 three variants: 1983 - The MN sends a trigger to the CN and the CN starts signaling as 1984 shown in Figure 12. 1986 - The MN routes the message back along the reverse path using the 1987 previously established state along the old route. This mechanism 1988 only works if the MN is able to send messages along the old path. 1989 As a generic mechanism this is not suggested. 1991 - An intermediate node act on its own. This might be possible that 1992 the UCRN is an entity which participates in the mobility signaling 1993 (e.g., Mobility Anchor Point (MAP)) exchange. Depending on the 1994 message exchange it needs to be studied whether the signaling 1995 message provides sufficient authorization to trigger the NSIS 1996 exchange. 1998 7.1.3.2 MN is authorizing entity 2000 In this scenario we consider the case where the CN is the data sender 2001 but the MN authorizes actions. The considerations are similar to 2002 those elaborated in Section 7.1.3 where the MN is the data sender but 2003 the CN is the authorizing entity. 2005 7.1.4 Multi-homing Scenarios 2007 Multi-homing scenarios have the property that the more than one path 2008 belongs to a signaling session. In Figure 13 the MN uses two 2009 interfaces to route NSIS message towards the CN. The two individual 2010 sessions are tight together with the same session identifier. The MN 2011 needs to indicate that both reservations need to be kept alive (and 2012 the DCRN should not delete a reservation). At the shared segment 2013 only a single reservation is stored. 2015 From an authorization point of view the session ownership issues is 2016 applicable since the DCRN needs to merge the two reservations into a 2017 single one along the shared segment. 2019 7.1.4.1 MN as data sender 2021 This section shows the multi-homing scenario with the MN as a data 2022 sender. 2024 segment 2 2025 +---+ 2026 ^>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>V 2027 ^ +---+ V 2028 +----+ +----+ +--+ 2029 | MN | |DCNR|>>>>>>>>>>|CN| 2030 |UCNR| | |>>>>>>>>>>| | 2031 +----+ +----+ +--+ 2032 v +---+ ^ shared 2033 v>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>^ segment 2034 +---+ 2035 segment 1 2037 ===============================================================> 2038 Traffic 2040 Figure 13: Multi-homed MN as data sender 2042 If the MN is the authorizing entity then the session ownership 2043 problem needs to be solved. Without solving this type of 2044 authorization problem it is possible for an adversary to "join" the 2045 reservation at the shared segment. Furthermore, it is an open issue 2046 whether reservation merging is allowed only for cases where one flow 2047 identifier is used at different interfaces or even with different 2048 flow identifiers. 2050 If the CN is the authorizing entity then, again, some message needs 2051 to be sent from the CN to the MN to trigger the exchange or to route 2052 the request backwards along the established path. The MN is 2053 reachable via the two paths. 2055 Mobility handling might be smoother since it is possible that only 2056 one interface experiences an IP address change with all the 2057 previously discussed implications. 2059 7.1.4.2 CN as data sender 2061 This section shows the multi-homing scenario with the CN as a data 2062 sender. The scenario is simpler (for the CN authorizing case) than 2063 the one described in Section 7.1 since the signaling message along 2064 the shared segment travels the previously established path. It shows 2065 some similarities with a route change scenario. At the mobile node 2066 itself the two paths merge which again leads to a session ownership 2067 problem. How should the MN know whether a signaling message with the 2068 same session identifier hitting a different interface belongs to the 2069 indicated session authorized by the CN? 2071 If the MN is the authorizing entity then again communication between 2072 the end hosts is required as a trigger. Routing the signaling 2073 messages in the reverse path might, in some cases, also be possible. 2075 segment 2 2076 +---+ 2077 v<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<<^ 2078 v +---+ ^ 2079 +----+ +----+ +--+ 2080 | MN | |UCRN|<<<<<<<<<<|CN| 2081 |DCRN| | |<<<<<<<<<<| | 2082 +----+ +----+ +--+ 2083 ^ +---+ v shared 2084 ^<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<