idnits 2.17.00 (12 Aug 2021) /tmp/idnits23254/draft-fu-nsis-mobility-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (October 17, 2003) is 6790 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) == Unused Reference: 'I-D.ietf-mobileip-fast-mipv6' is defined on line 1053, but no explicit reference was found in the text == Unused Reference: 'I-D.shen-nsis-mobility-fw' is defined on line 1108, but no explicit reference was found in the text == Outdated reference: draft-ietf-ipv6-flow-label has been published as RFC 3697 -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-mobileip-fast-mipv6' -- No information found for draft-ietf-mobileip-hmipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-mobileip-hmipv6' == Outdated reference: draft-ietf-nsis-fw has been published as RFC 4080 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-fw (ref. 'I-D.ietf-nsis-fw') == Outdated reference: draft-ietf-nsis-qos-nslp has been published as RFC 5974 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. 'I-D.ietf-nsis-qos-nslp') == Outdated reference: draft-ietf-nsis-req has been published as RFC 3726 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-req (ref. 'I-D.ietf-nsis-req') == Outdated reference: draft-ietf-nsis-signalling-analysis has been published as RFC 4094 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-signalling-analysis (ref. 'I-D.ietf-nsis-signalling-analysis') == Outdated reference: draft-ietf-seamoby-card-protocol has been published as RFC 4066 ** Downref: Normative reference to an Experimental draft: draft-ietf-seamoby-card-protocol (ref. 'I-D.ietf-seamoby-card-protocol') == Outdated reference: draft-ietf-seamoby-ctp has been published as RFC 4067 ** Downref: Normative reference to an Experimental draft: draft-ietf-seamoby-ctp (ref. 'I-D.ietf-seamoby-ctp') == Outdated reference: draft-ietf-seamoby-mobility-terminology has been published as RFC 3753 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-mobility-terminology (ref. 'I-D.ietf-seamoby-mobility-terminology') == Outdated reference: A later version (-04) exists of draft-manner-lrsvp-02 -- Possible downref: Normative reference to a draft: ref. 'I-D.manner-lrsvp' -- Possible downref: Normative reference to a draft: ref. 'I-D.schulzrinne-nsis-casp' -- Possible downref: Normative reference to a draft: ref. 'I-D.shen-nsis-mobility-fw' -- Possible downref: Normative reference to a draft: ref. 'I-D.shen-nsis-rsvp-mobileipv6' -- Possible downref: Normative reference to a draft: ref. 'I-D.thomas-nsis-rsvp-analysis' -- Possible downref: Normative reference to a draft: ref. 'I-D.tschofenig-nsis-aaa-issues' -- Possible downref: Normative reference to a draft: ref. 'I-D.tschofenig-nsis-sid' -- Possible downref: Normative reference to a draft: ref. 'I-D.westphal-nsis-qos-mobileip' -- Possible downref: Non-RFC (?) normative reference: ref. 'Nemo-ML' ** Downref: Normative reference to an Informational RFC: RFC 2386 ** Downref: Normative reference to an Informational RFC: RFC 3583 Summary: 12 errors (**), 0 flaws (~~), 14 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Fu 3 Internet-Draft Univ. Goettingen 4 Expires: April 16, 2004 P. Mendes 5 DoCoMo Euro-Labs 6 H. Schulzrinne 7 Columbia Univ. 8 H. Tschofenig 9 Siemens 10 October 17, 2003 12 Mobility Issues in Next Steps in Signaling (NSIS) 13 draft-fu-nsis-mobility-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 16, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 This document attempts to identify the various problems with 44 signaling in the data path for the mobile node's on-going flows after 45 it moves to a new point of attachment, and analyzes emerging issues 46 with mobility support in the two-layer Next Steps in Signaling (NSIS) 47 architecture. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Problems with Mobility Support in Signaling . . . . . . . . 5 54 3.1 Problems Caused by Rerouting of Data Packets . . . . . . . . 5 55 3.1.1 State Management . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1.2 Local Path Repair . . . . . . . . . . . . . . . . . . . . . 6 57 3.1.3 Crossover Router Discovery . . . . . . . . . . . . . . . . . 7 58 3.1.4 Update the Unchanged Path . . . . . . . . . . . . . . . . . 8 59 3.1.5 Service-aware Signaling . . . . . . . . . . . . . . . . . . 8 60 3.2 Problems Caused by IP-in-IP Encapsulation . . . . . . . . . 8 61 3.2.1 (Re-)Routing of Signaling Messages . . . . . . . . . . . . . 8 62 3.2.2 IP-in-IP Tunnels . . . . . . . . . . . . . . . . . . . . . . 9 63 3.2.3 Service-aware Signaling . . . . . . . . . . . . . . . . . . 9 64 3.2.4 Routing Interface . . . . . . . . . . . . . . . . . . . . . 9 65 3.2.5 Crossover Router Discovery . . . . . . . . . . . . . . . . . 10 66 4. Analysis on Mobility in the Two-Layer NSIS Architecture . . 11 67 4.1 Identifiers in Data and Control Planes . . . . . . . . . . . 11 68 4.2 Crossover Router Discovery . . . . . . . . . . . . . . . . . 13 69 4.3 Local Path Repair . . . . . . . . . . . . . . . . . . . . . 15 70 4.4 Routing of Signaling Messages . . . . . . . . . . . . . . . 16 71 4.5 IP-in-IP Encapsulation . . . . . . . . . . . . . . . . . . . 17 72 4.6 Interaction between Mobility Routing and NSIS Signaling . . 17 73 4.7 Interaction between NTLP and NSLP Signaling . . . . . . . . 18 74 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 19 75 5.1 Both End-Hosts are Mobile . . . . . . . . . . . . . . . . . 19 76 5.2 Interact with Seamoby Protocols . . . . . . . . . . . . . . 19 77 5.3 Fast State Installation/Advanced Reservations . . . . . . . 19 78 5.4 Resource Discovery in an End-to-End Path . . . . . . . . . . 20 79 5.5 Security and AAA Issues . . . . . . . . . . . . . . . . . . 20 80 5.6 Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 21 81 6. Security Considerations . . . . . . . . . . . . . . . . . . 22 82 6.1 Missing Cost Control . . . . . . . . . . . . . . . . . . . . 22 83 6.2 Implications for Price Determination . . . . . . . . . . . . 23 84 6.3 Intra-domain Mobility . . . . . . . . . . . . . . . . . . . 23 85 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 25 86 References . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 88 Intellectual Property and Copyright Statements . . . . . . . 30 90 1. Introduction 92 The Next Steps in Signaling (NSIS) working group is chartered with 93 the goal of standardizing a generic IP signaling protocol, having 94 Quality of Service (QoS) signaling as the first use case. A 95 two-layer signaling architecture of NSIS, which consists of a generic 96 transport layer protocol (NTLP) and various application signaling 97 procotols (NSLPs, e.g. QoS signaling [I-D.ietf-nsis-qos-nslp] and 98 NAT/firewall traversal), enables a separation of the transport of the 99 signaling from the application signaling. The NSIS framework 100 [I-D.ietf-nsis-fw] describes the functionality of the individual 101 layers in detail. 103 The interactions between mobility and signaling protocols have been 104 analyzed in recent years, in the context of RSVP and Mobile IP 105 interaction [I-D.thomas-nsis-rsvp-analysis], 106 [I-D.shen-nsis-rsvp-mobileipv6], [I-D.manner-lrsvp], [paskalis03], 107 [I-D.ietf-nsis-signalling-analysis], in the context of the DiffServ 108 model [heijenk01] and in the context of optimizing QoS signaling for 109 Mobile IP handovers [I-D.westphal-nsis-qos-mobileip]. 111 A previous study about QoS provisioning in mobile IP [manner02] shows 112 that the difficulty with the interaction between mobility and QoS 113 signaling protocols is mainly due to the design of the latter ones. 114 The I-D on requirements for signaling protocols [I-D.ietf-nsis-req] 115 and a recently published RFC on mobile IP QoS requirements [RFC3583] 116 discuss some issues concerning NSIS signaling and QoS signaling in 117 various mobility environment. However, the interaction between 118 mobility protocols and the NSIS protocols has not yet reached a 119 conclusion. The goal of this document is two-fold. First, it aims to 120 identify the problems that mobility causes to NSIS signaling, in 121 particular in the case of QoS signaling. Secondly, it presents an 122 analysis about mobility support in the two-layer NSIS architecture. 124 In a long term, it may be necessary to study how to use NSIS 125 signaling in particular network environments, such as 3G and WLAN 126 networks. However, we do not assume a specific mobile access network, 127 since it is important to avoid tightening NSIS signaling with any 128 specific access technology. Moreover, NSIS signaling should be also 129 independent from the used mobility management scheme. Hence, we 130 assume a general scenario where mobile nodes (MNs) can have local 131 mobility (inside the same access network) or global mobility (between 132 different access networks), without making NSIS signaling aware of 133 details specific to different mobility management schemes. 135 This document attempts to identify problems with signaling in 136 mobility environments, and the implications caused by different 137 design choices for mobility support in NSIS signaling. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 In addition, this document frequently uses the following terms or 146 abbreviations most of which are defined in Mobile IP, SEAMOBY and 147 NSIS related documents (e.g., 148 [I-D.ietf-seamoby-mobility-terminology]): 150 Home Address 152 Home Agent (HA) 154 Mobile Node (MN) 156 Correspondent Node (CN) 158 Access Router (AR), Previous AR (PAR) and New AR (NAR) 160 Mobile IP (MIP): Mobile IPv6 (MIPv6) or Mobile IPv4 (MIPv4) 162 Hierarchical Mobile IPv6 (HMIPv6) 164 Localized Mobilitiy Management (LMM): Fast/Low Latency Handovers, 165 HMIPv6 or Mobile IPv4 Regional Registration 167 Seamoby mechanisms: Context Transfer, Candidate Access Router 168 Discovery 170 Care of Address (CoA) 172 Regional Care-of-Address (RCoA), On-Link Care-of-Address (LCoA) 174 Mobility Anchor Point (MAP) 176 Mobility Agent: e.g., MAP and HA 178 NSIS Entity (NE) 180 NSIS Transport-Layer Protocol (NTLP) 182 NSIS Signaling-Layer Protocol (NSLP) 184 (Next-)Peer discovery 186 Authentication, Authorization and Accounting (AAA) 188 3. Problems with Mobility Support in Signaling 190 In this section we identify the problems that mobility poses to 191 signaling. The described problems are due to two main characteristics 192 of mobile systems. First, changes caused by re-routing of data 193 packets, essentially posed by topology changes, including the change 194 of host IP addresses and the change of routes for data packets sent 195 to or from the mobile node. Second, the use of IP-in-IP encapsulation 196 in some sections of the end-to-end path. 198 3.1 Problems Caused by Rerouting of Data Packets 200 Rerouting of data packets can be due to non-mobility related events 201 inside the network, or due to the movement of end hosts (mobility). 202 The reparation of a data path due to non-mobility issues, such as 203 load balancing and router failure, are not a concern of this I-D. 205 The movement of end-hosts leads to changes in the data path due to 206 the change of their point of attachment in the network. This results 207 in the original data path between a sender and a receiver to be 208 divided into three paths, all of which intersect at a crossover 209 router: the unchanged path, the newly-added path and the old 210 ("obsoleted") path. 212 The attachment of a mobile node (MN) to a new network point normally 213 means a change in the IP address used to build a data path. However, 214 in some situations, the movement of end-hosts can lead to changes in 215 the data path even if the addresses associated with the data flow do 216 not change in the path. This happens with Hierarchical Mobile IPv6 217 (HMIPv6) [I-D.ietf-mobileip-hmipv6], when a Mobility Anchor Point 218 (MAP) allows an MN to use the Regional Care-of Address (RCoA) as 219 source address without tunneling through the MAP. This means that 220 although the uptream flow have the same source address (RCoA) and 221 destination IP address it can be routed through a different path 222 towards the correspondent node (CN). This section describes a set of 223 problems posed by rerouting due to the movement of end-hosts. 225 3.1.1 State Management 227 Due to rerouting of data packets after handovers, 228 signaling-associated states need to be updated or removed. This 229 concerns with which information is needed for indexing states and 230 where a creation, update or removal of these states is required. 232 In general, a mobile node has a home address as its permanent IP 233 address; after a movement it obtains a new CoA which is the basis for 234 routing its data. If signaling-associated states, which are stored at 235 routers along the path, are indexed based on some temporary data 236 plane information, such as CoA, the states created by previous CoAs 237 can be inaccessible for the signaling after most handover procedures. 238 Furthermore, updating state information along the entire path might 239 be necessary to reflect the topology change of the MN (as one 240 signaling end). 242 3.1.2 Local Path Repair 244 In any mobility approach, a handover causes route changes in some 245 network nodes along the path: for the upstream direction signaling, 246 in the MN and possibly mobility agent(s) (if reverse tunneling is 247 used); for the downstream direction signaling, in the CN, the HA and/ 248 or other mobility agents (when non-route-optimization or LMM is 249 used). Therefore, state needs to be installed on the new path and 250 removed from the old one. We call this "path repair". 252 The installation of state in the new path must be done as quick as 253 possible so that the mobile node does not experience service 254 interruption or service degradation. To allow a quick set up of 255 state in a new path, the path repair should be done locally, i.e., 256 only between the MN and the crossover router, which is the first 257 signaling-aware router where the old and new path meet. This also 258 avoid state duplication on the unchanged path, i.e., the path from 259 the crossover router to the correspondent node. 261 Besides the installation of state in the new path, the local path 262 repair mechanism should release state in the old path, as soon as 263 possible, to avoid wasting resources. Typically, the changed path is 264 located inside an access network, where resources are relatively 265 expensive, thus it might be inefficient to wait for typical 266 soft-state timeouts. However, immediately releasing resources along 267 the old path might cause problems. In case of a ping-pong type of 268 movement resources along the old path might need to be reused again 269 after a very short time period. This means that the MN may return to 270 the previous access network shortly after leaving it, which brings 271 some problems about deciding to when to release state in the old 272 path. 274 The local path repair may be triggered by the mobile node, the 275 mobility agent(s), or by the access router at which the mobile node 276 is attached to. However, the triggering may be constrained by which 277 entities are authorized to carry out what state manipulations, which 278 is then a signaling application and security question. 280 To install states in the new path and to release states in the old 281 path, at least the following problems have to be solved: 283 o Know when to trigger the reparation of the local path. This 284 triggering requires some interaction with mobility management 285 schemes; 287 o Know where to end the local repair (i.e., discovery of the 288 crossover router, which requires differentiating between the MN as 289 sender or receiver. 291 3.1.3 Crossover Router Discovery 293 The problem of finding the crossover router in a new data path is a 294 generalization of the problem of finding next signaling-aware node. 295 It requires to probe the new data path until the old path is reached. 296 Since we have to assume that the MN can be a sender as well as a 297 receiver, the first difficulty to find a crossover router is posed by 298 the asymmetric characteristic of routing. 300 Due to routing asymmetry there is no reason for the crossover router 301 to be the same in the upstream direction and in the downstream 302 direction, even for the same correspondent node. 304 When an MN changes its point of attachment to the network, the 305 discovery of the crossover router is easier for the upstream 306 direction, in which the MN is the sender, than for the downstream 307 direction. In the latter case, although it is the MN that detects 308 data path changes, the discovery of the downstream crossover router 309 has to be done by signaling via the correspondent node. 311 Hence, the problem of discovering the new crossover router can be 312 divided into the following issues: 314 o When to trigger the discovery mechanism. This problem is related 315 with the interaction between a signaling protocol and the mobility 316 scheme, to allow the former to be notified from the latter about 317 the movement of mobile devices. 319 o How to trigger the crossover router discovery mechanism, which 320 depends on the role of the MN as a sender or receiver. 322 o How to identify a crossover router. 324 o Since both end-hosts involved in a bi-directional communication 325 can be mobile, the discovery mechanism trigger by each one of 326 them, as sender and receiver, has to be coordinated. 328 3.1.4 Update the Unchanged Path 330 As discussed earlier, double reservations in the unchanged path 331 should be avoided. This can only be done by being able to establish a 332 relationship between the old and the new flow. This is essentially 333 the same problem faced to release resource in the old path. 335 After the identification of the old flow in the unchanged path, the 336 network control state on the unchanged path must be updated to 337 reflect new flow identification. This leads to the problem of 338 requiring end-to-end signaling, which should be avoided to decrease 339 the control load overhead. However, it should be possible to avoid 340 AAA and admission control processing. 342 3.1.5 Service-aware Signaling 344 Signaling in mobile environments can be quite dependent on the type 345 of applications. For instance, for QoS signaling, having reservations 346 on old and new paths has a cost and should be avoided. On the other 347 hand, in the presence of ping-pong movement, the immediately release 348 of state in the old path can have a performance impact higher than 349 the cost of keeping that state. 351 The main problem posed by these issues is the difficult definition of 352 a signaling protocol general to all types of application in mobile 353 environments. Therefore, interaction of signaling and mobility 354 imposes an analysis of signaling responsibilities of each one of the 355 two NSIS layers in mobile environments. 357 3.2 Problems Caused by IP-in-IP Encapsulation 359 IP-in-IP encapsulation is one type of IP-in-IP tunnels, which have 360 been mentioned in [RFC2746]. Mobile IP's IP-in-IP encapsulation for 361 data packets introduces a number of problems, described below. 363 3.2.1 (Re-)Routing of Signaling Messages 365 One concern is which information can be used for routing of signaling 366 messages. In NSIS, signaling is expected to follow the standard IP 367 routing and mobile IP routing. In a standard IP routing case, 368 messages can be routed according to the destination host's IP address 369 and possibly additional IP header fields. In presence of mobile IP 370 routing protocols, especially when multiple mobility protocols are 371 applied for the same MN-CN communications, possibly nested (e.g., 372 MIPv6+HMIPv6+FMIPv6), it can be difficult to use the MN's address 373 (CoA) as the destination address. Also, as asymmetric routing is 374 common, routing of signaling messages must differentiate between the 375 case of the MN as data sender and the case of the MN as data 376 receiver. 378 3.2.2 IP-in-IP Tunnels 380 If the two end points of a tunnel is not signaling-aware, it might be 381 difficult to provide signaling services for signaling-aware nodes 382 inside the tunnel. In order to, for example, make a QoS reservation 383 for tunnels, it might be necessary to have the tunnel end points to 384 support NSIS. To make things more complicated, mobile IP tunnels 385 co-exist with the change of host addresses (e.g., CoAs) and multiple 386 of them can be possible nested. Therefore, signaling operations over 387 these tunnels, including routing of signaling messages and state 388 management, need to be systematically constructed. 390 3.2.3 Service-aware Signaling 392 Essentially, the purpose of signaling is to provide certain services 393 for the MN's flows. Therefore, signaling must be able to install 394 correct packet classifiers in the signaling-aware nodes. Since the 395 tunnels can be physically long, without loss of generality, the 396 ability to signal and install service-aware state inside the (mobile 397 IP) tunnels is required. Such information may need to be delivered to 398 both the tunnel endpoints and internal signaling-aware nodes. This is 399 difficult because signaling messages - same as other data packets - 400 can be encapsulated so as to be invisible of host addresses. In case 401 that nested tunnels are used (e.g., due to the concurrent usage of 402 several tunneling protocols), where an MN can have several level of 403 CoAs at one time together with a home address, special care would be 404 needed. 406 Another issue with service-aware signaling concerns with selective 407 signaling over tunnels. For example, when an application triggers a 408 per-flow QoS reservation, in some cases it is desired to trigger a 409 QoS reservation also for the tunnel. In some cases it is, however, 410 not desirable to support a QoS reservation for a tunnel. It must 411 therefore be possible for NSIS to decide whether a reservation for a 412 tunnel is desired and at which granularity. An end-to-end QoS 413 reservation need not to be automatically extended to the tunneled 414 region since the tunnel might also serve as a means for aggregation. 416 3.2.4 Routing Interface 418 Mobility reflects different route change due to creating, updating or 419 deleting tunnels, as well as changes in the routing entries, for 420 example in HA, CN, FA/MN, GFA/MAP). It is necessary for the signaling 421 process to obtain such information. RFC 2205 [RFC2205] provides an 422 RSVP/routing interface which can be applicable for mobility/ 423 NSIS-signaling interface. However, it is necessary to coordinate 424 signaling behaviors based on several mobility route change events in 425 different parts in the network, even when a single mobility routing 426 protocol is used. 428 3.2.5 Crossover Router Discovery 430 As previously stated, signaling messages can be hidden for 431 signaling-aware routers inside a tunnel. Therefore, it may be 432 necessary to introduce a separate discovery and signaling message for 433 the tunneled region. 435 4. Analysis on Mobility in the Two-Layer NSIS Architecture 437 The problems described in Section 3.1 have several implications to 438 the funtionality of the two-layer NSIS architecture in providing 439 mobility support. Hence, we analyze how mobility can be supported in 440 the two-layer NSIS architecture. Specifically, we focus on the 441 following issues to understand how different design choices can 442 possible address the enumerated problems. 444 4.1 Identifiers in Data and Control Planes 446 The main purpose of NSIS signaling is to manage flow-based state in 447 the network nodes. As mentioned in Section 3.1.2, to be able to 448 perform a local path repair, the flows in the new path and the 449 correspondent ones in the old path must be identified. The problem is 450 that although a flow is the same, one or both of the source and 451 destination addresses are different due to the new Care-of Address 452 (CoA) which the MN obtained from the new access network. Hence, A 453 stable identifier within NSIS is required which does not change due 454 to mobility. This identifier helps in the discovery of the crossover 455 router, allows the identification of the same flow in the old and new 456 path, and avoids setting up double state in the unchanged path. 458 The definition of a stable identifier must consider whether that 459 identifier should be placed in the data plane or in the control 460 plane. The former requires the definition of a flow identification 461 that does not change. This simplifies the problem of session update, 462 but introduces some problems on packet classification and security. 463 No such mobility independent identifier is available although the 464 IPv6 Flow Label [I-D.ietf-ipv6-flow-label] based on the Home Address 465 was discussed on the mailing list. If the flow identifier is based on 466 the Home Address, for example, once an MN has more than one signaling 467 flow to the same CN, say, one for the purpose of QoS and another for 468 firewall pinhole, it becomes difficult to distinguish between them. 470 In general, a distinguish between data plane and control plane 471 identifiers is necessary: the former of which reflects real, routable 472 IP addresses (home address, CoA or other possible tunnel endpoints' 473 addresses) in order to reflect packet classification, while the 474 latter reflects a stable identifier for managing state information. 475 In other words, the following two identifiers are useful to support 476 mobility in NSIS: 478 o A session identifier (session-ID) in the control plane that must 479 not change during mobility, in order to manage the control state. 480 This session-ID can be a random identifier or cryptographically 481 generated. It should be "globally unique". 482 [I-D.tschofenig-nsis-sid] discusses some possible mechanisms for 483 creating such an identifier. 485 o A flow identifier (flow-ID) in the data plane that describing 486 packets belonging to the flow. The flow-ID should contain fields 487 that are used by NSIS-aware routers to install filter specs 488 (packet classification). Some possible way of composing flow-IDs 489 have been suggested in the NSIS framework document 490 [I-D.ietf-nsis-fw]: 5-tuple, IPv6 flow label or a 3-tuple. Since 491 in mobile IP one or more IP-in-IP tunnels is(are) inserted in the 492 data path (see discussions in Section 3.2), an end-to-end universe 493 flow-ID might be insufficient to route signaling messages, or even 494 to make filter specs for applications' flows. It might be not 495 necessary to have the flow-ID in the NSIS message (and the 496 associated packet classifier/state stored at NSIS nodes) along the 497 entire end-to-end path to be the same; some network nodes (e.g., 498 HA) might need to be able to change it. 500 Note it can also possible that the NSLP has its own session-ID to 501 identify individual sessions. They may or may not be correlated. In 502 the following text, without special statement, session-ID represents 503 NTLP session-ID. 505 The use of a flow-ID based on MN's addresses, e.g., the CoA, and 506 possibly other fields in the IP header is meaningful for many 507 signaling applications. However, whether flow-ID would be needed for 508 all NSLPs is still an open issue. Therefore, the flow-ID could be 509 constructed either by NTLP or by the NSLP layer. While constructing 510 flow-ID, if CoAs are used for identifing flows, even on the unchanged 511 path, signaling would be still needed to update a changed flow 512 identification in the unchanged path. In this case, signaling in the 513 unchanged path should be possible to avoid AAA and admission control 514 processing. Note if flow-ID is managed by the NTLP layer, it can be 515 avoided to be constraint to host addresses, thus make it possible to 516 limit the update of flow-ID information locally, while still allowing 517 flow-ID useful/visible for NSLPs. If the flow-ID contains a CoA, it 518 is necessary to update flow-IDs stored at NSIS nodes along the the 519 unchanged path. Furthermore, from a performance point of view it 520 would be highly advisable to avoid AAA and admission control 521 processing. 523 The management of the session-ID and flow-ID in the two-layer NSIS 524 architecture requires more study, especially after an analysis of the 525 NTLP proposal. In particular, routing of signaling messages at NTLP 526 level can be based on either flow-ID or session-ID. In a 527 flow-ID-based approach, NTLP has to rely on a mapping between certain 528 fields of the flow-ID (e.g., destination IP address and additional IP 529 header information) and local IP (and mobility) routing table. In a 530 session-ID-based approach, NTLP can route the signaling messages 531 based on a mapping between the session-ID and the local NTLP-level 532 state (for example, next/previous NE's address). If there is no 533 existing state, a next-peer discovery has to be performed to create 534 such a state. 536 As the association of different flow-IDs to a single session-ID is a 537 problem common to many signaling applications, the association 538 between both identifiers might be done at the NTLP. However, it could 539 be also possible this association is done at the NSLP layer, if the 540 method used to perform such association is specific to each 541 application. In both possibilities, it is assumed that the session-ID 542 should be visible within the NTLP, allowing it to perform an enhanced 543 forwarding control for packets belonging to that session. 545 Another three related identifiers, namely the message identifier 546 (message-ID) that is introduced in RFC 2961 [RFC2961], the branch 547 identifier (branch-ID) suggested in CASP 548 [I-D.schulzrinne-nsis-casp][fu03] and the Reservation Sequence Number 549 (RSN) proposed in QoS NSLP [I-D.ietf-nsis-qos-nslp], have been also 550 discussed as potential mechanisms useful for mobility support in 551 NSIS. All of three indicate the order in which corresponding 552 signaling messages are processed by the corresponding signaling 553 entities (RSVP, CASP-NTLP and QoS-NSLP daemons, respectively) and try 554 to address the out-of-order problems of signaling messages. 556 Message-ID, together with Epoch object in RFC 2961, concerns with 557 signaling messages between peering neighbors, where the out-of-order 558 problem can come from retransmission/refresh. It was not designed for 559 mobility support specifically. As an extension to message-ID concept, 560 the branch ID (together Session ID) can be used for detecting 561 out-of-order signaling messages along different branches each can 562 consist of multiple hops) for route change and mobility scenarios; it 563 can be generally useful for determining end of (explicit) teardown 564 message to forward on along the unchanged path. Different from the 565 branch ID, the RSN is meaningful in a QoS-NSLP node for protecting 566 out-of-order problems in the associated branches, each of which can 567 consist of multiple QoS NEs. 569 4.2 Crossover Router Discovery 571 The discovery of the crossover router, due to the mobility of 572 end-hosts, must be based on the session-ID of the MN. Additional 573 information might be used for computing an authorization decision or 574 to verify ownership. 576 Since the session-ID is processed at the NTLP layer, we can say that 577 the crossover router of a mobile session is an NTLP-aware node that 578 for a session request coming from one of its interfaces, already has 579 forwarding information about that session stored on one or more 580 interfaces, excluding the incoming one. However, a session may have a 581 different crossover router for the upstream and downstream 582 directions. Hence, we can specify the definition of a crossover 583 router as follows: 585 o Upstream direction: an NTLP-aware NE that for a session request 586 coming from one of its interfaces, already has information about 587 that session stored on more than one interface, excluding the 588 incoming one. 590 o Downstream direction: an NTLP-aware NE that for a session request 591 coming from one of its interfaces, already has information about 592 that session stored on more than one interface, excluding the 593 outgoing one. 595 The discover of the downstream crossover router must be started by 596 the correspondent node, which means that the MN should signal the 597 correspondent node when it detects some movement. However, this 598 procedure does not necessarily increase the handover latency, since 599 end to end message exchanges will be required at the application 600 layer anyway to update the sender with the new address of the 601 receiver. 603 In either situation, the discovery of the crossover router is 604 typically done at the NTLP layer. For instance, to discover the 605 crossover router in the upstream direction, all NEs in the new path 606 have to be found out. A natural way is to use NTLP next peer 607 discovery for this purpose and then one can do state repair 608 immediately after finding out the next NE peer, or perform the state 609 repair after finding the new NE-chain in the new path (as discussed 610 in Section 4.3). 612 Alternatively, it is possible to discover the crossover router at the 613 NSLP layer, since the NSLP is the entity who does the real work for 614 signaling sessions and leaves useful information in NEs. However, 615 this is problematic since the number of NSLPs for a given MN-CN pair 616 may be more than one, which requires discovery of possibly different 617 crossover routers for each NSLP. Furthermore, as NSIS is assumed to 618 follow normal IP routing mechanism, all NSLP sessions between a same 619 MN-CN pair will have the same crossover router. Therefore, definition 620 and discovery of the crossover router at NSLP layer would only 621 increase the complexity. 623 The discovery of the crossover router due to route changes inside the 624 network caused by non-mobility reasons, such as load balancing and 625 node failure should also be taken care by NTLP. In this case, if 626 end-to-end NTLP addressing is used the discovery of the crossover 627 router can be done based on the flow-ID, which does not change; 628 otherwise, session-ID will assist the discovery. The analysis of this 629 situation is beyond the scope of this document, since it is not an 630 issue caused by IP mobility. 632 4.3 Local Path Repair 634 There is a tight relationship between the crossover router discovery 635 mechanism and the local path repair mechanism, because the local path 636 is defined as the path between the MN and the crossover router. Local 637 repair can be done either during (coupled approach) or after 638 (separated approach) the crossover router discovery process. This 639 affects whether only NSLP or both NSLP and NTLP is involved in the 640 local repair. In both cases, all NEs in that path have to be 641 discovered by the NTLP peer discovery mechanism. In the coupled 642 approach, NSLP state in a new local path has to be recovered upon a 643 notification of local NTLP (more details are discussed in Section 644 4.7); the advantage is that it requires less recovery time and the 645 same procedure as normal NSIS signaling. In contrast, the separated 646 approach utilizes an additional NSLP-based procedure which might add 647 the complexity to the whole NSIS signaling; NTLP essentially is used 648 as a transparent underlying mechanism to transport NSLP messages. 650 The interaction between the crossover router discover mechanism and 651 the local path repair mechanism is different for the upstream and 652 downstream directions: 654 o Upstream direction: Since the definition of local path depends 655 upon the location of the crossover router, in the separated 656 approach, it may be considered that is the crossover router 657 discovery mechanism that triggers the local path repair, which 658 itself is triggered by the mobile node. In the coupled approach, 659 the crossover router discovery mechanism takes place before the 660 local path repair is performed, until the crossover router is 661 discovered. 663 o Downstream direction: Since the crossover router of downstream 664 direction can be located in any section in the data path (e.g., 665 between CN and HA, or between HA and CN) a general assumption 666 would be that the crossover router discovery mechanism has to 667 started by the correspondent node (for example, after receiving a 668 binding update message or detecting of a change in its binding 669 entry, see discussions in Section 4.6). However, if LMM mechanisms 670 are used for mobility, it can be also possible that mobility 671 agents such as HA or MAP to start this process. Also, it can be 672 considered that it is the crossover router that starts the local 673 path repair mechanism. A local repair mechanism as the one used by 674 RSVP [RFC2205], where local repair may be triggered by a local 675 route change, is impossible or at least difficult in this case. 676 The reason is that, the node experiencing a route change can only 677 be the CN, HA, or other mobility agents, which is not necessarily 678 the crossover router and it is the destination address that 679 changed and not the route to the old CoA. 681 During the local path repair procedure, setting state in a new path 682 may be conditioned by the session ownership and the availability of 683 resources. In the latter case, when the network is overloaded, it is 684 preferable to keep state belonging to previously established flows 685 while blocking new requests. Therefore, the local path repair 686 mechanism for mobiling sessions should have priority over local 687 requests for resources. 689 4.4 Routing of Signaling Messages 691 As stated in the NSIS framework document [I-D.ietf-nsis-fw], there 692 are two ways to address a signaling message being transmitted between 693 NEs: 695 o Peer-to-peer, where the message is addressed to a neighboring NE 696 that is known to be closer to the destination NE. 698 o End-to-end, where the message is addressed to the flow destination 699 directly, and intercepted by an intervening NE. 701 Each type of message is necessary for some aspects of NTLP operation: 702 in particular, initial discovery of the next peer will usually 703 require end-to-end addressing, whereas reverse routing will always 704 require peer-peer addressing. For other message types, the choice is 705 a matter of protocol design. The mode used is not visible to the 706 NSLP, and the information needed in each case is available from the 707 flow-ID or locally stored as NTLP state. 709 With peer-to-peer addressing, an NE uses the payload of the message 710 to determine the address of the next NE. This requires the address 711 of the destination NE to be derivable from the information present in 712 the payload. Peer-peer addressing inherently supports tunneling of 713 messages between NEs. 715 In the case of end-to-end addressing, the message is addressed to the 716 data flow receiver, and some of the NEs along the data path intercept 717 the messages. The routing of the messages should follow exactly the 718 same path as the associated data flow. To allow signaling packets 719 follow the same route as data packets, network nodes that route 720 packets based on different information from flow-ID must be 721 NSIS-aware. An example is the forwarding of signaling massages into 722 an IP tunnel. In this case the NTLP may need to force a signaling 723 packet to use an output interface that it knows data packets are 724 going to use, even if the IP stack would naturally use a different 725 one. The session-ID, which may be visible within the NTLP, as stated 726 in the framework draft, can be used to identify sessions that should 727 be tunneled instead of routed based on the flow-ID. In this 728 situation, the NE at the end of the tunnel should restart routing 729 messages for this session by using the flow-ID. 731 4.5 IP-in-IP Encapsulation 733 RFC 2746 [RFC2746] provides an approach for RSVP operation over 734 IP-in-IP tunnels. Basically, the same considerations can be also 735 applicable to NSIS operation over mobile IP IP-in-IP encapsulations. 737 Two methods of dealing with this issue are conceivable. One is to 738 adapt signaling payloads which refer to header fields to allow 739 signaling inside the tunnel. Another is to use an adaptable flow-ID 740 to indicate the changed situation of the signaling message. Both can 741 be used together, with certain extensions to RFC 2746 [RFC2746]. 742 However, since NTLP itself is not yet fully determined, the issue of 743 operations over mobile IP's IP-in-IP encapsulated paths needs further 744 study. 746 4.6 Interaction between Mobility Routing and NSIS Signaling 748 One issue related to routing NSIS messages is the interface between 749 the routing protocol and NTLP/NSLP. In normal situations, end-to-end 750 and peer-to-peer addressing can be handle by the NTLP. In the 751 presence of tunnels, the use of the session-ID by the NTLP allows the 752 forwarding of packet through a tunnel. In this situation, only the 753 NTLP need to have an interface to the routing protocol. 755 Another issue related with the interaction between mobility routing 756 and NSIS signaling is whether to use the receipt of binding messages 757 (e.g., in CN, MN or HA) (active way) or to use routing/NSIS interface 758 (passive way), to trigger NSIS signaling. The active way allows 759 faster state recovery and removal, but its disadvantage is that fast 760 or ping-pong movements may result in considerable signaling overhead 761 and possible errors, and moreover, by mobility protocol binding 762 updates can take place periodically even for the MN with the same 763 point of attachment. The passive way, typically after seconds of 764 routing change detection (the MN and the CN in typical cases) of a 765 routing/NSIS interface mechanism to obtain route change and tunnel 766 change information, can be less processing-intensive and thus more 767 promising. 769 If the session-ID is not visible by the NTLP, two alternatives are 770 conceivable: either other methods need to be used at the NTLP level 771 to identify sessions that need to be tunneled, or the forwarding of 772 messages may be done by the NSLP. The latter case required an 773 interface between the NSLP and the routing protocol, which may break/ 774 complicate the NSIS layering. 776 4.7 Interaction between NTLP and NSLP Signaling 778 In the two-layer architecture, there is a separation between NTLP and 779 NSLPs. In general, NTLP is needed to be involved with mobility 780 anyway, for example to transport signaling messages along the new 781 path in order to create new state, or to transport explicit release 782 signaling messages along old path to release old state. In such 783 cases, NTLP should be able to notify NSLP to update state (by 784 initializing NSLP refresh/teardown messages appropriately). An open 785 issue is, however, how and what information the NSLP can expect from 786 NTLP, or directly from the routing interface. 788 5. Open Issues 790 This section discusses some open issues for mobility support in NSIS. 792 5.1 Both End-Hosts are Mobile 794 Considerations about signaling between two MNs. Until now, we are 795 assuming a non-mobile corresponding node. Problems can show up if 796 both devices start to signal at the same time, namely in the local 797 path repair, and signaling of NSIS messages. 799 5.2 Interact with Seamoby Protocols 801 A term "seamless mobility" is often referred to mean that the MN is 802 able to keep an ongoing session seamlessly (without experiencing 803 perceivable service interruption or performance penalty) during and 804 after moving from one access network to another. Measures to achieve 805 seamless mobility include, but not limited to, various LMM 806 mechanisms, seamoby context transfer [I-D.ietf-seamoby-ctp] and 807 candidate access router discovery [I-D.ietf-seamoby-card-protocol] 808 protocols, as well as predictive/anticipated handling mechanism. 809 Issues related to signaling in LMM scenarios have been discussed in 810 previous sections, while interaction of NSIS with seamoby protocols 811 are different because of their effects on parts that are out of the 812 signaling path. [I-D.westphal-nsis-qos-mobileip] studied the issue 813 of QoS signaling for mobile IP with context transfer, but the 814 interaction between NSIS and context transfer still needs further 815 investigation. 817 In the context of mobility between different access routers, it is 818 common to consider performance optimizations in two areas: selection 819 of the optimal access router to handover to, and transfer of state 820 information between the access routers to avoid having to regenerate 821 it in the new access router after handover. Since these solutions are 822 still under development as well as the NTLP, it is premature to 823 specify details on the interaction. 825 5.3 Fast State Installation/Advanced Reservations 827 There are some other issues concerned with performance optimization, 828 for example, the capability to (pre-)discover the required level of 829 end-to-end resources, and to fast (predictive/anticipated/in-advance) 830 state installation. This section discusses fast state installation. 832 Since the time required to establish the session in the new path can 833 induce packet losses and delays, which do not contribute to achieve a 834 seamless handover. Therefore, it is important that the NSIS signaling 835 in a new path can be carried out very quickly. 837 To accomplish a fast state installation, it might be desirable for 838 NSIS to be performed in advance to the movement of MNs. This 839 approach may involve some kind of NSIS proxy, on the new access 840 network, which can signal in the new path on behalf of the MN. If we 841 assume that the end-to-edge communication is done between the MN and 842 its access router, some study is required to determine how to signal 843 between the mobile device currently access router and the NSIS proxy 844 in the new access network - e.g., how to discover the most suitable 845 NSIS proxy, and to establish a communication between access networks. 846 The latter issue is beyond the charter of NSIS, since it involves 847 out-of-path signaling. 849 Moreover, in some anticipated signaling scenarios, NSIS signaling 850 cannot be triggered by the mobility signaling, which required some 851 study about other possible triggers, such as: 853 o Cross-layer triggering. For instance, the layer-2 mechanism can 854 give some information about a possible movement. 856 o Context-awareness triggering. For instance, information about a 857 lower traffic load in some neighbor access networks can trigger 858 the establishment of state in a new path. 860 5.4 Resource Discovery in an End-to-End Path 862 The anticipated signaling for a new path and the selection of a 863 suitable access network may not be enough to ensure seamless 864 mobility. Resource availability in a new end-to-end path may be 865 considered as well. This means that a multimedia session can be 866 disrupted if NSIS cannot signal the required resources in the 867 end-to-end path supplied by the routing protocols. 869 To avoid quality degradation due to mobility, it might be desirable 870 to interact with QoS routing [RFC2386] to discover the optimal (or 871 sub-optimal) end-to-end path. As stated in the framework document 872 [I-D.ietf-nsis-fw], NTLP should work with standard layer 3 routing, 873 thus QoS NSLP needs to be able to handle this type of enhanced 874 routing. Also, in this case, it might be NSLP's responsibility to 875 discover crossover router. 877 However, NSIS performance should not be deteriorated in the presence 878 of such protocols. For instance, state oscillation can occur if flows 879 are frequently re-routed due to changes in the traffic load of 880 alternative end-to-end paths. Such state oscillation must be avoided. 882 5.5 Security and AAA Issues 883 Since a network access authentication protocol can be executed when a 884 host arrives at a new network, AAA procedures are likely to create 885 the necessary financial settlement. In this sense it is helpful to 886 use an identify for the user session which can be mapped to the 887 identify used during the network access procedures to make 888 authorization and charging easier. This is particularly of relevance 889 if the NSLP carries QoS information. For other NSLPs the 890 authorization procedure may be different, but the identity used in 891 the authentication and key exchange procedure (e.g., IKE, IKEv2 or 892 KINK) has to be accessible especially for an entity in the network at 893 the NSLP layer. (Note that this is simpler in case of TLS where the 894 authenticated identity of the user is available to the NSLP via an 895 API). 897 The authorization procedure in a mobile environment still needs more 898 investigation, particularly since there is a strong relationship to 899 network access procedures. 901 5.6 Other Issues 903 Aggregation (as well as multicast) is not a mobility-specific problem 904 in general. In mobility scenarios, one possibly related issue is that 905 whether the messages for creating, updating and removing existing 906 states in different sections in the network need to be grouped 907 according to the new CoAs, or the home address, when the MN is the 908 data receiver. 910 Another issue is signaling in Network Mobility (NEMO) or ad-hoc 911 network scenarios, which has different implications from IP mobility 912 scenarios. In NEMO or ad-hoc networks an end-host's address can 913 remain the same while the path is changed, so state management, 914 crossover router discovery and local repair would rely on the change 915 of path not on the change of host addresses. However, as NSIS 916 signaling is assumed to follow normal IP routing (including IP 917 mobility routing), further study of these issues is beyond the scope 918 of this document. 920 6. Security Considerations 922 It is obvious that mobility support within NSIS raises security 923 issues. A number of mobility scenarios with impacts on security are 924 discussed in Section 7 of [I-D.tschofenig-nsis-aaa-issues]. Even if 925 the signaling message exchange is restarted from scratch (i.e. using 926 a new flow-ID), security handling within NSIS is affected. This type 927 of processing is, however, mostly not a topic for this draft. 929 The introduction of a flow-ID independent identifier referred as 930 session identifier creates security hazards which are discussed in 931 [I-D.tschofenig-nsis-sid]. Once the expected signaling messaging 932 behavior is precisely defined then it is possible to address the 933 raised security concerns. Then it should be possible to define which 934 entities are authorized to perform certain types of actions. In the 935 following subsections we discuss some additional security 936 implications. 938 6.1 Missing Cost Control 940 A large number of service providers (e.g. wireless LAN hotspots) with 941 complex roaming agreements create a non-transparent cost structure. 942 In a traditional subscription-based scenario, users are subscribed to 943 their home network and use this trust relationship to dynamically 944 establish a financial settlement between the visited network and the 945 home network. Additionally, security associations are dynamically 946 established as part of this procedure. This is the typical AAA 947 deployment scenario. In these scenarios users do not learn the 948 identity of the access network as part of a regular authentication 949 and key exchange protocol message exchange. The identity of the 950 access network is possibly never revealed (in a secure fashion). The 951 user is therefore only authenticated to the home network (and 952 hopefully vice versa). While issuing a QoS reservation request to the 953 next NSIS peer (for example in the access network), the end host is 954 typically unaware of the cost of such an end-to-end QoS reservation. 955 Without knowing the costs it is not possible to reject a too 956 expensive QoS reservation. 958 Currently there is no standarized protocol available which allows 959 users to communicate cost limits, to request cost information for 960 network resources or to learn already accumulated costs for a 961 particular reservation. 963 Especially in mobility environments - where an end host is likely to 964 have access to different networks within a short time period - cost 965 control is even more complicated. 967 Some mobility/QoS protocol proposals try to merge existing mobility 968 protocols with QoS signaling (i.e. to apply in-band signaling). 969 Thereby the access network is queried (towards the crossover router 970 or the MAP) for the possibility of making a QoS reservation (without 971 actually making the reservation itself). Without a query mechanism, 972 a user cannot take reservation costs into account when choosing 973 between different access networks (or different access routers). 974 Hence, the user might be able to refuse a more expensive service 975 provider. The ability to allow a user to choose between different 976 providers might be required - not only because of the availability of 977 different access technologies (e.g. IEEE 802.1x, Bluetooth, UTRAN) 978 and different service quality offered, but also for cost reasons. 980 Although real-time notifications of QoS reservation costs (cost 981 control) to the user are out of the scope of NSIS, some interaction 982 might be required. 984 6.2 Implications for Price Determination 986 The problem of determining the price of a QoS reservation has been 987 mentioned in [I-D.tschofenig-nsis-aaa-issues] and closely relates to 988 integrating the end host into the process of authorization. Even if 989 the end host is aware of the price of a QoS reservation during 990 reservation setup the price might change for a number of reasons: 992 o First, mobility in general causes a different path to be chosen 993 and might therefore require a new price determination. End host 994 mobility is visible to the end host itself, therefore the 995 appropriate actions can be triggered by the end host to always 996 determine the correct price. 998 o Route changes somewhere along the path, e.g., mobility in NEMO 999 networks or even mobility in ad-hoc networks, create more 1000 problems, since the route change might not be visible for the end 1001 host. If price determination is based on the number of networks 1002 traversed and intermediate nodes or network contribute to the 1003 total price of a QoS reservation, then a periodic price query is 1004 necessary. Discussions at the NEMO mailing list already point to 1005 this problem [Nemo-ML]. If the price of QoS reservation is 1006 associated with the authorization itself, then a periodic 1007 re-authorization based on the change of prices or on the 1008 accumulated costs is necessary. 1010 6.3 Intra-domain Mobility 1012 Intra-domain mobility with the help of the context transfer protocol 1013 can help to move established state information between different 1014 access nodes within the same administrative domain including security 1015 associations, QoS parameters (QoS NSLP state), NTLP state and even 1016 authorization information. An authorization for a QoS reservation 1017 granted along one path through the access network might also valid at 1018 a different access router or even at a different path within the same 1019 administrative domain. Discussions in the EAP working group, however, 1020 reveal that this might not always be the case. However, if we extend 1021 the scheme from intra-domain context transfer to inter-domain context 1022 transfer then we might encounter some interesting authorization 1023 problems. Note that these issues do not only address authorization of 1024 QoS resources, but are more applicable to network access 1025 authentication and authorization in general. Network access 1026 authentication and authorization would not necessarily be executed 1027 again after attaching to the new domain. Instead, a trust 1028 relationship is established between the new and the old 1029 administrative domain. 1031 In addition to the above issues, performance is important in mobility 1032 environments. Proper security handling accounts for a high percentage 1033 of the total performance. 1035 7. Acknowledgment 1037 The authors would like to acknowledge discussions with Bob Braden, 1038 Marcus Brunner, Ruediger Geib, Seong Jeong, Zhigang Kan, Cornelia 1039 Kappler, Holger Karl, Gary Kenward, Sung-Hyuck Lee, Jukka Manner, 1040 Andrew McDonald, Sarantis Paskali, Cedric Westphal, and Hairong Zheng 1041 in the NSIS working group. In particular, the document benefits from 1042 Hemant Chaskar, Robert Hancock, Charles Shen and Michael Thomas's 1043 insightful comments on various aspects of this topic. 1045 References 1047 [I-D.ietf-ipv6-flow-label] 1048 Rajahalme, J., Conta, A., Carpenter, B. and S. Deering, 1049 "IPv6 Flow Label Specification", 1050 draft-ietf-ipv6-flow-label-07 (work in progress), April 1051 2003. 1053 [I-D.ietf-mobileip-fast-mipv6] 1054 Koodli, R., "Fast Handovers for Mobile IPv6", 1055 draft-ietf-mobileip-fast-mipv6-08 (work in progress), 1056 October 2003. 1058 [I-D.ietf-mobileip-hmipv6] 1059 Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, 1060 "Hierarchical Mobile IPv6 mobility management (HMIPv6)", 1061 draft-ietf-mobileip-hmipv6-08 (work in progress), July 1062 2003. 1064 [I-D.ietf-nsis-fw] 1065 Hancock, R. and et al., "Next Steps in Signaling: 1066 Framework", draft-ietf-nsis-fw-04 (work in progress), 1067 September 2003. 1069 [I-D.ietf-nsis-qos-nslp] 1070 Van den Bosch, S. and et al., "NSLP for Quality-of-Service 1071 signaling", draft-ietf-nsis-qos-nslp-00 (work in 1072 progress), September 2003. 1074 [I-D.ietf-nsis-req] 1075 Brunner, M., "Requirements for Signaling Protocols", 1076 draft-ietf-nsis-req-09 (work in progress), August 2003. 1078 [I-D.ietf-nsis-signalling-analysis] 1079 Manner, J., Fu, X. and P. Pan, "Analysis of Existing 1080 Quality of Service Signaling Protocols", 1081 draft-ietf-nsis-signalling-analysis-02 (work in progress), 1082 July 2003. 1084 [I-D.ietf-seamoby-card-protocol] 1085 Liebsch, M. and et al., "Candidate Access Router 1086 Discovery", draft-ietf-seamoby-card-protocol-04 (work in 1087 progress), September 2003. 1089 [I-D.ietf-seamoby-ctp] 1090 Loughney, J. and et al., "Context Transfer Protocol", 1091 draft-ietf-seamoby-ctp-04 (work in progress), October 1092 2003. 1094 [I-D.ietf-seamoby-mobility-terminology] 1095 Manner, J. and M. Kojo, "Mobility Related Terminology", 1096 draft-ietf-seamoby-mobility-terminology-04 (work in 1097 progress), April 2003. 1099 [I-D.manner-lrsvp] 1100 Manner, J. and et al., "Localized RSVP", 1101 draft-manner-lrsvp-02 (work in progress), July 2003. 1103 [I-D.schulzrinne-nsis-casp] 1104 Schulzrinne, H. and et al., "CASP - Cross-Application 1105 Signaling Protocol", draft-schulzrinne-nsis-casp-01 (work 1106 in progress), March 2003. 1108 [I-D.shen-nsis-mobility-fw] 1109 Shen, C., "Several Framework Issues Regarding NSIS and 1110 Mobility", draft-shen-nsis-mobility-fw-00 (work in 1111 progress), July 2002. 1113 [I-D.shen-nsis-rsvp-mobileipv6] 1114 Shen, C. and et al., "Mobility Extensions to RSVP in an 1115 RSVP-Mobile IPv6 Framework", 1116 draft-shen-nsis-rsvp-mobileipv6-00 (work in progress), 1117 July 2002. 1119 [I-D.thomas-nsis-rsvp-analysis] 1120 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", 1121 draft-thomas-nsis-rsvp-analysis-00 (work in progress), 1122 November 2002. 1124 [I-D.tschofenig-nsis-aaa-issues] 1125 Tschofenig, H., "NSIS Authentication, Authorization and 1126 Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 1127 (work in progress), March 2003. 1129 [I-D.tschofenig-nsis-sid] 1130 Tschofenig, H. and et al., "Security Implications of the 1131 Session Identifier", draft-tschofenig-nsis-sid-00 (work in 1132 progress), June 2003. 1134 [I-D.westphal-nsis-qos-mobileip] 1135 Westphal, C. and H. Chaskar, "QoS Signaling Framework for 1136 Mobile IP", draft-westphal-nsis-qos-mobileip-00 (work in 1137 progress), June 2002. 1139 [Nemo-ML] Alper, Y., "[nemo] AAA and NEMO", discussion in the IETF 1140 Nemo Mailing List (available at: http:// 1141 www.nal.motlabs.com/pipermail/nemo/2003-February/ 1142 000271.html), February 2003. 1144 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1145 Requirement Levels", BCP 14, RFC 2119, March 1997. 1147 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. 1148 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1149 Functional Specification", RFC 2205, Sep 1997. 1151 [RFC2386] Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, "A 1152 Framework for QoS-based Routing in the Internet", RFC 1153 2386, August 1998. 1155 [RFC2746] Terzis, A., Wroclawski, J. and L. Zhang, "RSVP Operation 1156 Over IP Tunnels", RFC 2746, January 2000. 1158 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and 1159 S. Molendini, "RSVP Refresh Overhead Reduction 1160 Extensions", RFC 2961, April 2001. 1162 [RFC3583] Chaskar, H., "Requirements of a Quality of Service (QoS) 1163 Solution for Mobile IP", RFC 3583, September 2003. 1165 [fu03] Fu, X., Schulzrinne, H. and H. Tschofenig, "Mobility 1166 Support for Next-Generation Internet Signaling Protocols", 1167 Proceedings of IEEE Vehicular Technology Conference 1168 2003-Fall, October 2003. 1170 [heijenk01] 1171 Heijenk, G., Karagiannis, G., Rexhepi, V. and L. Westberg, 1172 "DiffServ Resource Management in IP-based Radio Access 1173 Networks", Proceedings of 4th International Symposium on 1174 Wireless Personal Multimedia Communications (WPMC'01), 1175 Aalborg, Denmark, September 2001. 1177 [manner02] 1178 Manner, J., Lopez, A., Mihailovic, A., Velayos, H., 1179 Hepworth, E. and Y. Khouaja, "Evaluation of mobility and 1180 QoS interaction", Computer Networks vol.38, no.2, 1181 pp.137-163, February 2002. 1183 [paskalis03] 1184 Paskalis, S., Kaloxylos, A., Zervas, E. and L. Merakos, 1185 "An efficient RSVP-mobile IP interworking scheme", Mobile 1186 Networks and Applications vol.8, no.3, pp.197-207, June 1187 2003. 1189 Authors' Addresses 1191 Xiaoming Fu 1192 University of Goettingen 1193 Telematics Group 1194 Lotzestr. 16-18 1195 Goettingen 37083 1196 Germany 1198 EMail: fu@cs.uni-goettingen.de 1200 Paulo Mendes 1201 DoCoMo Communications Laboratories Europe GmbH 1202 Landsberger Str. 312 1203 Munich 80687 1204 Germany 1206 EMail: mendes@docomolab-euro.com 1208 Henning Schulzrinne 1209 Columbia University 1210 Dept. of Computer Science 1211 1214 Amsterdam Avenue 1212 New York, NY 10027 1213 USA 1215 EMail: hgs@cs.columbia.edu 1217 Hannes Tschofenig 1218 Siemens AG 1219 Otto-Hahn-Ring 6 1220 Munich 81739 1221 Germany 1223 EMail: Hannes.Tschofenig@siemens.com 1225 Intellectual Property Statement 1227 The IETF takes no position regarding the validity or scope of any 1228 intellectual property or other rights that might be claimed to 1229 pertain to the implementation or use of the technology described in 1230 this document or the extent to which any license under such rights 1231 might or might not be available; neither does it represent that it 1232 has made any effort to identify any such rights. Information on the 1233 IETF's procedures with respect to rights in standards-track and 1234 standards-related documentation can be found in BCP-11. Copies of 1235 claims of rights made available for publication and any assurances of 1236 licenses to be made available, or the result of an attempt made to 1237 obtain a general license or permission for the use of such 1238 proprietary rights by implementors or users of this specification can 1239 be obtained from the IETF Secretariat. 1241 The IETF invites any interested party to bring to its attention any 1242 copyrights, patents or patent applications, or other proprietary 1243 rights which may cover technology that may be required to practice 1244 this standard. Please address the information to the IETF Executive 1245 Director. 1247 Full Copyright Statement 1249 Copyright (C) The Internet Society (2003). All Rights Reserved. 1251 This document and translations of it may be copied and furnished to 1252 others, and derivative works that comment on or otherwise explain it 1253 or assist in its implementation may be prepared, copied, published 1254 and distributed, in whole or in part, without restriction of any 1255 kind, provided that the above copyright notice and this paragraph are 1256 included on all such copies and derivative works. However, this 1257 document itself may not be modified in any way, such as by removing 1258 the copyright notice or references to the Internet Society or other 1259 Internet organizations, except as needed for the purpose of 1260 developing Internet standards in which case the procedures for 1261 copyrights defined in the Internet Standards process must be 1262 followed, or as required to translate it into languages other than 1263 English. 1265 The limited permissions granted above are perpetual and will not be 1266 revoked by the Internet Society or its successors or assignees. 1268 This document and the information contained herein is provided on an 1269 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1270 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1271 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1272 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1273 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1275 Acknowledgment 1277 Funding for the RFC Editor function is currently provided by the 1278 Internet Society.