idnits 2.17.1 draft-ietf-nsis-applicability-mobility-signaling-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 26, 2010) is 5022 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Next Steps in Signaling (nsis) T. Sanda (Ed.) 3 Internet-Draft Panasonic 4 Intended status: Informational X. Fu 5 Expires: January 27, 2011 University of Goettingen 6 S. Jeong 7 HUFS 8 J. Manner 9 TKK 10 H. Tschofenig 11 Nokia Siemens Networks 12 July 26, 2010 14 NSIS Protocols operation in Mobile Environments 15 draft-ietf-nsis-applicability-mobility-signaling-20.txt 17 Abstract 19 Mobility of an IP-based node affects routing paths, and as a result, 20 can have a significant effect on the protocol operation and state 21 management. This document discusses the effects mobility can cause 22 to the Next Steps in Signaling (NSIS) protocol suite, and shows how 23 the NSIS protocols operation can work in different scenarios, with 24 mobility management protocols. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 27, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Requirements Notation and Terminology . . . . . . . . . . . . 6 74 3. Challenges with Mobility . . . . . . . . . . . . . . . . . . . 8 75 4. Basic Operations for Mobility Support . . . . . . . . . . . . 11 76 4.1. General functionality . . . . . . . . . . . . . . . . . . 11 77 4.2. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 4.3. NATFW NSLP . . . . . . . . . . . . . . . . . . . . . . . . 14 79 4.4. Localized signaling in mobile scenarios . . . . . . . . . 16 80 4.4.1. CRN Discovery . . . . . . . . . . . . . . . . . . . . 18 81 4.4.2. Localized State Update . . . . . . . . . . . . . . . . 18 82 5. Interaction with Mobile IPv4/v6 . . . . . . . . . . . . . . . 20 83 5.1. Interaction with Mobile IPv4 . . . . . . . . . . . . . . . 21 84 5.2. Interaction with Mobile IPv6 . . . . . . . . . . . . . . . 23 85 5.3. Interaction with Mobile IP tunneling . . . . . . . . . . . 24 86 5.3.1. Sender-Initiated Reservation with Mobile IP tunnel . . 24 87 5.3.2. Receiver-Initiated Reservation with Mobile IP 88 tunnel . . . . . . . . . . . . . . . . . . . . . . . . 27 89 5.3.3. CRN discovery and State Update with Mobile IP 90 tunneling . . . . . . . . . . . . . . . . . . . . . . 29 91 6. Further Studies . . . . . . . . . . . . . . . . . . . . . . . 31 92 6.1. NSIS Operation in the multihomed mobile environment . . . 31 93 6.1.1. Selecting the best interface(s)/CoA(s) . . . . . . . . 31 94 6.1.2. Differentiation of two types of CRNs . . . . . . . . . 32 95 6.2. Interworking with other mobility protocols . . . . . . . . 33 96 6.3. Intermediate node becomes a dead peer . . . . . . . . . . 34 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 99 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 37 100 9.1. Changes from -00 version . . . . . . . . . . . . . . . . . 37 101 9.2. Changes from -01 version . . . . . . . . . . . . . . . . . 38 102 9.3. Changes from -02 version . . . . . . . . . . . . . . . . . 39 103 9.4. Changes from -03 version . . . . . . . . . . . . . . . . . 39 104 9.5. Changes from -04 version . . . . . . . . . . . . . . . . . 40 105 9.6. Changes from -05 version . . . . . . . . . . . . . . . . . 41 106 9.7. Changes from -06 version . . . . . . . . . . . . . . . . . 41 107 9.8. Changes from -07 version . . . . . . . . . . . . . . . . . 42 108 9.9. Changes from -08 version . . . . . . . . . . . . . . . . . 42 109 9.10. Changes from -09 version . . . . . . . . . . . . . . . . . 42 110 9.11. Changes from -10 version . . . . . . . . . . . . . . . . . 43 111 9.12. Changes from -11 version . . . . . . . . . . . . . . . . . 43 112 9.13. Changes from -12 version . . . . . . . . . . . . . . . . . 43 113 9.14. Changes from -13 version . . . . . . . . . . . . . . . . . 43 114 9.15. Changes from -14 version . . . . . . . . . . . . . . . . . 43 115 9.16. Changes from -15 version . . . . . . . . . . . . . . . . . 43 116 9.17. Changes from -16 version . . . . . . . . . . . . . . . . . 44 117 9.18. Changes from -17 version . . . . . . . . . . . . . . . . . 44 118 9.19. Changes from -18 version . . . . . . . . . . . . . . . . . 44 119 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 45 120 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 121 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 122 12.1. Normative Reference . . . . . . . . . . . . . . . . . . . 47 123 12.2. Informative References . . . . . . . . . . . . . . . . . . 47 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 126 1. Introduction 128 Mobility of IP-based nodes incurs route changes, usually at the edge 129 of the network. Since IP addresses are usually part of flow 130 identifiers, the change of IP addresses implies the change of flow 131 identifiers (i.e., the General Internet Signalling Transport (GIST) 132 message routing information or Message Routing Information (MRI) 133 [draft-ietf-nsis-ntlp]). Local mobility usually does not cause the 134 change of the global IP addresses, but affects the routing paths 135 within the local access network 137 The NSIS protocol suite consists of two layers: NSIS Transport Layer 138 Protocol (NTLP) and the NSIS Signaling Layer Protocol (NSLP). The 139 General Internet Signaling Transport (GIST) [draft-ietf-nsis-ntlp] 140 implements the NTLP, which is a signaling application independent 141 protocol and transports service-related information between 142 neighboring GIST nodes. Each specific service has its own NSLP 143 protocol; currently there are two specified NSLP protocols, the QoS 144 NSLP [draft-ietf-nsis-qos-nslp], and the NAT/Firewall NSLP 145 [draft-ietf-nsis-nslp-natfw] 147 The goals of this document are to present the effects of mobility on 148 the NTLP/NSLPs and to provide guides on how such NSIS protocols work 149 in basic mobility scenarios, including support for Mobile IPv4 and 150 Mobile IPv6 scenarios. We also show how these protocols fulfil the 151 requirements regarding mobility set forth in [RFC3726]. In general, 152 the NSIS protocols work well in mobile environments. The Session ID 153 (SID) used in NSIS signaling enables the separation of the signaling 154 state and the IP addresses of the communicating hosts. This makes it 155 possible to directly update a signaling state in the network due to 156 mobility without being forced to first remove the old state and then 157 re-establish a new one. This is the fundamental reason why NSIS 158 signaling works well in mobile environments. As the additional 159 information, mobility specific enhanced operations, e.g. operations 160 with crossover node (CRN) are also introduced. 162 This document focuses on basic mobility scenarios. Key management 163 related to handovers, multihoming and interactions between NSIS and 164 other mobility management protocols than Mobile IP are out of scope 165 of this document. Also, practical implementations typically need 166 various APIs across components within a node. API issues, e.g., APIs 167 from GIST to the various mobility and routing schemes, are also out 168 of scope of this work. The generic GIST API towards NSLP is flexible 169 enough to fulfill most mobility-related needs of the NSLP layer. 171 2. Requirements Notation and Terminology 173 The terminology in this documnet is based on [draft-ietf-nsis-ntlp] 174 and [RFC3753]. In addition, the following terms are used. Note that 175 in this document, a generic route change caused by regular IP routing 176 is referred to as a 'route change', and the route change caused by 177 mobility is referred to as 'mobility'. 179 (1) Downstream 181 The direction from a data sender towards the data receiver. 183 (2) Upstream 185 The direction from a data receiver towards the data sender. 187 (3) Crossover Node (CRN) 189 A Crossover Node is a node that for a given function is a merging 190 point of two or more paths belonging to flows of the same session 191 along which states are installed. 193 In the mobility scenarios, there are two different types of merging 194 points in the network according to the direction of signaling flows 195 followed by data flows, where we assume that the Mobile Node (MN) is 196 the data sender. 198 Upstream CRN (UCRN): the node closest to the data sender from 199 which the state information in the direction from data receiver to 200 data sender begins to diverge after a handover. 202 Downstream CRN (DCRN): the node closest to the data sender from 203 which the state information in the direction from the data sender 204 to the data receiver begins to converge after a handover. 206 In general, the DCRN and the UCRN may be different due to the 207 asymmetric characteristics of routing although the data receiver is 208 the same. 210 (4) State Update 212 State Update is the procedure for the re-establishment of NSIS state 213 on the new path, the teardown of NSIS state on the old path, and the 214 update of NSIS state on the common path due to the mobility. The 215 State Update procedure is used to address mobility for the affected 216 flows. 218 Upstream State Update: State Update for the upstream signaling 219 flow. 221 Downstream State Update: State Update for the downstream signaling 222 flow. 224 3. Challenges with Mobility 226 This section identifies problems caused by mobility, which affect the 227 operations of NSIS protocol suite. 229 1. Change of route and possibly change of the MN's IP address 231 Topology changes or network reconfiguration might lead to path 232 changes for data packets sent to or from the MN and can cause an IP 233 address change of the MN. Traditional route changes usually do not 234 cause address changes of the flow endpoints. When an IP address 235 changes due to mobility, information within the path-coupled MRI is 236 affected (the source or destination address). Consequently, this 237 concerns GIST as well as NSLPs, e.g., the packet classifier in QoS 238 NSLP or some rules carried in NAT/FW NSLP. So already installed 239 firewall rules, NAT bindings, and QoS reservations may become 240 invalid, because the installed states refer to a non-existent flow. 241 If the affected nodes are also on the new path, this information must 242 be updated accordingly. 244 2. Double state problem 246 After a handover, packets may end up getting delivered through a new 247 path. Since the state on the old path still remains as it was after 248 re-establishing the state along the new path, we have two separate 249 states for the same signaling session. Although the state on the old 250 path will be deleted automatically based on the soft state timeout, 251 the state timer value may be quite long (e.g., 90s as a default 252 value). With the QoS NSLP, this problem might result in the waste of 253 resources and lead to failure of admitting new reservations (due to 254 lack of resources). With the NAT/FW NSLP, it is still possible to 255 re-use this installed state although an MN roams to a new location; 256 this means that another host can send data through a firewall without 257 any prior NAT/FW NSLP signaling because the previous state did not 258 yet expire. 260 3. End-to-end signaling and frequency of route changes 262 The change of route and IP addresses in mobile environments is 263 typically much faster and more frequent than traditional route 264 changes caused by node or link failure. This may result in a need to 265 speed up the update procedure of NSLP states. 267 4. Identification of the crossover node 269 When a handover at the edge of a network has happened, in the typical 270 case, only some parts of the end-to-end path used by the data packets 271 changes. In this situation, the cross-over node (CRN) plays a 272 central role in managing the establishment of the new signaling 273 application state, and removing any useless state, while localizing 274 the signaling only to the affect part of the network. 276 5. Upstream State Update vs. Downstream State Update 278 Due to the asymmetric nature of Internet routing, the upstream and 279 downstream paths are likely not to be exactly the same. Therefore, 280 state update needs to be handled independently for upstream and 281 downstream paths. 283 6. Upstream signaling 285 If the MN is receiver and moves to a new point of attachment, it is 286 difficult to signal upstream towards the Correspondent Node (CN). 287 New signaling states have to be established along the new path, but 288 for a path-coupled Message Routing Method (MRM) this has to be 289 initiated in downstream direction. So NTLP signaling state in 290 upstream direction cannot be initiated by the MN, i.e., GIST cannot 291 easily send a Query in upstream direction (there is an upstream 292 Q-mode, but this is only applicable in a limited scope). The use of 293 additional other protocols such as application level signaling (e.g, 294 SIP) or mobility management signaling (e.g., Mobile IP) may help to 295 trigger NSLP and NTLP signaling from the CN side in downstream 296 direction though. 298 7. Authorization Issues 300 The procedure of State Update may be initiated by the MN, the CN, or 301 even nodes within the network (e.g., crossover node, Mobility Anchor 302 Point (MAP) in Hierarchical Mobile IP (HMIP)). This State Update on 303 behalf of the MN raises authorization issues about the entity that is 304 allowed to make these state modifications. 306 8. Dead peer and invalid NR problem 308 When the MN is on the path of a signaling exchange, after handover 309 the old Access Router (AR) can not forward NSLP messages any further 310 to the MN. In this case, the old AR's mobility or routing protocol, 311 or even the NSLP may trigger an error message to indicate that the 312 last node fails or is truncated. This error message is forwarded and 313 may mistakenly cause the removal of the state on the existing common 314 path, if the state is not updated before the error message is 315 propagated through the signaling peers. This is called the 'invalid 316 NSIS Receiver (NR) problem'. 318 9. IP-in-IP Encapsulation 319 Mobility protocols may use IP-in-IP encapsulation on the segment of 320 the end-to-end path for routing traffic from the CN to the MN, and 321 vice versa. Encapsulation harms any attempt to identify and filter 322 data traffic belonging to, for example, a QoS reservation. Moreover, 323 encapsulation of data traffic may lead to changes in the routing 324 paths since the source and the destination IP addresses of the inner 325 header differ from those of the outer header. Mobile IP uses 326 tunneling mechanisms to forward data packets among end hosts. 327 Traversing over the tunnel, NSIS signaling messages are transparent 328 on the tunneling path due to the change of flow's addresses. In case 329 of interworking with Mobile IP-tunneling, CRNs can be discovered on 330 the tunneling path. It enables NSIS protocols to perform State 331 Update procedure over the IP-tunnel. In this case, GIST needs to 332 cope with the change of Message Routing Information (MRI) for the CRN 333 discovery on the tunnel. Also, NSLP signaling needs to determine 334 when to remove the tunneling segment on the signaling path and/or how 335 to tear down the old state via interworking with the IP-tunneling 336 operation. Furthermore, tunneling adds additional IP header as 337 overhead that must be taken into account by QoS NSLP for example, 338 when resources must be reserved accordingly. So an NSLP must usually 339 be aware whether tunneling or route optimization is actually used for 340 a flow [draft-ietf-nsis-tunnel]. 342 4. Basic Operations for Mobility Support 344 This section presents the basic operations of the NSIS protocol suite 345 after mobility related route changes. Detailed discussion of the 346 operation of Mobile IP with respect to NSIS protocols are discussed 347 in the subsequent section. 349 4.1. General functionality 351 The NSIS protocol suite decouples state and flow identification. A 352 state is stored and referred by the Session ID (SID). Flows 353 associated with a given NSLP state are defined by the Message Routing 354 Information (MRI). GIST notices when a routing path associated with 355 a SID changes, and provides a notification to the NSLP. It is then 356 up to the NSLP to update the state information in the network. Thus, 357 the effect is an update to the states, not a full new request. This 358 decoupling effectively solves also a typical problem with certain 359 signaling protocols, where protocol state is identified by flow 360 endpoints, and when flow endpoint addresses change, the whole session 361 state becomes invalid. 363 A further benefit of the decoupling is that if the MRI, i.e., the IP 364 addresses associated with the data flow, remain the same after 365 movement, the NSIS signaling will repair only the affected path of 366 the end-to-end session. Thus, updating the session information in 367 the network will be localized, and no end-to-end signaling will be 368 needed. If the MRI changes, end-to-end signaling usually can not be 369 avoided since new information for proper data flow identification 370 must be provided all the way between the data sender and receiver, 371 e.g., in order to update filters, QoS profiles, or other flow related 372 session data. 374 GIST provides NSLPs with an identifier of the next signaling peer, 375 the SII Handle. When this SII Handle changes, the NSLP knows a 376 routing change has happened. Yet, the NSLP can also figure out 377 whether it is also the crossover node for the session. Thus, CRN 378 discovery is always done at the NSLP layer because only NSLPs have a 379 notion of end-to-end signaling. 381 When a path changes, the session information on the old path needs to 382 be removed. Normally, the information is released when the session 383 timer is expired after a routing change. But the NSLP running on the 384 end-host or the CRN, depending on the direction of the session, may 385 use the SII Handle (provided by GIST) to explicitly remove states on 386 the old path; new session information is simultaneously set up on the 387 new path. Both current NSLPs use sequence numbers to identify the 388 order of messages, and this information can be used by the protocols 389 to recover from a routing change. 391 Since NSIS operates on a hop-by-hop basis, any peer can perform state 392 updates. This is possible because a chain-of-trust is expected 393 between NSIS nodes. If this weren't the case, e.g., true resource 394 reservations would not be possible; one misbehaving or compromised 395 node would effectively break everything. Thus, currently the NSIS 396 protocols do not limit the roles of each NSIS signaling peer on a 397 path, and any node can make updates. Yet, some updates are reflected 398 back to the signaling end points, and they can decide whether the 399 signaling actually succeeded, or not. 401 If the signaling packets are encapsulated in a tunnel, it is 402 necessary to perform a separate signaling exchange for the tunneled 403 region. Furthermore, a binding is needed to tie the end-to-end and 404 tunneled session together. 406 Furthermore, in some cases the NSLP must be aware whether tunneling 407 is used, since additional tunneling overhead must be taken into 408 account, e.g., for resource reservations etc. 410 4.2. QoS NSLP 412 Figure 1 illustrates an example of QoS NSLP signaling in a Mobile 413 IPv6 route optimization case, for a data flow from the MN to the CN, 414 where sender-initiated reservation is used. Once a handover event is 415 detected in the MN, the MN needs to acquire the new care-of-address 416 and update the path coupled MRI accordingly. Then the MN issues a 417 QoS NSLP RESERVE message towards the CN, that carries the unique 418 session ID and other identification information for the session, as 419 well as the reservation requirements (step(1)~(4) in Figure 1). Upon 420 receipt of the RESERVE message, the QoS NSLP nodes (which will be 421 discovered by the underlying NTLP) establish the corresponding QoS 422 NSLP state, and forward the message towards the CN. When there is 423 already an existing NSLP state with the same session ID, the state 424 will be updated. If all the QoS NSLP nodes along the path support 425 the required QoS, the CN in turn responds with a RESPONSE message, to 426 confirm the reservation (step(5)~(6) in Figure 1). 428 In a bi-directional tunneling case, the only difference is that the 429 RESERVE message should be sent to the HA instead of the CN, and the 430 node which responds with a RESPONSE should be the HA instead of the 431 CN too. More details are discussed in Section 5 433 Therefore, for the basic operation there is no fundamental difference 434 among different operation modes of Mobile IP, and the main issue of 435 mobility support in NSIS is to trigger NSLP signaling appropriately 436 when a handover event is detected, and the destination of the NSLP 437 signaling shall follow the Mobile IP data path as being path-coupled 438 signaling. 440 In this process, the obsoleted state in the old path is not 441 explicitly released because the state can be released by timer 442 expiration. To speed up the process, it may be possible to localize 443 the signaling. When the RESERVE message reaches a node, depicted as 444 CRN in this document (step(2) in Figure 1), where a state is 445 determined for the first time to reflect the same session, the node 446 may issue a NOTIFY message towards the MN's old care-of-address (CoA) 447 (step(9) in Figure 1). The QNE adjacent to MN's old position stops 448 the NOTIFY message (step(10) in Figure 1), and sends RESERVE message 449 (with Teardown bit set) towards the CN, to release the obsoleted 450 state (step(11) in Figure 1). This RESERVE with tear message is 451 stopped by the CRN (step(12) in Figure 1). The Reservation Sequence 452 Number (RSN) used in the messages is used to distinguish the order of 453 the signaling. More details are described in Section 4.4 455 MN QNE1 MN QNE2 QNE3 QNE4 CN 456 (CoA1) | (CoA2) | (CRN) | | 457 | | | | | | | 458 | | |RESERVE | | | | 459 | | |------->| | | | 460 | | | (1) |RESERVE | | | 461 | | | |--------->| | | 462 | | | | (2) |RESERVE | | 463 | | | | |------->| | 464 | | | | | (3) |RESERVE | 465 | | | | | |------->| 466 | | | | NOTIFY| | (4) | 467 | | | |<---------| | | 468 | | | NOTIFY| (9) | | | 469 | |<------------| | | | 470 | | | (10) | | | | 471 | |RESERVE(T) | | | | 472 | |------------>| | | | 473 | | | (11) |RESERVE(T)| | | 474 | | | |--------->| | | 475 | | | | (12) | |RESPONSE| 476 | | | | | |<-------| 477 | | | | |RESPONSE| (5) | 478 | | | | RESPONSE|<-------| | 479 | | |RESPONSE|<---------| (6) | | 480 | | |<------ | (7) | | | 481 | | | (8) | | | | 482 | | | | | | | 484 Figure 1: Basic operation example 486 Further cases to consider are: 488 * receiver-initiated reservation if MN is sender 490 * sender-initiated reservation if MN is receiver 492 * receiver-initiated reservation if MN is receiver 494 In the first case, the MN can easily initiate a new QUERY along the 495 new path after movement, thereby installing signaling state and 496 eventually eliciting a new RESERVE from the CN in upstream direction. 497 Similarly, the second and third cases require the CN to initiate a 498 RESERVE or QUERY message respectively. The difficulty in both cases 499 is, however, to let the CN know that the MN has moved. Because the 500 MN is the receiver it cannot simply use an NSLP message to do so, 501 because upstream signaling is not possible in this case (cf. Sec. 3, 502 Upstream Signaling). 504 4.3. NATFW NSLP 506 Figure 2 illustrates an example of NATFW NSLP signaling in a Mobile 507 IPv6 route optimization case, for a data flow from the MN to the CN. 508 The difference to the QoS NSLP is that for the NATFW NSLP only the 509 NSIS initiator (NI) can update the signalling session, in any case. 510 Once a handover event is detected in the MN, the MN must get to know 511 the new care-of-address and update the path coupled MRI accordingly. 512 Then the MN issues a NATFW NSLP CREATE message towards the CN, that 513 carries the unique session ID and other identification information 514 for the session (step(1)~(4) in Figure 2). Upon receipt of the 515 CREATE message, the NATFW NSLP nodes (which will be discovered by the 516 underlying NTLP) establish the corresponding NATFW NSLP state, and 517 forward the message towards the CN. When there is already an 518 existing NSLP state with the same session ID, the state will be 519 updated. If all the NATFW NSLP nodes along the path accept the 520 required NAT/firewall configuration, the CN in turn responds with a 521 RESPONSE message, to confirm the configuration (step(5)~(8) in 522 Figure 2). 524 In a bi-directional tunneling case, the only difference is that the 525 CREATE message should be sent to the HA instead of the CN, and the 526 node which responds with a RESPONSE should be the HA instead of the 527 CN too. 529 Therefore, for the basic operation there is no fundamental difference 530 among different operation modes of Mobile IP, and the main issue of 531 mobility support in NSIS is to trigger NSLP signaling appropriately 532 when a handover event is detected, and the destination of the NSLP 533 signaling shall follow the Mobile IP data path as being path-coupled 534 signaling. 536 In this process, the obsoleted state in the old path is not 537 explicitly released because the state can be released by timer 538 expiration. To speed up the process, when the CREATE message reaches 539 a node, depicted as CRN in this document (step(2) in Figure 2), where 540 a state is determined for the first time to reflect the same session, 541 the node may issue a NOTIFY message towards the MN's old CoA 542 (step(9)~(10) in Figure 2) and when the NI notices this, it sends a 543 CREATE message towards the CN to release the obsoleted state 544 (step(11)~(12)) in Figure 2). 546 MN NI MN NF1 NF2 NF3 CN 547 (CoA1) | (CoA2) | (CRN) | | 548 | | | | | | | 549 | | | | | | | 550 | | |CREATE | | | | 551 | | |------->| | | | 552 | | | (1) |CREATE | | | 553 | | | |--------->| | | 554 | | | | (2) |CREATE | | 555 | | | | |------->| | 556 | | | | | (3) |CREATE | 557 | | | | | |------->| 558 | | | | NOTIFY| | (4) | 559 | | | |<---------| | | 560 | | | NOTIFY| (9) | | | 561 | |<------------| | | | 562 | | | (10) | | | | 563 | |CREATE(CoA2) | | | | 564 | |------------>| | | | 565 | | | (11) |CREATE(CoA2) | | 566 | | | |--------->| | | 567 | | | | (12) | |RESPONSE| 568 | | | | | |<-------| 569 | | | | |RESPONSE| (5) | 570 | | | | RESPONSE|<-------| | 571 | | |RESPONSE|<---------| (6) | | 572 | | |<------ | (7) | | | 573 | | | (8) | | | | 574 | | | | | | | 575 | | | | | | | 577 Figure 2: NATFW NSLP operation example 579 4.4. Localized signaling in mobile scenarios 581 This section describes detailed CRN operations. As described in 582 previous sections, CRN operations are informational. 584 As shown in Figure 3, mobility generally causes signaling path to 585 either converge or diverge depending on the direction of each 586 signaling flow. 588 Old path 589 +--+ +-----+ 590 original |MN|<------ |OAR | ---------^ 591 address | | |NSLP1| ^ 592 +--+ +-----+ ^ common path 593 | C +-----+ +-----+ +--+ 594 | | |<--|NSLP1|----|CN| 595 | |NSLP2| |NSLP2| | | 596 v New path +-----+ +-----+ +--+ 597 +--+ +-----+ V B A 598 New CoA |MN|<------ |NAR |----------V >>>>>>>>>>>> 599 | | |NSLP1| ^ 600 +--+ +-----+ ^ 601 D ^ 602 <=====(upstream signaling followed by data flows) ===== 604 (a) The topology for upstream NSIS signaling flow due to 605 mobility (in case the MN is a data sender) 607 Old path 608 +--+ +-----+ 609 original |MN|------> |OAR | ----------V 610 | | |NSLP1| 611 address +--+ +-----+ V common path 612 | K +-----+ +-----+ +--+ 613 | | |---|NSLP1|--->|CN| 614 | |NSLP2| |NSLP2| | | 615 v New path +-----+ +-----+ +--+ 616 +--+ +-----+ ^ M N 617 New CoA |MN|------> |NAR |-----------^ >>>>>>>>>>>> 618 | | |NSLP1| ^ 619 +--+ +-----+ ^ 620 L ^ 621 ====(downstream signaling followed by data flows) ======> 623 (b) The topology for downstream NSIS signaling flow due to 624 mobility (in case the MN is a data sender) 626 Figure 3: The topology for NSIS signaling caused by mobility 628 These topological changes due to mobility cause the NSIS state 629 established in the old path to be useless. Such state may be removed 630 as soon as possible. In addition, NSIS state needs to be established 631 along the new path and be updated along the common path. The re- 632 establishment of NSIS signaling may be localized when route changes 633 (including mobility) occur to minimize the impact on the service and 634 to avoid unnecessary signaling overhead. This localized signaling 635 procedure is referred to as State Update (refer to the terminology 636 section). In mobile environments, for example, the NSLP/ NTLP needs 637 to limit the scope of signaling information only to the affected 638 portion of the signaling path because the signaling path in the 639 wireless access network usually changes only partially. 641 4.4.1. CRN Discovery 643 The CRN is discovered at the NSLP layer. In case of QoS NSLP, when a 644 RESERVE message with an existing SESSION_ID is received and its 645 Source Identification Information (SII) and MRI are changed, the QNE 646 knows its upstream or downstream peer has changed by the handover, 647 for sender-oriented and receiver-oriented reservations, respectively. 648 And realizes it is implicitly the CRN. 650 4.4.2. Localized State Update 652 In the downstream State Update, the MN initiates the RESERVE with a 653 new RSN for state setup toward a CN and also the implicit DCRN 654 discovery is performed by the procedure of signaling as described in 655 Section 4.4.1. The MRI from the DCRN to the CN (i.e., common path) 656 is updated by the RESERVE message. DCRN may also send NOTIFY with 657 "Route change (0x02)" to previous upstream peer. The NOTIFY is 658 forwarded hop-by-hop and reaches the edge QNE (i.e., QNE1 in 659 Figure 1). After the QNE is aware that the MN as QNI has disappeard 660 (how this is can be noticed is out of scope of NSIS, yet, e.g., GIST 661 will eventually know this through undelivered messages), the QNE 662 sends a tearing RESERVE towards downstream. When the tearing RESERVE 663 reaches the DCRN, it stops forwarding and drops it. Note that, 664 however, it is not necessary for GIST state to be explicitly removed 665 because of the inexpensiveness of the state maintenance at the GIST 666 layer [draft-ietf-nsis-ntlp]. Note that, the sender-initiated 667 approach leads to faster setup than the receiver-initiated approach 668 as in RSVP [RFC2205]. 670 In the scenario of an upstream State Update, there are two possible 671 methods for state update. One is the CN (or a HA/ a Gateway Foreign 672 Agent (GFA)/ a MAP) sends the refreshing RESERVE message toward the 673 MN to perform State Update upon receiving trigger (e.g., Mobile IP 674 (MIP) binding update). UCRN is discovered implicitly by the CN- 675 initiated signaling along the common path as described in 676 Section 4.4.1. When the refreshing RESERVE reaches to the adjacent 677 QNE of UCRN, the QNE sends back a RESPONSE saying "full QoS 678 Specification (QSPEC) required". Then the UCRN sends the RESERVE 679 with full QSPEC towards the MN to set up a new reservation. The UCRN 680 may also send tearing RESERVE to previous downstream peer. The 681 tearing RESERVE is forwarded hop-by-hop and reaches to the edge QNE. 682 After the QNE is aware that the MN as QNI has disappeard, the QNE 683 drops the tearing peer. Another method is, if GIST hop is already 684 established on the new path (e.g. by QUERY from the CN, or the HA/ 685 GFA/ MAP) when MN gets a hint from GIST that routing has changed, the 686 MN sends a NOTIFY towards upstream saying "Route Change" 0x02. When 687 the NOTIFY hits UCRN, the UCRN is aware that the NOTIFY is for a 688 known session comes from a new SII-Handle. Then the UCRN sends a 689 RESERVE with a new RSN and an RII towards the MN. By receiving the 690 RESERVE, the MN replies RESPONSE. The UCRN may also send tearing 691 RESERVE to previous downstream peer. The tearing RESERVE is 692 forwarded hop-by-hop and reaches to the edge QNE. After the QNE is 693 aware that the MN as QNI is disappeared, the QNE drops the tearing 694 peer. 696 The State Update on the common path to reflect the changed MRI brings 697 issues on the end-to-end signaling addressed in Section 3. Although 698 the State Update over the common path does not give rise to re- 699 processing of AAA and admission control, it may lead to the increased 700 signaling overhead and latency. 702 One of the goals of the State Update is to avoid the double 703 reservation on the common path as described in Section 3. The double 704 reservation problem on the common path can be solved by establishing 705 a signaling association using a unique SID and by updating packet 706 classifier/MRI. In this case, even though the flows on the common 707 path have different MRIs, it refers to the same NSLP state. 709 5. Interaction with Mobile IPv4/v6 711 Mobility management solutions like Mobile IP try to hide mobility 712 effects from applications by providing stable addresses and avoiding 713 address changes. On the other hand, the MRI [draft-ietf-nsis-ntlp] 714 contains flow addresses and will change if the CoA changes. This 715 makes impact on some NSLPs such as QoS NSLP and NAT/FW NSLP. 717 QoS NSLP must be mobility-aware because it needs to care about the 718 resources on the actual current path, and sending a new RESERVE or 719 QUERY for the new path. Applications on top of Mobile IP communicate 720 along logical flows that use home addresses, whereas QoS NSLP has to 721 be aware of the actual flow path, e.g., whether the flow is currently 722 tunneled or route-optimized etc. QoS NSLP may have to obtain current 723 link properties, especially additional overhead due to mobility 724 header extensions that must be taken into account in QSPEC (e.g., the 725 m parameter in the traffic model (TMOD)). Therefore, NSLPs must 726 interact with mobility management implementations in order to request 727 information about the current flow address (CoAs), source addresses, 728 tunneling, or, overhead. Furthermore, an implementation must select 729 proper interface addresses in the natural language interface (NLI) in 730 order to ensure that a corresponding Messaging Association is 731 established along the same path as the flow in the MRI. Moreover, 732 the home agent needs to perform additional actions (e.g., 733 reservations) for the tunnel. If the home agent lacks support of a 734 mobility-aware QoS NSLP a missing tunnel reservation is usually the 735 result. Practical problems may occur in situations where a home 736 agent needs to send a GIST query (with S-flag=1) towards the MN's 737 Home Address and the query is not tunneled due to route optimization 738 between HA and MN: the query will be wrongly intercepted by QNEs 739 within the tunnel. 741 NAT/FW box needs to be configured before MIP signaling, hence NAT/FW 742 signaling will have to be performed, to allow Return Routability Test 743 (RRT) and Binding Update (BU)/Binding Acknowledgement (BA) messages 744 to traverse the NAT/FWs in the path. After RRT and BU/BA are 745 completed, another NAT/FW signaling needs to be performed for passing 746 the data. Optimized version can include a combined NAT/FW message to 747 cover both RRT and BU/BA messages pattern. However this may require 748 NAT/FW NSLP to do a slight update to support carrying multiple NAT/FW 749 rules in one signaling round trip. 751 This section analyzes NSIS operation with tunneled route case 752 especially for QoS NSLP. 754 5.1. Interaction with Mobile IPv4 756 In Mobile IPv4 [RFC3344], the data flows are forwarded based on 757 triangular routing, and an MN retains a new CoA from the Foreign 758 Agent (FA) (or an external method such as DHCP) in the visited access 759 network. When the MN acts as a data sender, the data and signaling 760 flows sent from the MN are directly transferred to the CN not 761 necessarily through the HA or indirectly through the HA using the 762 reverse tunneling. On the other hand, when the MN act as a data 763 receiver, the data and signaling flows sent from the CN are routed 764 through the IP tunneling between the HA and the FA (or the HA and the 765 MN in case of the Co-located CoA). With this approach, routing is 766 dependent on the HA, and therefore the NSIS protocols interact with 767 the IP tunneling procedure of Mobile IP for signaling. 769 The Figure 4 (a) to (e) show the NSIS signaling flows depending on 770 the direction of the data flows and the routing methods. 772 MN FA (or FL) CN 773 | | | 774 | IPv4-based Standard IP routing | 775 |------------ |--------------------------------->| 776 | | | 778 (a) MIPv4: MN-->CN, no reverse tunnel 780 MN FA HA CN 781 | IPv4 (normal) | | | 782 |--------------->| IPv4(tunnel) | | 783 | |--------------->| IPv4 (normal)| 784 | | |------------->| 786 (b) MIPv4: MN-->CN, the reverse tunnel with FA CoA 788 MN (FL) HA CN 789 | | | | 790 | IPv4(tunnel) | | 791 |------------------------------->|IPv4 (normal) | 792 | | |-------------->| 794 (c) MIPv4: MN-->CN, the reverse tunnel with Co-located CoA 796 CN HA FA MN 797 |IPv4 (normal) | | | 798 |-------------->| | | 799 | | MIPv4 (tunnel) | | 800 | |---------------->| IPv4 (normal)| 801 | | |------------->| 803 (d) MIPv4: CN-->MN, Foreign agent Care-of-address 805 CN HA (FL) MN 806 |IPv4(normal ) | | | 807 |-------------->| | | 808 | | MIPv4 (tunnel) | | 809 | |------------------------------->| 810 | | | | 812 (e) MIPv4: CN-->MN with Co-located Care-of-address 814 Figure 4: NSIS signaling flows under different Mobile IPv4 scenarios 816 When an MN (as a signaling sender) arrives at a new FA and the 817 corresponding binding process is completed (Figure 4 (a), (b) and 818 (c)), the MN performs the CRN discovery (DCRN) and the State Update 819 toward the CN (as described in Section 4) to establish the NSIS state 820 along the new path between the MN and the CN. In case reverse tunnel 821 is not used (Figure 4 (a)), a new NSIS state is established on direct 822 path from the MN to the CN. If the reverse tunnel and FA CoA are 823 used (Figure 4 (b)), a new NSIS state is established along a 824 tunneling path from the FA to the HA separately from end-to-end path. 825 CRN discovery and State Update in tunneling path is also separately 826 performed if necessary. If the reverse tunnel and co-located CoA are 827 used (Figure 4 (c)) the NSIS signaling for the DCRN discovery and the 828 State Update is the same as the case of using FA CoA above except for 829 the use of the reverse tunneling path from the MN to the HA. That 830 is, in this case, one of tunnel end points is the MN, not the FA. 832 When an MN (as a signaling receiver) arrives at a new FA and the 833 corresponding binding process is completed (Figure 4 (d) and (e)), 834 the MN sends NOFITY message to the signaling sender, i.e., the CN. 835 In case FA CoA is used (Figure 4 (d)), the CN initiates a NSIS 836 signaling to update an existing state between the CN and the HA, and 837 afterwards the NSIS signaling messages are forwarded to the FA and 838 reaches to the MN. A new NSIS state is established along the 839 tunneling path from the HA to the FA separately from end-to-end path. 840 During this operation, a UCRN is discovered on the tunneling path, 841 and a new MRI for the State Update on the tunnel may need to be 842 created. CRN discovery and State Update in tunneling path is also 843 separately performed if necessary. In case collocated CoA is used 844 (Figure 4 (d)) the NSIS signaling for the UCRN discovery and the 845 State Update is also the same as the case of using FA CoA above 846 except for the end point of tunneling path from the HA to the MN. 848 Note that Mobile IPv4 optionally supports route optimization. In the 849 case route optimization is supported, the signaling operation will be 850 the same as Mobile IPv6 route optimization. 852 5.2. Interaction with Mobile IPv6 854 Unlike Mobile IPv4, with Mobile IPv6 [RFC3775], the FA is not 855 required on the data path. If an MN moves to visited network, a CoA 856 at the network is allocated like co-located CoA in Mobile IPv4. In 857 addition, the route optimization process between the MN and CN can be 858 used to avoid the triangular routing in the Mobile IPv4 scenarios. 860 If the route optimization is not used, data flow routing and NSIS 861 signaling procedures (including the CRN discovery and the State 862 Update) will be similar to the case of using the Mobile IPv4 with co- 863 located CoA. However, if Route Optimization is used, signaling 864 messages are sent directly from the MN to the CN, or from the CN to 865 the MN. Therefore, route change procedures described in Section 4 866 are applicable to this case. 868 5.3. Interaction with Mobile IP tunneling 870 In this section, we assume that MN acts as an NI and CN acts as an NR 871 in interworking between Mobile IP and NSIS signaling. 873 Scenarios for interaction with Mobile IP tunneling vary depending on: 875 - Whether a tunneling entry point (Tentry) is an MN or other node. 876 In case Mobile IPv4 co-located CoA or Mobile IPv6, Tentry is an 877 MN. In case Mobile IPv4 FA CoA case, Tentry is a FA. In both 878 case, a HA is tunneling exit point (Texit). 880 - Whether the mode of QoS-NSLP signaling is sender-initiated or 881 receiver initiated. 883 - Whether the operation mode over tunnel is with pre-configured 884 QoS sessions or with dynamically created QoS sessions as described 885 in [draft-ietf-nsis-tunnel]. 887 The following subsection describes sender-initiated and receiver- 888 initiated reservation with Mobile IP tunneling and CRN discovery and 889 State Update with Mobile IP tunneling. 891 5.3.1. Sender-Initiated Reservation with Mobile IP tunnel 893 The following scenario assumes that a FA is a Tentry. However the 894 procedure is the same for the case an MN is a Tentry if it is 895 considered that the MN and the FA are the same node. 897 - When an MN moves into a new network attachment point, QoS- NSLP 898 in the MN initiates RESERVE (end-to-end) message to start the 899 State Update procedure. The GIST below the QoS-NSLP adds GIST 900 header and then sends the encapsulated RESERVE message to peer 901 GIST node with corresponding QoS-NSLP. In this case, the peer 902 GIST node is a FA if the FA is an NSIS-aware node. The FA is one 903 of the endpoints of Mobile IP tunneling: Tentry. For proper NSIS 904 tunneling operation, a Mobile IP endpoint is required to be NSIS 905 tunneling aware. In case of interaction with tunnel signaling 906 originated from the FA, there can be two scenarios depending on 907 whether the tunnel already has pre-configured QoS sessions or not. 908 In former case the FA map end-to-end QoS signaling requests 909 directly to existing tunnel sessions. In latter case the FA 910 dynamically initiate and maintain tunnel QoS sessions that are 911 then associated with the corresponding end-to-end QoS sessions. 912 [draft-ietf-nsis-tunnel]. 914 - Figure 5 shows the typical NSIS operation over tunnels with pre- 915 configured QoS sessions. Both the FA and the HA are configured 916 with information about the Flow ID of the tunnel QoS session. 917 Upon receiving a RESERVE message from the MN, the FA checks tunnel 918 QoS configuration, determines whether and how this end-to-end 919 session can be mapped to a pre-configured tunnel session. The FA 920 then tunnels the RESERVE message to the HA. The CN replies with a 921 RESPONSE message which arrives at the HA, the FA and the MN. 923 - Figure 6 shows the typical NSIS operation over tunnels with 924 dynamically created QoS sessions. When the FA receives an end-to- 925 end RESERVE message from the MN, the FA chooses the tunnel Flow 926 ID, creates the tunnel session and associates the end-to-end 927 session with the tunnel session. The FA then sends a tunnel 928 RESERVE' message matching the request of the end-to-end session 929 towards the HA to reserve tunnel resources. The tunnel RESERVE' 930 message is processed hop-by-hop inside the tunnel for the flow 931 identified by the chosen tunnel Flow ID, while the end-to-end 932 RESERVE message passes through the tunnel intermediate nodes 933 (Tmid). When these two messages arrive at the HA, the HA creates 934 the reservation state for the tunnel session, and sends a tunnel 935 RESPONSE' message to the FA. At the same time, the HA updates the 936 end-to-end RESERVE message based on the result of the tunnel 937 session reservation, and forwards the end-to-end RESERVE message 938 along the path towards the CN. When the CN receives the end-to- 939 end RESERVE message, it sends an end-to-end RESPONSE message back 940 to the MN. 942 More detailed operations are specifid in [draft-ietf-nsis-tunnel]. 944 MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver) 946 | | | | | 947 | RESERVE | | | | 948 +------------->| | | | 949 | | RESERVE | | 950 | +--------------------------->| | 951 | | | | RESERVE | 952 | | | +------------->| 953 | | | | RESPONSE | 954 | | | |<-------------+ 955 | | RESPONSE | | 956 | |<---------------------------+ | 957 | RESPONSE | | | | 958 |<-------------+ | | | 959 | | | | | 961 Figure 5: Sender-Initiated QoS-NSLP over Tunnel with Pre-configured 962 QoS Sessions 964 MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver) 966 | | | | | 967 | RESERVE | | | | 968 +------------->| | | | 969 | | RESERVE' | | | 970 | +=============>| | | 971 | | | RESERVE' | | 972 | | +=============>| | 973 | | RESERVE | | 974 | +---------------------------->| | 975 | | | RESPONSE' | | 976 | | |<=============+ | 977 | | RESPONSE' | | | 978 | |<=============+ | | 979 | | | | RESERVE | 980 | | | +------------->| 981 | | | | RESPONSE | 982 | | | |<-------------+ 983 | | RESPONSE | | 984 | |<----------------------------+ | 985 | RESPONSE | | | | 986 |<-------------+ | | | 987 | | | | | 989 Figure 6: Sender-Initiated QoS NSLP over Tunnel with Dynamically 990 Created QoS Sessions 992 5.3.2. Receiver-Initiated Reservation with Mobile IP tunnel 994 Figure 7 and Figure 8 show examples of receiver-initiated operation 995 over Mobile IP tunnel with pre-configured and dynamically created QoS 996 session, respectively. Basic Operation is the same as sender- 997 initiated case. 999 MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver) 1001 | | | | | 1002 | QUERY | | | | 1003 +------------->| | | | 1004 | | QUERY | | 1005 | +--------------------------->| | 1006 | | | | QUERY | 1007 | | | +------------->| 1008 | | | | RESERVE | 1009 | | | |<-------------+ 1010 | | RESERVE | | 1011 | |<---------------------------+ | 1012 | RESERVE | | | | 1013 |<-------------+ | | | 1014 | RESPONSE | | | | 1015 +------------->| | | | 1016 | | RESPONSE | | 1017 | +--------------------------->| | 1018 | | | | RESPONSE | 1019 | | | +------------->| 1020 | | | | | 1022 Figure 7: Receiver-Initiated QoS NSLP over Tunnel with Pre-Configured 1023 QoS Session 1025 MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver) 1027 | QUERY | | | | 1028 +------------->| | | | 1029 | | QUERY' | | | 1030 | +=============>| | | 1031 | | | QUERY' | | 1032 | | +=============>| | 1033 | | | RESPONSE' | | 1034 | | |<=============+ | 1035 | | RESPONSE' | | | 1036 | |<=============+ | | 1037 | | QUERY | | 1038 | +---------------------------->| | 1039 | | | | QUERY | 1040 | | | +------------->| 1041 | | | | RESERVE | 1042 | | | |<-------------+ 1043 | | | RESERVE' | | 1044 | | |<=============+ | 1045 | | RESERVE' | | | 1046 | |<=============+ | | 1047 | | RESERVE | | 1048 | |<----------------------------+ | 1049 | | RESPONSE' | | | 1050 | +=============>| | | 1051 | | | RESPONSE' | | 1052 | | +=============>| | 1053 | RESERVE | | | | 1054 |<-------------+ | | | 1055 | RESPONSE | | | | 1056 +------------->| | | | 1057 | | RESPONSE | | 1058 | +---------------------------->| | 1059 | | | | RESPONSE | 1060 | | | +------------->| 1061 | | | | | 1063 Figure 8: Receiver-Initiated QoS NSLP over Tunnel with Dynamically 1064 Created QoS Session 1066 5.3.3. CRN discovery and State Update with Mobile IP tunneling 1068 In case the tunnel is dynamically created mode, interaction with 1069 Mobile IP tunneling scenario can define two types of CRNs, i.e., a 1070 CRN on end-to-end path and a CRN on tunneling path while pre- 1071 configured mode only have the one on end-to-end. CRN discovery and 1072 State Update for these two paths are operated independently. 1074 CRN discovery for end-to-end path is initiated by the MN by sending 1075 RESERVE (sender-initiated case) or QUERY (receiver-initiated case) 1076 message. As MN uses HoA as source address even after handover, a CRN 1077 is found by normal route change process (i.e., the same SID and FID, 1078 but different SII handle). If a HA is QoS-NSLP aware, the HA is 1079 found as the CRN. The CRN initiate tearing process on the old path 1080 as described in [draft-ietf-nsis-qos-nslp] 1082 CRN discovery for tunneling path is initiated by Tentry by sending 1083 RESERVE' (sender-initiated case) or QUERY' (receiver-initiated case) 1084 message. The route change procedures described in Section 4 are 1085 applicable to this case. 1087 End-to-end state inside the tunnel should not be torn until all 1088 states inside the tunnel have been torn from imprementation 1089 perspective. But detailed discussions are out-of-scope of this 1090 document. 1092 6. Further Studies 1094 All sections above dealt with basic issues on NSIS mobility support. 1095 This section introduces potential issues and possible approaches for 1096 complicated scenarios in the mobile environment, i.e., peer failure 1097 scenarios, multihomed scenarios, and interworking with other mobility 1098 protocols, which may need to be resolved in the future. Topics in 1099 this section are out-of-scope of this document. Detailed operations 1100 in this section are just for future references. 1102 6.1. NSIS Operation in the multihomed mobile environment 1104 In multihomed mobile environments, multiple interfaces and addresses 1105 (i.e., CoAs and HoAs) are available. This case, two major issues can 1106 be considered. One is how to select or acquire the most appropriate 1107 interface(s) and/or address(es) from end-to-end QoS point of view. 1108 The other is, when multiple paths are simultaneously used for load- 1109 balancing purpose, how to differentiate and manage two types of CRNs, 1110 i.e., CRN between two on-going Paths (LB-CRN: Load Balancing CRN) and 1111 CRN between the old and new paths caused by MN's handover (HO-CRN: 1112 Handover CRN). This section introduces possible approaches for these 1113 issues. 1115 6.1.1. Selecting the best interface(s)/CoA(s) 1117 In MIPv6 route optimization case, if multiple CoAs registration is 1118 provided [RFC5648], the contents of QUERYs sent by candidate CoAs can 1119 be used to select the best interface(s)/CoA(s). 1121 Assume that an MN is a data sender and has multiple interfaces. Now 1122 the MN moves to a new location and acquires CoA(s) for multiple 1123 interfaces. After the MN performs the BU/BA procedure, it sends 1124 QUERY messages toward the CN through the interface(s) associated with 1125 the CoA(s). On receiving the QUERY messages, the CN or Gateway, 1126 determines the best (primary) CoA(s) by checking 'QoS available' 1127 field in the QUERY messages. Then a RESERVE message is sent toward 1128 the MN to reserve resources along the path the primary CoA takes. If 1129 the reservation is not successful, the CN transmits another RESERVE 1130 message using the CoA with the next highest priority. The CRN may 1131 initiate a teardown (RESERVE with the TEAR flag set) message toward 1132 old access router (OAR) to release the reserved resources on the old 1133 path. 1135 In case of sender-initiated reservation, a similar approach is 1136 possible. That is, the QUERY and RESERVE messages are initiated by 1137 an MN, and the MN selects the Primary CoA based on the information 1138 delivered by the QUERY message. 1140 |--Handover-->| 1141 MN OAR AR1 AR2 AR3 CRN CRN CRN CN 1142 (OAR/AR1)(OAR/AR2)(OAR/AR3) 1143 | | | | | | | | | 1144 |---QUERY(1)->|-------------------->|---------------------->| 1145 | | | | | | | | | 1146 |---QUERY(2)-------->|--------------------->|-------------->| 1147 | | | | | | | | | 1148 |---QUERY(3)--------------->|---------------------->|------>| 1149 | | | | | | | | | 1150 | | | | | | | | Primary CoA 1151 | | | | | | | | Selection(4) 1152 | | | | | | | | | 1153 | | | | | | |<--RESERVE(5)--| 1154 | | | |<------RESERVE(6)-----| (MRI | 1155 | | | | (Actual reservation) | Update) | 1156 |<----RESERVE(7)-----| | | | | | 1157 | | | | | | | | | 1158 | |<-----------teardown(8)-------------| | | 1159 | | | | | | | | | 1160 | | | | Multimedia Traffic | | | 1161 |<=================->|<===================->|<=============>| 1162 | | | | | | | | | 1164 Figure 9: Receiver-initiated reservation in the multihomed 1165 environment 1167 6.1.2. Differentiation of two types of CRNs 1169 When multiple interfaces of the MN are simultaneously used for load- 1170 balancing purpose, a possible approach for distinguishing LB-CRN and 1171 HO-CRN will introduce an identifier to determine the relationship 1172 between interfaces and paths. 1174 An MN uses interface 1 and interface 2 for the same session, where 1175 the paths (say path 1 and path 2) have the same SID but different 1176 FIDs as shown in (a) of Figure 10. Now one of the interfaces of MN 1177 performs a handover and obtains a new CoA, the MN will try to 1178 establish a new path (say Path 3) with the new FID, as shown in (b) 1179 of Figure 10. In this case the CRN between path 2 and path 3 cannot 1180 determine if it is LB-CRN or HO-CRN since for both cases, SID is the 1181 same but FIDs are different. Hence the CRN will not know if State 1182 Update is required. One possible solution to solve this issue will 1183 introduce path classification identifier which shows the relationship 1184 between interfaces and paths. For example, signaling messages and 1185 QNEs belong to paths from interface 1 and interface 2 carry the 1186 identifier '00' and '02', respectively. By having this identifier, 1187 the CRN between path 2 and path 3 will be able to determine whether 1188 it is LB-CRN or HO-CRN. For example, if path 3 carries '00', the CRN 1189 is LB-CRN, and if '01', the CRN is HO-CRN. 1191 +--+ Path 1 +---+ +--+ 1192 | |IF1 <-----------------|LB | common path | | 1193 |MN| |CRN|-------------|CN| 1194 | | Path 2 | | | | 1195 | |IF2 <-----------------| | | | 1196 | | +---+ +--+ 1197 | | 1198 +--+ 1199 (a) NSIS Path classification in multihomed environments 1201 +--+ Path 1 +---+ +--+ 1202 | |IF1 <-----------------|?? | common path | | 1203 |MN| |CRN|-------------|CN| 1204 | | Path 2 -| | | | 1205 | |IF2 <--- +------+ | | | | | 1206 | | \_|??-CRN|--v +---+ +--+ 1207 | | / +------+ 1208 +--+IF? <--- 1209 Path 3 1211 (b) NSIS Path classification after handover 1213 Figure 10: The topology for NSIS signaling in multihomed mobile 1214 environments 1216 6.2. Interworking with other mobility protocols 1218 Unlike the generic route changes, in mobility scenarios, the end-to- 1219 end signaling problem by the State Update gives rise to the 1220 degradation of network performance, e.g., increased signaling 1221 overhead, service blackout, and so on. To reduce signaling latency 1222 in the Mobile IP-based scenarios, the NSIS protocol suite may need to 1223 interwork with localized mobility management (LMM). If the GIST/NSLP 1224 (QoS-NSLP or NAT/FW-NSLP) protocols interact with Hierarchical Mobile 1225 IPv6 and the CRN is discovered between an MN and an MAP, the State 1226 Update can be localized by address mapping. However, how the State 1227 Update is performed with scoped signaling messages within the access 1228 network under the MAP is for future study. 1230 In the inter-domain handover, a possible way to mitigate the latency 1231 penalty is to use the multi-homed MN. It is also possible to allow 1232 the NSIS protocols to interact with mobility protocols such as 1233 Seamoby protocols (e.g., Candidate Access Router Discovery (CARD) 1234 [RFC4066] and Context Transfer Protocol (CXTP) [RFC4067]) and Fast 1235 Mobile IP (FMIP). Another scenario is to use peering agreement which 1236 allows aggregation authorization to be performed for aggregate 1237 reservation on an inter- domain link without authorizing each 1238 individual session. How these approaches can be used in NSIS 1239 signaling is for further study. 1241 6.3. Intermediate node becomes a dead peer 1243 The failure of a (potential) NSIS CRN may result in incomplete state 1244 re-establishment on the new path and incomplete teardown on the old 1245 path after handover. In this case, a new CRN should be re-discovered 1246 immediately by the CRN discovery procedure. 1248 The failure of an AR may make the interactions with Seamoby protocols 1249 (such as CARD and CXTP) impossible. In this case, the neighboring 1250 peer closest to the dead AR may need to interact with such protocols. 1251 A more detailed analysis of interactions with Seamoby protocols is 1252 left for future work. 1254 In Mobile IP-based scenarios, the failures of NSIS functions at an FA 1255 and an HA may result in incomplete interaction with IP-tunneling. In 1256 this case, recovery for NSIS functions needs to be performed 1257 immediately. In addtion, a more detailed analysis of interactions 1258 with IP-tunneling is left for future work. 1260 7. Security Considerations 1262 This document does not introduce new security concerns. The security 1263 considerations pertaining to the standard NSIS protocol 1264 specifications [gist, qos-nslp, natfw-nslp] remain relevant. When 1265 deployed in service provider networks, it is mandatory to ensure that 1266 only authorized entities are permitted to initiate re-establishment 1267 and removal of NSIS states in mobile environments, including the use 1268 of NSIS proxies and CRN. 1270 8. IANA Considerations 1272 This memo includes no request to IANA. 1274 9. Change History 1276 [Note to the RFC editor: Please remove this section before 1277 publication] 1279 9.1. Changes from -00 version 1281 The major change made to the initial (-00) version of the draft is to 1282 re-arrange the issues addressed in the draft in order to clearly 1283 identify general issues caused by mobility itself and NSIS protocols- 1284 specific issues. The generic route changes-related text in Section 4 1285 was moved into Appendix to make this draft more mobility-specific. 1287 Specifically, the following changes have been made: 1289 1. Removed the terminologies, 'uplink' and 'downlink' in Section 2. 1291 2. Removed the terminology, 'local repair' in Sections 2 and 4. 1293 3. Re-arranged all problems in Section 3 by merging the 'mobility- 1294 related issues with NSIS protocols' section and the 'problem 1295 statement and general considerations' section. 1297 4. Removed the general considerations section in Section 3. 1299 5. Modified the problem statement section and moved it into the 1300 general problem section in Section 3.1. 1302 6. Added more problems including 'Identification of the crossover 1303 node', 'Key exchanges', and 'AA-related Issues' to Section 3.1 1305 7. Added the 'Multihoming-related issues' to Section 3.2.4 1307 8. Removed the issues on 'how to immediately delete the state on 1308 the old path' in Section 3.2. 1310 9. Moved the generic route changes-related text in Section 4.1 into 1311 Appendix. 1313 10. Removed the figure describing "NSIS signaling topology for 1314 downstream signaling flow after the route changes in the middle 1315 of the network" in Figure 2. 1317 11. Added 'NSLP_IDs' to each node in Figure 1. 1319 12. Removed the 'use cases of identifiers' section, and instead, 1320 added the 'support for ping-pong type handover' section to 1321 Section5. 1323 13. Added this change history. 1325 9.2. Changes from -01 version 1327 Version -02 includes mainly a number of clarifications on the issues 1328 raised in this draft and more details in some specific areas. 1329 Specifically, the following changes have been made: 1331 1. Defined the terminologies, 'route change' and 'mobility' in 1332 Section 2. 1334 2. Clarified the terminology, 'Crossover node (CRN)' in Section 2. 1336 3. Removed the terminology, 'mobility CRN' in Section 2. 1338 4. The issue, 'Priority of signaling messages' in Section 3.2.2 was 1339 closed, and thus removed it. 1341 5. Clarified the issue, 'CRN discovery and State Update on the IP- 1342 tunneling path in Section 3.2.4. 1344 6. Added the pros and cons of two mechanisms on CRN discovery 1345 dependent on NSIS layers to Section 4.2.1. 1347 7. Clarified the identifier, NSLP_Br_ID for CRN discovery in 1348 Section 4.2.2. 1350 8. Added the scenario on interaction between NSIS and Mobile IP to 1351 Section 5.1. 1353 9. Clarified interaction issues with IP-tunneling according to 1354 reservation initiation type (receiver-initiated or sender- 1355 initiated) in Mobile IPv4-based scenarios and added those to 1356 Section 5.1.1.1. 1358 10. 1Clarified interaction issues between NSIS protocols and IP- 1359 tunneling in Mobile IPv6 and added those to Section 5.1.1.2. 1361 11. Clarified the multihoming-related issues in Section 5.2. 1363 12. Added the issues on usage of 'hint' information to trigger NSIS 1364 signaling in mobility to Section 5.5. 1366 13. Identified the dead peer-related issues in Mobile IP-based 1367 scenario in Section 5.5. 1369 9.3. Changes from -02 version 1371 In version -03, tunneling-related and multihoming-related scenarios 1372 were newly added in Sections 5.1.3 and 5.2, respectively. Also, the 1373 terminology, 'Path Update' is changed into 'State Update' in Section 1374 3.2.4. 1376 9.4. Changes from -03 version 1378 Version -04 includes mainly a number of clarifications on the issues 1379 raised in this draft and more details in some specific areas. 1380 Specifically, the following changes have been made: 1382 1. The issue, 'Peering agreement issue' in Section 3.2.2 was 1383 closed, and thus removed it. 1385 2. Clarified the issue, 'Interfaces between Mobile IP and NSIS 1386 protocols' in Section 3.2.1. 1388 3. Clarified the issue, 'Authorization-related issues with 1389 teardown' in Section 3.2.2. 1391 4. Clarified the issue, 'Dead peer discovery' in Section 3.2.2. 1393 5. Clarified the issue, 'Invalid NR problem' in Section 3.2.2. 1395 6. Clarified the issue, 'CRN discovery and State Update on the IP- 1396 tunneling path' in Section 3.2.4. 1398 7. Clarified the issue, 'Multihoming-related issues' in Section 1399 3.2.4. 1401 8. Changed Figure 1 (a) into (b) in Section 4.1. 1403 9. Changed Figure 1 (b) into (a) in Section 4.1. 1405 10. Clarified the identifier, NSLP_Br_ID for CRN discovery in 1406 Section 4.2.2. 1408 11. Clarified the identifier, Mobility identifier for CRN discovery 1409 in Section 4.2.2. 1411 12. Added the text on 'CRN_DISCOVERY flag bit' in Section 4.2.3, and 1412 clarified the role of 'CD flag bit' in Section 4.3.1. 1414 13. Clarified the issues on 'interaction with Mobile IP tunneling' 1415 and added those to Section 5.1.4. 1417 14. Clarified the issues on 'load balancing in multihomed mobile 1418 environments' and added those to Section 5.2.5. 1420 15. Changed Problems of the heading name in Section 3.2 into 1421 Challenges. 1423 9.5. Changes from -04 version 1425 Version -05 includes mainly a number of clarifications on the issues 1426 raised in this draft and more details in some specific areas. 1427 Specifically, the following changes have been made: 1429 1. 'Explicit routes' in Section 3.1 (3) was removed. 1431 2. Clarified the problem, 'Double reservation problem' in Section 1432 3.1 (7). 1434 3. Clarified the issue, 'CRN discovery-related issues' in Section 1435 3.2.4 (1). 1437 4. Clarified the issue, 'Issues on API between NTLP and NSLP' in 1438 Section 3.2.4 (3). 1440 5. Clarified the issue, 'approaches for CRN discovery' in Section 1441 4.2.1. 1443 6. Changed NSLP_Br_ID (of identifiers for CRN discovery) into 1444 State_Br_ID in Section 4.2.2 for clarification. 1446 7. Clarified the issue, 'double reservation problem on the common 1447 path' in Section 4.3.1. 1449 8. Clarified the issue, 'Interfaces between Mobile IP and NSIS' in 1450 Section 5.1.1. 1452 9. Removed the sencond paragraph on the issue, 'Explicit routes' in 1453 Section 4.1. 1455 10. Clarified the issue, 'refresh timer value in mobility scenarios' 1456 in Section 5.3. 1458 11. Removed the third paragraph on the issue, 'usage of Reservation 1459 Sequence Number (RSN) to support ping-pong type hanover' in 1460 Section 5.4. 1462 12. Clarified the issues on 'peer failure' in Section 5.5. 1464 13. Removed Figure 3 'Sender- vs. Receiver-initiated reservation' in 1465 Section 4.3.1. 1467 9.6. Changes from -05 version 1469 In Version -06, contents of this draft were re-selected and re- 1470 structured: 1472 1. Section 4 and 5 of -05 were divided into two parts: 1474 1. 'Main' part, which is focusing on examples and describing how 1475 mobility is handled by the NSIS protocols. Topics here will 1476 be route change handling and NSIS interwork with MIP v4/v6 1477 (Section 4 and Section 5 in -06) 1479 2. 'Further Study' part, which introduces summary of potential 1480 issues and possible approaches for other topics. These 1481 topics are out-of-scope for discussing details (Section 6 in 1482 -06) 1484 2. Specific parameters and terms were removed from 'Main' part 1486 3. Showing similar detailed operations were avoided in 'Interaction 1487 with MIP tunneling section (Section 5.3)' 1489 4. In Further Study section Section 6: 1491 1. Detailed operations were removed 1493 2. Ping-pong issue was removed 1495 5. Problem Statement (Section 3) was cleaned up 1497 9.7. Changes from -06 version 1499 Changes in Version -07 are: 1501 1. 'Invalid NR problem' are moved from Further Study section 1503 2. Figure 7 (Receiver-Initiated QoS NSLP over Tunnel -Parallel Mode) 1504 are changed 1506 3. Terminologies 'NSLP CRN', 'NTLP CRN' 'NSIS CRN' 'Divergent- 1507 convergent UCRN' and 'Divergent-convergent DCRN' are removed from 1508 Terminology section. 1510 4. 'Open Issues' section is added 1512 9.8. Changes from -07 version 1514 Changes in Version -08 are: 1516 1. Figure 1 was updated (NOTIFY message from CRN is added) 1518 2. Section 4.2.1 (CRN discovery) was updated to be synchronized with 1519 QoS-NSLP draft 1521 3. Title of Section 4.2.2 was changed from "State setup and update" 1522 to "Localized State Update" 1524 4. Section 4.2.2 (Localized State Update) was updated to be 1525 synchronized with QoS-NSLP draft 1527 5. Section 4.2.3 (State teardown) was deleted because the issues was 1528 already solved 1530 6. Title of Section 4.2.3 was changed to "State teardown 1531 consideration" 1533 9.9. Changes from -08 version 1535 Changes in Version -09 are: 1537 1. Security Consideration Section (Section 7) was cleaned up. 1539 2. Security Consideration issue was removed from Open Issue section 1540 (Section 8). 1542 3. NAT traversal issues were removed from Open Issue section 1543 (Section 8). 1545 9.10. Changes from -09 version 1547 Changes in Version -10 are: 1549 1. Introduction was updated accordingly. 1551 2. Definition of RFC2119 terms were removed from Section 2 1553 3. Definition of Upstream/Downstream State Update were cleaned up 1555 4. Title of Section 3 was changed from "Problem Statement" to 1556 "Challenges with Mobility" 1558 5. NSIS solutions are removed from Section 3 1559 6. Section 4 was cleaned up 1561 7. More detailed description was added to Section 5 1563 9.11. Changes from -10 version 1565 Change in Version -11 is: 1567 1. Introduction part of Section 5 was updated. 1569 9.12. Changes from -11 version 1571 Change in Version -12 are: 1573 1. Section 4.3 (NATFW section) was added. 1575 2. Open Issue section was closed. 1577 9.13. Changes from -12 version 1579 Changes in Version -13 are: 1581 1. "Upstream signaling" was added to Section 3 1583 2. Three more cases were discussed in Section 4.2 1585 3. Definition of Upstream/Downstream State Update were cleaned up 1587 4. Figure 3 was removed because it was't really necessary for the 1588 discussion. 1590 9.14. Changes from -13 version 1592 Change in Version -14 is: 1594 1. Figure 3 was re-added with appropriate changes. 1596 9.15. Changes from -14 version 1598 Change in Version -15 is: 1600 1. Title was changed because this draft is not talking about AS. 1602 9.16. Changes from -15 version 1604 Changes in Version -16 are: 1606 1. RFC2205, RFC3726, RFC3753 and draft-ietf-nsis-tunnel were changed 1607 from Normative references to Informative references. 1609 2. IANA Consideration was added. 1611 3. RFC4066 and RFC4067 was added to Informative References. 1613 9.17. Changes from -16 version 1615 Changes in Version -17 is: 1617 1. Some editorial changes were made. 1619 9.18. Changes from -17 version 1621 Changes in Version -18 is: 1623 1. Some editorial changes were made. 1625 9.19. Changes from -18 version 1627 Changes in Version -19 are: 1629 1. Abstract and Introduction were changed to clearly say the NSIS 1630 protocols operations can work in mobility environments without 1631 particular operations, and additional operations such as CRN 1632 discovery are only for enhancement and informational. 1634 2. Some texts were added to section 4 to say the state in old path 1635 can be torn by timer. 1637 3. Consideration in tearing down end-to-end tunneling state was 1638 mentioned in section 5. 1640 4. Authorization for CRN was briefly mentioned in security 1641 consideration. 1643 5. Some editorial changes were made. 1645 10. Contributors 1647 Sung-Hyuck Lee was the first editor of the draft. Since version 06 1648 of the draft, Takako Sanda has taken the editorship. 1650 Many individuals have contributed to this draft. Since it was not 1651 possible to list them all in the authors section, this section was 1652 created to have a sincere respect for other authors, Paulo Mendes, 1653 Robert Hancock, Roland Bless, Shivanajay Marwaha and Martin 1654 Stiemerling. Separating authors into two groups was done without 1655 treating any one of them better (or worse) than others. 1657 11. Acknowledgements 1659 The authors would like to thank Byoung-Joon Lee, Charles Q. Shen, 1660 Cornelia Kappler, Henning Schulzrinne, and Jongho Bang for 1661 significant contributions in four earlier drafts and the previous 1662 draft. The authors would also like to thank Robert Hancock, Andrew 1663 Mcdonald, John Loughney, Rudiger Geib, Cheng Hong, Elena Scialpi, 1664 Pratic Bose, Martin Stiemerling and Luis Cordeiro for their useful 1665 comments and suggestions. 1667 12. References 1669 12.1. Normative Reference 1671 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC3344 , 1672 August 2002. 1674 [RFC3775] Johnson, D., "Mobility Support in IPv6", RFC3775 , 1675 June 2004. 1677 [draft-ietf-nsis-nslp-natfw] 1678 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 1679 Protocol (NSLP)", Internet 1680 Draft draft-ietf-nsis-nslp-natfw-25, Work in progress , 1681 April 2010. 1683 [draft-ietf-nsis-ntlp] 1684 Schulzrinne, H., "GIST: General Internet Signaling 1685 Transport", Internet Draft draft-ietf-nsis-ntlp-20, Work 1686 in progress , June 2009. 1688 [draft-ietf-nsis-qos-nslp] 1689 Manner, J., "NSLP for Quality-of-Service Signaling", 1690 Internet Draft draft-ietf-nsis-qos-nslp-18, Work in 1691 progress , January 2010. 1693 12.2. Informative References 1695 [RFC2205] Braden, B., "Resource ReSerVation Protocol (RSVP) -- 1696 Version 1 Functional Specification", RFC2205 , 1697 September 1997. 1699 [RFC3726] Brunner, (Ed), M., "Requirements for Signaling Protocols", 1700 RFC3726 , June 2004. 1702 [RFC3753] Manner, J., "Mobility Related Terminology", RFC3753 , 1703 June 2004. 1705 [RFC4066] Liebsch, M., "Candidate Access Router Discovery (CARD)", 1706 RFC4066 , July 2005. 1708 [RFC4067] Loughney, J., "Context Transfer Protocol (CXTP)", 1709 RFC4067 , July 2005. 1711 [RFC5648] Wakikawa, R., "Multiple Care-of-Address Registration", 1712 RFC5648 , October 2009. 1714 [draft-ietf-nsis-tunnel] 1715 Shen, C., "NSIS Operation Over IP Tunnels", Internet 1716 Draft draft-ietf-nsis-tunnel-10, Work in Progress , 1717 April 2010. 1719 Authors' Addresses 1721 Takako Sanda 1722 Panasonic Corporation 1723 600 Saedo-cho, Tsuzuki-ku, Yokohama 1724 Kanagawa 224-8539 1725 Japan 1727 Phone: +81 45 938 3056 1728 Email: sanda.takako@jp.panasonic.com 1730 Xiaoming Fu 1731 Computer Networks Group, University of Goettingen 1732 Lotzestr. 16-18 1733 Goettingen 37083 1734 Germany 1736 Email: fu@cs.uni-goettingen.de 1738 Seong-Ho Jeong 1739 Hankuk University of FS 1740 89 Wangsan Mohyun 1741 Yongin-si, Gyeonggi-do 449-791 1742 Korea 1744 Phone: +82 31 330 4642 1745 Email: shjeong@hufs.ac.kr 1747 Jukka Manner 1748 Helsinki University of Technology 1749 P.O. Box 3000 1750 Espoo FIN-02015 1751 Finland 1753 Phone: +358 9 451 2481 1754 Email: jukka.manner@tkk.fi 1755 Hannes Tschofenig 1756 Nokia Siemens Networks 1757 Linnoitustie 6 1758 Espoo 1759 02600 1760 Finland 1762 Phone: +358 50 4871445 1763 Email: Hannes.Tschofenig@nsn.com