idnits 2.17.00 (12 Aug 2021) /tmp/idnits21633/draft-sanda-nsis-mobility-qos-proxy-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 == Line 67 has weird spacing: '...g place in th...' == 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 (February 2004) is 6670 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) -- Missing reference section? '1' on line 13 looks like a reference -- Missing reference section? '2' on line 45 looks like a reference -- Missing reference section? '3' on line 115 looks like a reference -- Missing reference section? '5' on line 129 looks like a reference -- Missing reference section? '6' on line 422 looks like a reference -- Missing reference section? '8' on line 97 looks like a reference -- Missing reference section? '13' on line 102 looks like a reference -- Missing reference section? '12' on line 158 looks like a reference -- Missing reference section? '7' on line 416 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Sanda 2 Internet Draft T. Ue 3 Expires: August 2004 Panasonic 4 February 2004 6 Pre CRN discovery from proxy on candidate new path 7 draft-sanda-nsis-mobility-qos-proxy-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026 [1]. 14 Internet-Drafts are working documents of the Internet 15 Engineering Task Force (IETF), its areas, and its working groups. 16 Note that other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as "work 23 in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 NSIS WG has been discussing the ways to minimize/avoid QoS 33 interruption during handover. One solution is to install new 34 path before MN's move (fast state installation). 35 This document proposes a procedure of pre CRN discovery for fast 36 state installation by using proxies on candidate new paths. An 37 example of fast state installation is shown. 39 Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 42 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 43 "OPTIONAL" in this document are to be interpreted as described 44 in RFC-2119 [2]. 46 Table of Contents 48 1. Introduction................................................2 49 1.1 Terminology.............................................2 50 1.2 Assumption..............................................3 51 2. Proxy for Fast State Installation...........................3 52 3. Proxy discovery.............................................3 53 4. Pre CRN Discovery...........................................4 54 5. New path installation.......................................7 55 5.1 Fast state installation for downlink data flow..........7 56 5.2 Fast state installation for uplink data flow............8 57 6. Signaling messages for fast CRN discovery...................9 58 7. Security Considerations....................................10 59 References....................................................10 60 Author's Addresses............................................11 62 1. Introduction 64 When a MN performs L3 level handover with a QoS state, it is 65 required to establish new QoS paths before handover to 66 avoid/minimize QoS interruption in new subnetwork. Discussions 67 on this topic are taking place in the NSIS WG and some drafts 68 are proposing "Fast State Installation", by which new QoS paths 69 are established in advance [3][5][6][8]. 71 The goal of this draft is to initiate discussion on concrete 72 solutions for Fast State Installation. An example is provided of 73 a procedure that includes crossover node (CRN) discovery. This 74 procedure utilizes a proxy entity on the candidate new path, to 75 perform CRN discovery and QoS state installation along the new 76 path prior to the MN's move to the new subnetwork. 78 Terminology definitions and assumptions in this document are 79 described in the following section. 81 1.1 Terminology 83 Uplink data flow: 84 data flow from MN to CN 86 Downlink data flow: 87 data flow from CN to MN 89 UCRN and DCRN: 90 The same as defined in [6] 92 mQNE: 93 The NSIS aware node supporting QoS and mobility 94 functionalities 95 1.2 Assumption 97 o Signaling messages are path-coupled [8]. Signaling messages 98 from MN to CN are routed only through NEs that are in the Uplink 99 data path, and signaling messages from CN to MN are routed only 100 through NEs that are in the Downlink data path 102 o Network supports Mobile IPv6 [13] 104 o Only optimized route case is discussed in this document 105 although several routes are possible such as triangle route, 106 tunnel between OAR and NAR established by FMIP, and so on. 108 o MN and CN are mQNE 110 2. Proxy for Fast State Installation 112 MN cannot directly initiate resource reservation signaling on 113 candidate new paths before it actually moves. Therefore NSIS 114 proxy utilization will be necessary for fast state installation, 115 as described in [3]. 117 The proxy can be used for preparing new path installation, e.g. 118 discovering CRN in advance of the MN's move(pre CRN discovery). 119 Additionally the proxy may install the new path on behalf of the 120 MN. 122 The following section describes a procedure for pre CRN 123 discovery followed by fast state installation. 125 3. Proxy discovery 127 Either old (current) or candidate new adjacent mQNEs of MN (see 128 Figure1) can act as a proxy. 129 An example of the former case is described in an appendix of [5]. 130 Here we aim to consider the latter case, i.e. new adjacent mQNE 131 acts as a proxy and prepares new path creation. 133 If candidate NAR(s) has mQNE functionalities, the NAR(s) acts as 134 a proxy. 136 new 137 adjacent 138 mQNE 139 +..+ +---+ +----+ 140 .MN.---|NAR|---|mQNE|---...-------- 141 +..+ +---+ +----+ | 142 ^ | 143 | | 144 +--+ +---+ +-+ +----+ +----+ +--+ 145 |MN|===|OAR|==|R|==|mQNE|==...==|mQNE|==...==|CN| 146 +--+ +---+ +-+ +----+ +----+ +--+ 147 old (current) 148 adjacent 149 mQNE 151 === current path 152 --- expected new path 153 R: Router or NE (not QNE) 155 Figure1: New and old adjacent mQNE 157 If MN and network support suitable mobility protocol, such as 158 CARD [12], MN can obtain proxies information through the CARD 159 server. 161 When the network does not support CARD, the MN may have to rely 162 on pre-stored information. This information could be in the form 163 of tables contains mapping information between APs and their 164 connecting ARs, and neighboring mQNEs (proxies) of the ARs. The 165 MN would then be able to associate the information on candidate 166 APs to mQNEs that will likely be on the new path and would be 167 able to act as proxies. Given though that determining whether an 168 mQNE router will be on a data path to an arbitrary CN is 169 difficult, it is proposed that only access routers with mQNE 170 capabilities are used as proxies as described in [6]. This has 171 the added advantage that these routers will be able to perform 172 DAD on prospective new CoAs which would enable them to also 173 perform the state installation on behalf of the MN. 175 4. Pre CRN Discovery 177 The idea of pre CRN (both UCRN and DCRN) discovery is as follows. 179 a. After determining proxies, MN sends PROXY_INIT message to 180 the proxies. The PROXY_INIT message is a NSLP signaling 181 message and contains current flow identifier and session 182 identifier (for both uplink and downlink, or either) 183 information. 185 b. On receipt of PROXY_INIT message, each proxy sends a 186 DCRN_DISCOVERY message to CN. A DCRN_DISCOVERY is NSLP 187 signaling message and containing the flow identifier and 188 session identifier received from the MN. An IP address of CN is 189 contained in flow identifier. 191 c. Each QNE belonging to the signaling path from proxy to CN 192 intercepts DCRN_DISCOVERY, and checks if any interface has 193 resource reservation for the pair of flow identifier and 194 session identifier for uplink. If one of interface has the 195 reservation, the QNE appends IP address of the interface to 196 DCRN_DISCOVERY. 197 When DCRN_DISCOVERY message arrives to CN, DCRN_DISCOVERY 198 message contains the information of all overlapping interfaces 199 belonging to current uplink QoS path (from MN to CN) and 200 expected new uplink path (from proxy to CN) in order. 202 current path 203 =======================> 204 IF1 IF2 205 +--+ +----+ +----+ +----+ +----+ +--+ 206 |MN|>>>>|mQNE|>>>|mQNE|>>>|mQNE|>>>|mQNE|>>>>|CN| 207 +--+ +----+ +----+ >+----+>>>+----+>>>>+--+ 208 ^ 209 ^ -----> 210 ^ | 211 +-----+ +----+ ^ | 212 |Proxy|>>>>>|mQNE|>>>> | 213 +-----+ +----+ | 214 | 215 ------------------- 216 DCRN_DISCOVERY 217 IF=Interface to be appended 218 to the message 220 Figure2: Interfaces' information collected by DCRN_DISCOVERY 222 d. On receipt of DCRN_DISCOVERY message, CN sends a 223 UCRN_DISCOVERY to the proxy. A UCRN_DISCOVERY message is NSLP 224 signaling message and containing the flow identifier and 225 session identifier received from MN via DCRN_DISCOVERY message. 226 A UCRN_DISCOVERY message also contains the information of IP 227 addresses appended to DCRN_DISCOVERY message. 229 e. Each QNE belonging to the signaling path from CN to proxy 230 intercepts UCRN_DISCOVERY, and checks if any interface has 231 resource reservation for the pair of flow identifier and 232 session identifier for downlink. If one of interface has the 233 reservation, the QNE appends IP address of the interface to 234 UCRN_DISCOVERY. 236 When UCRN_DISCOVERY message arrives to proxy, UCRN_DISCOVERY 237 message contains the information of all overlapping interfaces 238 belonging to current uplink QoS path (from MN to CN) and 239 expected new downlink path (from proxy to CN) in order. 241 current path 242 <======================= 243 IF4 IF3 244 +--+ +----+ +----+ +----+ +----+ +--+ 245 |MN|<<<<|mQNE|<<<|mQNE|<<<|mQNE|<<<|mQNE|<<<<|CN| 246 +--+ +----+ +----+ <+----+<<<+----+<<<<+--+ 247 v 248 v ------ 249 v | 250 +-----+ +----+ v | 251 |Proxy|<<<<<|mQNE|<<<< | 252 +-----+ +----+ | 253 | 254 <------------------ 255 UCRN_DISCOVERY 256 IF=Interface to be appended 257 to the message 259 Figure3: Interfaces' information collected by UCRN_DISCOVERY 261 f. The proxy receiving UCRN_DISCOVERY from CN checks appended 262 information in UCRN_DISCOVERY and decides CRN(s). The first 263 interface IP address appended to DCRN_DISCOVERY (and set into 264 UCRN_DISCOVERY) is DCRN, and the last interface IP address 265 appended to UCRN_DISCOVERY is UCRN. 267 collected by collected by 268 DCRN_DISCOVERY UCRN_DISCOVERY 269 <===============> <===============> 271 +------+--------+--------+------+--------+--------+ 272 |up- |IP addr.|IP addr.|down- |IP addr.|IP addr.| 273 |stream| of IF1 | of IF2 |stream| of IF1 | of IF2 | 274 +------+--------+--------+------+--------+--------+ 276 ^ ^ 277 | | 278 DCRN UCRN 280 Figure4: collected information and DCRN/UCRN 281 The proxy sends PROXY_INIT_ACK message to the MN. PROXY_INIT_ACK 282 message is NSLP message and used for informing whether pre CRN 283 discovery is successfully done or failed. 285 5. New path installation 287 DCRN/UCRN discovered by proxy can be used for fast state 288 installation. For this purpose, it is required that RESERVE 289 message contains IP addresses of DCRN/UCRN. When the RESERVE 290 message reaches the DCRN, it is also required for the DCRN to 291 translate the RESERVE (create) message into RESERVE (update) 292 message and vice versa for UCRN in order to avoid duplicate 293 reservation of common QoS path (CN-UCRN/DCRN). 295 This section describes an example of fast state installation. 297 5.1 Fast state installation for downlink data flow 299 The following scenario assumes that the data flow is downlink 300 only. 302 a. When the MN listens to neighboring AP's beacons, MN refers a 303 proxy table (see Chapter 3). This table has mapping information 304 between APs and their connecting ARs, and whether the ARs have 305 mQNE functionalities. MN selects target subnetwork of which AR 306 has mQNE (proxy) functionalities. 308 b. MN configures NCoA from the AR's information in the table, 309 i.e. AR's IP address and prefix length. 311 c. MN sends PROXY_INIT message with NCoA to the new AR (NAR). 312 This PROXY_INIT message may contain IP address of MN's old 313 (current) mQNE as well. 315 d. The NAR executes DAD for NCoA. 317 e. Simultaneously with d., the NAR performs pre CRN discovery 318 as described in Chapter 4 and discovers UCRN. 320 f. If the NCoA is valid, the NAR send RESERVE message with UCRN 321 to CN. QSpec information may be obtained form mQNE in old 322 (current) path such as MN or old adjacent mQNE of MN. 324 MN NAR CN 325 (Proxy) 326 | | | 327 +--------+ | | 328 |HO | | | 329 |Decision| | | 330 +--------+ | | 331 +-------------+ | | 332 |NCoA | | | 333 |Configuration| | | 334 +-------------+ | | 335 | | | 336 |PROXY_INIT | | 337 |------------------->| | 338 | | | 339 | +-------+ | 340 | |DAD for| | 341 | |NCoA | | 342 | +-------+ | 343 | | | 344 | |DCRN_DISCOVERY | 345 | |------------------->| 346 | | | 347 | | UCRN_DISCOVERY| 348 | |<-------------------| 349 | | | 350 | +---------+ | 351 | |Obtaining| | 352 | |UCRN | | 353 | +---------+ | 354 | | | 355 | |RESERVE | 356 | |------------------->| 357 | | | 358 | | | 360 Figure5: An example of Fast state installation for downlink 362 5.2 Fast state installation for uplink data flow 364 If data flow is uplink only or duplicate, the following 365 procedure can be used in addition to downlink case. 367 o DCRN_DISCOVERY message contains NCoA (which is valid). 369 o The CN receiving DCRN_DISCOVERY message performs RESERVE 370 message to NAR (proxy) for uplink, as it can obtain DCRN and 371 MN's NCoA. 373 MN NAR CN 374 (Proxy) 375 | | | 376 +--------+ | | 377 |HO | | | 378 |Decision| | | 379 +--------+ | | 380 +-------------+ | | 381 |NCoA | | | 382 |Configuration| | | 383 +-------------+ | | 384 | | | 385 |PROXY_INIT | | 386 |------------------->| | 387 | | | 388 | +-------+ | 389 | |DAD for| | 390 | |NCoA | | 391 | +-------+ | 392 | | | 393 | |DCRN_DISCOVERY | 394 | |------------------->| 395 | | | 396 | | +---------+ 397 | | |Obtaining| 398 | | |DCRN and | 399 | | |NCoA | 400 | | +---------+ 401 | | | 402 | | RESERVE| 403 | |<-------------------| 404 | | | 405 | | UCRN_DISCOVERY| 406 | |<-------------------| 407 | | | 408 | | | 410 Figure6: An example of Fast state installation for uplink 412 6. Signaling messages for fast CRN discovery 414 PROXY_INIT, DCRN_DISCOVERY, UCRN_DISCOVERY and PROXY_INIT_ACK 415 may be extended existing QoS NSLP message, such as QUERY, 416 RESPONSE and NOTIFY [7]. If DCRN_DISCOVERY and UCRN_DISCOVERY 417 are QUERY and RESPONSE respectively, proxy can obtain downlink 418 path information simultaneously with UCRN discovery. 420 7. Security Considerations 422 Security issues are addressed in section 12 of [6] but they are 423 not covering candidate proxies (mQNEs) which are described in 424 this document. Proper security handling must be provided in 425 candidate proxy discovery. It is also required to consider the 426 issues caused by sending PROXY_INIT which includes session and 427 flow identifiers from MN to candidate proxies, such as 428 session/reservation ownership. 430 Future draft will include these issues. 432 References 434 1. Bradner, S., "The Internet Standards Process -- Revision 3", 435 BCP 9, RFC 2026, October 1996. 437 2. Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, March 1997 440 3 X. Fu, et al., "Mobility Issues in Next Steps in Signaling 441 (NSIS)", Internet Draft (work in progress), 442 draft-fu-nsis-mobility-01.txt, October 2003 444 4 H. Chaskar, et al., "Requirements of a Quality of Service 445 (QoS) Solution for Mobile IP", RFC3583, September 2003 447 5 S. Lee, et al., "Mobility Functions in the QoS-NSLP", 448 Internet Draft (work in progress), draft-lee-nsis-mobility-nslp- 449 01.txt, October 2003 451 6 Roland Bless, et al., "Mobility and Internet Signaling 452 Protocols", Internet Draft (work in progress), draft-manyfolks- 453 signaling-protocol-mobility-00.txt, January 2004 455 7 Sven Van den Bosch (Editor), "NSLP for Quality-of-Service 456 signaling", Internet Draft (work in progress), draft-ietf-nsis- 457 qos-nslp-01.txt, October 2003 459 8 Robert Hancock et al., "Next Step in Signaling: Framework", 460 Internet Draft (work in progress), draft-ietf-nsis-fw-05.txt, 461 October 2003 463 9 R. Hancock, et al., "Interactions of Routing and Mobility on 464 NTLP and NSLP", Internet Draft (work in progress), draft- 465 hancock-nsis-routing-mobility-00.txt, October, 2003 467 10 S. Jeong, et al., "Mobility Functions in the NTLP", Internet 468 Draft (work in progress), draft-jeong-nsis-mobility-ntlp-01.txt, 469 October 2003 470 11 H. Schulzrinne, et al., "GIMPS: General Internet Messaging 471 Protocol for Signaling", Internet Draft (Work in progress), 472 draft-ietf-nsis-ntlp-00, October 2003 474 12 M. Liebsch, et al., "Candidate Access Router Discovery", 475 Internet Draft (work in progress), draft-ietf-seamoby-card- 476 protocol-06.txt, December 2003 478 13 D.Johnson, C. Perkins and J. Arkko, "Mobility Support in 479 IPv6", Internet Draft (work in progress), draft-ietf-mobileip- 480 ipv6-24.txt, June 2003 482 Author's Addresses 484 Takako Sanda 485 Panasonic (Matsushita Electric Industrial Co., Ltd.) 486 5-3, Hikarino-oka, Yokosuka City, Kanagawa 239-0847, Japan 487 Phone: (+81) 46 840 5764 488 Email: sanda.takako@jp.panasonic.com 490 Toyoki Ue 491 Panasonic (Matsushita Electric Industrial Co., Ltd.) 492 5-3, Hikarino-oka, Yokosuka City, Kanagawa 239-0847, Japan 493 Phone: (+81) 46 840 5816 494 Email: ue.toyoki@jp.panasonic.com 496 Full Copyright Statement 498 Copyright (C) The Internet Society (2003). All Rights Reserved. 500 This document and translations of it may be copied and furnished 501 to others, and derivative works that comment on or otherwise 502 explain it or assist in its implementation may be prepared, 503 copied, published and distributed, in whole or in part, without 504 restriction of any kind, provided that the above copyright 505 notice and this paragraph are included on all such copies and 506 derivative works. However, this document itself may not be 507 modified in any way, such as by removing the copyright notice or 508 references to the Internet Society or other Internet 509 organizations, except as needed for the purpose of developing 510 Internet standards in which case the procedures for copyrights 511 defined in the Internet Standards process must be followed, or 512 as required to translate it into languages other than English. 514 The limited permissions granted above are perpetual and will not 515 be revoked by the Internet Society or its successors or assigns. 517 This document and the information contained herein is provided 518 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 519 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 520 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 521 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 522 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 523 PARTICULAR PURPOSE.