idnits 2.17.00 (12 Aug 2021) /tmp/idnits41411/draft-bernardos-mext-aero-nemo-ro-sol-analysis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 734. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 740. 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 Copyright Line does not match the current year -- 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 (November 3, 2008) is 4940 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-mext-aero-reqs has been published as RFC 5522 == Outdated reference: A later version (-02) exists of draft-ietf-mext-nemo-ro-automotive-req-01 == Outdated reference: A later version (-01) exists of draft-thubert-mext-global-haha-00 == Outdated reference: A later version (-01) exists of draft-bauer-mext-aero-topology-00 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group C. Bernardos 3 Internet-Draft M. Bagnulo 4 Intended status: Informational UC3M 5 Expires: May 7, 2009 November 3, 2008 7 Analysis on how to address NEMO RO for Aeronautics Mobile Networks 8 draft-bernardos-mext-aero-nemo-ro-sol-analysis-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 7, 2009. 35 Abstract 37 The Network Mobility Basic Support protocol enables networks to roam 38 and attach to different access networks without disrupting the 39 ongoing sessions that nodes of the mobile network may have. By 40 extending the Mobile IPv6 support to Mobile Routers, nodes of the 41 mobile network are not required to support any kind of mobility, 42 since packets go through the Mobile Router-Home Agent (MRHA) bi- 43 directional tunnel. Data packets belonging to communications of 44 nodes of the mobile network have to traverse the Home Agent, and 45 therefore resulting paths are likely to be suboptimal. Additionally, 46 the solution adds packet overhead, due to the use of encapsulation 47 between the Mobile Router and the Home Agent. 49 There are currently a set of well defined NEMO Route Optimization 50 requirements for Operational Use in Aeronautics and Space 51 Exploration, which potential solutions should meet. This document 52 analyses how the problem of NEMO RO for Aeronautics Mobile Networks 53 might be tackled, in a way as generic as possible, trying to identify 54 those open questions and deployment considerations that need to be 55 addressed. 57 The main goal of this document is to foster the discussion about 58 aeronautics NEMO RO solution space within the MEXT WG. 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [1]. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Solution Space analysis . . . . . . . . . . . . . . . . . . . 4 70 3. Design issues/questions/trade-offs . . . . . . . . . . . . . . 8 71 3.1. Where are the RO entities located? . . . . . . . . . . . . 9 72 3.2. Who administratively manages the RO entities? . . . . . . 10 73 3.3. Which kind of addresses are gonna be used and who own 74 them? . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 3.4. How many RO entities are needed to globally perform 76 NEMO RO? . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 3.5. What trust relationships are needed? . . . . . . . . . . . 12 78 3.6. Is the solution flexible enough to allow the 79 participation of the end-nodes (CNs and/or MNNs)? . . . . 13 80 3.7. Does the solution allow for a hierarchical scheme? . . . . 13 81 3.8. What is the target protocol complexity? . . . . . . . . . 14 82 3.9. How is routing performed within the ATN? . . . . . . . . . 14 83 3.10. Does the solution allow for implementing 84 legal/political/economical requirements? . . . . . . . . . 14 85 3.11. What is the robustness of the solution (i.e. what type 86 of failure affects to the reachability)? . . . . . . . . . 15 87 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 92 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 93 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 95 Intellectual Property and Copyright Statements . . . . . . . . . . 18 97 1. Introduction 99 This document assumes that the reader is familiar with the 100 terminology related to Network Mobility [4] and [5], and with the 101 Mobile IPv6 [2] and NEMO Basic Support [3] protocols. 103 The MEXT WG is currently chartered to work on three use cases for 104 route optimization of network mobility, namely aeronautics [6], 105 vehicular [7] and consumer electronics [8]. The work on the 106 requirements for the aeronautics use case seems to be mature enough 107 at this point to start discussing about solutions. This document is 108 an initial attempt aimed at fostering discussion on solutions, by 109 presenting a general framework of how a solution for the aeronautics 110 use case could look like, and identifying and highlighting relevant 111 questions, issues and deployment models that need to be taken care of 112 during the solution definition process. 114 The requirements for the aeronautics use case [6] differentiate among 115 three different domains of interest: Air Traffic Services (ATS), Air 116 Operational Services (AOS) and Passenger Information and 117 Entertainment Services (PIES). Besides, two kind of requirements are 118 identified: required (minimal properties that a solution must 119 possess) and desirable (difficult to quantify or not immediately 120 needed requirements) characteristics. Since the PIES domain is not 121 critical to safety-of-life, but mostly involves added comfort and 122 business services to passengers, this domain has not been taken into 123 account as input for the required characteristics. 125 Due to the very different nature of the required and desirable 126 characteristics, and the importance of the former ones, this document 127 only analyzes how a solution for ATS/AOS would look like. 129 2. Solution Space analysis 131 In this section we try to outline the general lines of a NEMO Route 132 Optimization solution for the aeronautics use case (ATS/AOS domains), 133 based on the set of requirements described in [6], which we summarize 134 next: 135 o Separability: an RO solution MUST support configuration by using a 136 dynamic RO policy database, so RO for certain flows can be 137 disabled/enabled. A granularity level similar to the one of IPsec 138 security policy databases is expected to be supported. 139 o Multihoming: an RO solution MUST support multi-interfaced MRs, and 140 it MUST allow the use of different interfaces (and also different 141 MNPs) for different domains. 143 o Latency: an RO solution MUST allow packets to use the MRHA tunnel 144 while setting up or reconfiguring the RO path. 145 o Availability: an RO solution MUST NOT prevent to fall-back using 146 the default MRHA tunnel if the RO path fails for whatever reason. 147 This basically also means that an RO solution MUST NOT introduce 148 any new single point of failure for the communications. 149 o Packet Loss: an RO solution SHOULD NOT cause either additional 150 loss or duplication of data packets due to the use of RO, above 151 that caused in the NEMO basic default solution. 152 o Scalability: an RO solution MUST be simultaneously usable by 153 hundreds of thousands of crafts without overloading the ground 154 network or the routing system. 155 o Efficient Signaling: an RO solution MUST be efficient in terms of 156 the number of required signaling messages, and avoid signaling 157 storms as a result of providing multiple ongoing flows with RO 158 following a handover. 159 o Security: an RO solution MUST NOT expose MNPs on the wireless 160 egress link, MUST allow the receiver of BUs to validate CoA 161 ownership, and MUST ensure that only explicitly authorized MRNs 162 are able to send a BU for a specific MNP. 163 o Adaptability: an RO solution MUST NOT prevent applications from 164 using transport protocols, IPsec or new IP options. 165 o Although it is not explicitly listed as a required characteristic 166 -- but only suggested in [6] --, it seems to be widely accepted 167 that modifications to CNs MUST NOT be required by an RO solution. 169 From this list of requirements, a first conclusion that can be 170 obtained is that a solution for the aeronautics NEMO RO use case MUST 171 NOT require changes on the CNs in order to correctly operate, that 172 is, a solution MUST provide certain level of RO with legacy IPv6 CNs. 173 This means that the solution would likely rely on a set of entities 174 at the infrastructure, performing the RO function between them or/and 175 also the MR. 177 In a glimpse, a solution along the lines mentioned before would 178 operate as follows (Figure 1): an optimized route between a mobile 179 network deployed in a craft and a CN (or set of CNs) is set-up (upon 180 some sort of trigger/policy) between two (or more in general terms) 181 NEMO RO entities (NROEs). These RO entities should be located -- in 182 order to provide an optimized route as shorter as possible -- close 183 to the mobile network and/or the CN. It should be noted that one of 184 these RO entities may be collocated within the MR. A tunnel between 185 the RO entities (or a chain/nesting of tunnels, in case several RO 186 entities are involved in the same optimized route) is established, so 187 data traffic between the mobile network and the CN (or set of CNs) 188 can be routed through this shorter route (compared with the default 189 MRHA one). It might be the case that certain additional operations 190 are needed in order to ensure that traffic sent/received by the CN 191 (or by the mobile network) is routed through the RO entities, so they 192 can forward packets using the optimized route. Involving more than 193 two RO entities might be useful in order to deploy hierarchical 194 schemes (i.e. a chain of RO entities is set up along the path between 195 the MR and the CN), in which the MR would only need to update/ 196 exchange signaling with the closest RO entity, but not with all the 197 RO entities involved ih the optimization. This may improve the 198 handover performance for the optimized flows and reduce the signaling 199 load. 201 --------- 202 | HA_MR | 203 --------- 204 | 205 | 206 (-*-*-*-*+*-*-*-*-) 207 -*- -*- 208 ( ) 209 -*- ATN -*- ------ 210 ( ) | CN | 211 ( -------- ) ------ 212 ( | NROE |.........)--+ | 213 ( /./------ ) |====?=====?== 214 ( /./ ) | 215 -*- /./ -*- ------ 216 ( -------- ) | CN | 217 -*- | NROE | -*- ------ 218 ( -------- ) 219 -*- . -*- 220 ( . ) 221 -*- . -*- 222 -*+*- 223 | 224 | 225 ------ ------------------------------ 226 | AR | | AR: Access Router | 227 ------ | CN: Correspondent Node | 228 | | MR: Mobile Router | 229 ===?========== | HA_MR: MR's Home Agent | 230 | | MNP: Mobile Network Prefix | 231 ------ | MNN: Mobile Network Node | 232 | MR | | NROE: NEMO RO Entity | 233 ------ ------------------------------ 234 | 235 ===?========?====(MNP) 236 | | 237 ------- ------- 238 | MNN | | MNN | 239 ------- ------- 241 Figure 1: RO entity-based solution architecture 243 This approach, based on the use of RO network entities that are in 244 charge of performing the NEMO RO, seems to be the solution that has 245 received more positive feedback from the MEXT WG so far. This 246 solution -- as described in this document -- is very general and 247 leaves (on purpose) many aspects open/undefined. Depending on the 248 particular design decisions that can be taken, completely different 249 solutions might be the outcome. For example, there are currently two 250 proposed solutions that implement the RO entity-based concept in 251 different ways: the global Home Agent to Home Agent (HAHA) [9], [10], 252 and the Correspondent Router based RO for NEMO (CRON) [11]. 254 Since different design decisions might result into completely 255 different solutions, each of them meeting different requirements and 256 providing different features, it is very important to understand the 257 impact of the related design decisions, as well as the involved 258 trade-offs, when designing a NEMO RO solution for the aeronautics use 259 case. It is also important to look at the deployment issues derived 260 from the particular characteristics of the Aeronautical 261 Telecommunications Networks (ATNs) [12]. The next section of this 262 document is aimed at identifying the different important design 263 aspects, deployment issues and resulting trade-offs when considering 264 an RO entity-based NEMO RO solution. The goal of such an exercise is 265 to help the MEXT WG in the design of the NEMO RO solution for the 266 aeronautics use case. 268 3. Design issues/questions/trade-offs 270 In this section, we attempt to identify relevant design issues, 271 questions and involved trade-offs when considering an RO entity-based 272 NEMO RO solution, by asking the following questions: 274 1. Where are the RO entities located? 276 2. Who administratively manages the RO entities? 278 3. Which kind of addresses are gonna be used and who own them? 280 4. How many RO entities are needed to globally perform NEMO RO? 282 5. What trust relationships are needed? 284 6. Is the solution flexible enough to allow the participation of the 285 end-nodes (CNs and/or MNNs)? 287 7. Does the solution allow for a hierarchical scheme? 289 8. What is the target protocol complexity? 291 9. How is routing performed within the ATN? 293 10. Does the solution allow for implementing legal/political/ 294 economical requirements? 295 11. What is the robustness of the solution (i.e. what type of 296 failure affects to the reachability)? 298 3.1. Where are the RO entities located? 300 A first important question is where the RO entities are located. 302 One option is to place the RO entities at the gACSPs. In this case 303 the optimized path would have at least one end-point (depending on 304 whether the solution involves two RO entities at the infrastructure 305 or one entity at the infrastructure and the MR) at the gACSP. This 306 may be not good enough from a performance point of view, since the 307 farther the RO entities are from the communication end-points (i.e., 308 the mobile network and the CNs) the more likely the resulting path 309 would be less optimal. 311 There are some potentially relevant questions related to placing 312 entities at the gACSPs: 313 o can an MR get connectivity from two different gACSPs? 314 o is it possible that the same MR needs to make use of RO entities 315 placed at different gACSPs? 316 o would it be possible/required that an RO path is set-up between RO 317 entities belonging to two different gACSPs? If so, the different 318 routing policies that gACSPs might implement are relevant, as we 319 analyze later. 321 Another potential configuration is to place the RO entities at the 322 ANSPs. This configuration would allow to have one end-point of the 323 optimization close to the CNs (for the ATS scenario) and therefore 324 would result in paths that in general would be closer to the optimal 325 case. On the other hand, this approach would require more RO 326 entities to be deployed, therefore eventually increasing the 327 complexity of the solution. Besides, a solution that only places the 328 infrastructure RO entities at the ANSPs would require the MR being 329 the other RO entity in the NEMO RO process, since an MR might get 330 connectivity through a gACSP, or through an lACSP that is not an 331 ANSP. In the AOS scenario, this configuration might not work, since 332 AOS CNs might not get connectivity through an ANSP, and therefore an 333 RO entity should be deployed somewhere else. 335 In those communication scenarios in which the MR is attached to an 336 ANSP access network and it is communicating with a CN also attached 337 to the same ANSP, placing the RO entities at the ANSP (or collocated 338 within the MR) provides the additional advantage that these 339 communications would survive failures on the gACSPs to which the ANSP 340 gets connectivity from. This brings the following question: 342 o if a craft attached to an ANSP access network is communicating 343 with a CN attached to the same ANSP, is it required for the NEMO 344 RO solution to survive when the link of the ANSP to its gACSP goes 345 down? or put in a different way, would it be OK for such a 346 communication to be broken? It should be noted that the default 347 MRHA path used by the NEMO Basic Support protocol would likely 348 fail in this scenario. 350 Another approach is to deploy infrastructure RO entities at the 351 networks where CN are attached (these networks might be ANSPs in some 352 scenarios) and at MRs. This would provide shorter paths, at the cost 353 of higher complexity. 355 Last, a solution might not assume any particular placement of the RO 356 entities, i.e. they can be located anywhere. This assumption, 357 however, might not hold, depending on different aspects -- such as 358 security and addressing (for example if prefixes used in ATS cannot 359 leak to the Internet, leading to ATS traffic traversing the public 360 Internet). 362 3.2. Who administratively manages the RO entities? 364 It is also important to analyze who will be the stakeholders than 365 manage the RO entities, since this might have a critical impact on 366 the trust relationships that can be assumed among the different RO 367 entities. 369 One first scenario is the one in which all the RO entities are 370 managed by the same administrative entity. This compresses both the 371 case of RO entities deployed and managed by the airline company, and 372 the case of a global ACSP providing the RO entities for airlines with 373 an agreement with the ACSP. The obvious advantage of this scenario 374 is that it makes security and authentication easier, since all the RO 375 entities belong to the same administrative domain. However, this 376 does not mean that this scenario is excluded from having trust 377 issues, since a particular solution might require to inject routes in 378 some parts of the network (e.g., RO entities owned by an airline and 379 placed in networks not managed by the airline, anycast routing, 380 etc.), and this could require additional trust relationships. 382 A second scenario is that in which RO entities are managed by 383 different administrative domains. This approach has the advantage 384 that it provides additional flexibility, but it has the drawback of 385 requiring additional trust agreements in order to enable NEMO RO to 386 be provided in a secure way. Depending on the particular solution, 387 these additional trust relationships may include those that are 388 necessary to enable anycast routing, route injection or strong state 389 synchronization, among others. These are examples of functions that 390 are usually not easy to achieve across different domains. 392 For AOS, it seems assumable to deploy an RO entity close the the CNs, 393 and then perform RO between this entity and the MR, since both 394 entities are operated by the same organization (therefore, existence 395 of certificates between these nodes could be expected). The ATS case 396 is different, and should be analyzed carefully. Although some trust 397 may exist between an RO entity belonging to an ANSP and another RO 398 entity (e.g., one deployed at the aircraft, or one deployed at one 399 gACSP), assuming the existence of certificates or strong trust 400 relationships is not clear at this point [12]. This brings the 401 following question: 402 o which trust relationships are expected? this will be analyzed in 403 further detail in another subsection. 405 3.3. Which kind of addresses are gonna be used and who own them? 407 Addressing aspects might be relevant for the design of a NEMO RO 408 solution. Some related questions are the following: 409 o are there gonna be reserved blocks of addresses for aeronautical 410 use (i.e. addressing used to derive MNPs from)? 411 o can prefixes used to derive the MNPs configured at the crafts leak 412 on the routing tables of the public Internet? can ATS/AOS traffic 413 traverse the public Internet? 414 o what kind of addressing is gonna be used for ATS and AOS? would it 415 be the same kind of addressing? 416 o is it fine to use PA addresses to derive the MNPs configured at 417 the crafts or is it a requirement to use PI addresses (delegated 418 to the airline, to enable provider independency)? One possible 419 solution design is that MNPs are derived from the addressing of a 420 gACSP which deploy several RO entities to perform NEMO RO, but 421 this scenario would tie the airline to keep using the same 422 provider. 424 3.4. How many RO entities are needed to globally perform NEMO RO? 426 Another important aspect that should be taken into account is the 427 number of RO entities that would be required to perform NEMO RO 428 efficiently. There are many aspects that may have an impact on the 429 number of required RO entities, such as: 430 o Location of the RO entities. If a solution is based on placing RO 431 entities very close to the CNs this might require an entity per CN 432 network (e.g., per ANSP). Solutions relying on RO entities 433 located at gACSPs may require less entities to be deployed. 434 o Who owns/manages the RO entities. Depending on the particular 435 solution, it could happen that each airline has to deploy its own 436 RO entities, thus requiring a set of RO entities per airline. 438 o Required level of RO. Of course, depending on the optimization 439 levels that are required to be achieved, the location and number 440 of RO entities would change. If certain amount of additional 441 delay are allowed, it is expected that less entities would be 442 needed, since there is usually a trade-off between the number and 443 location of RO entities, and the reduction of the delay due to the 444 optimized path. 446 3.5. What trust relationships are needed? 448 Trust relationships are a quite important aspect to be analyzed. As 449 it has been described in this document, a solution based on the 450 deployment of RO entities may take many different forms, depending on 451 the design decisions and the deployment assumptions that are 452 followed. Most of the design decisions would have an impact or would 453 be constrained by the trust relationships that are in place among the 454 different players involved in the NEMO RO. 456 A solution based on the establishment of an optimized path between 457 two or more RO entities inherently requires those entities to have 458 strong trust relationships with the end-points of the communications, 459 since they are providing an alternative -- over the MRHA default path 460 -- route for their communication. Therefore, both MNNs and CNs MUST 461 have some form of trust relationship with the RO entities, to allow 462 the latter set-up an optimized route for their traffic (on their 463 behalf). As an example, both the MR and the HA of a particular 464 mobile network clearly have the required trust relationship with the 465 MNNs of the mobile network, and therefore they could take part of an 466 optimization mechanism. Other entities but the MR and its HA would 467 need additional trust relationships in place in order to take part of 468 a NEMO RO solution. 470 The RO entities involved in a NEMO RO solution MUST also have some 471 trust relationship between them, allowing them to authenticate each 472 other. 474 Additionally, RO entities involved in an RO attempt MUST be able to 475 show each other that they are authorized to send and receive packets 476 originated/destined to the nodes (MNNs or CNs) they are providing RO 477 with. As an example, let's assume a particular solution in which 478 there are two RO entities, one placed close to the mobile network, 479 and the other placed close to the CN. In this example, the entity 480 close to the mobile network should be able to show to the one close 481 to the CN that it is authorized to send/received packets originated/ 482 destined to the MNNs of that particular mobile network. It should be 483 noted that the same kind of authorization is required and provided 484 when the NEMO Basic Support protocol is used (i.e. the MR has to be 485 authorized to set-up a tunnel with its HA to exchange packets, and 486 both MR and HA have to authenticate each other before setting up the 487 tunnel). Actually, the same authorization is required between any 488 Internet host and the routers it uses to forward its traffic. 490 RO entities MUST also be authorized to inject the routes (if any) 491 required to get the packets that are subject of being route 492 optimized. The simpler case is that in which an RO entity is the 493 default router of the MNNs (i.e. the MR) or the CNs, since in this 494 scenario nothing is required to make MNNs/CNs forward to the RO 495 entity their traffic, and therefore this entity is inherently 496 authorized to forward that traffic. Other kind of solutions, in 497 which the RO entities are not collocated with the MR and the default 498 router of the CN might require the RO entities to inject routes 499 within a certain portion of the network. This might be hard to 500 achieve across different domains. 502 The location and ownership of the RO entities would likely have a 503 great impact on the potentially required trust relationships. 504 Therefore, trust and location issues have to be simultaneously 505 considered. 507 3.6. Is the solution flexible enough to allow the participation of the 508 end-nodes (CNs and/or MNNs)? 510 Supporting legacy end-nodes (MNNs and CNs) seems to be a required 511 characteristic, although it is not explicitly listed as that in [6]. 512 That means that a solution MUST NOT require changes neither at the 513 MNNs nor at the CNs to operate. However, that does necessary imply 514 that a particular solution cannot benefit from inserting changes on 515 some specific MNNs and/or CNs. In other words, a solution could 516 provide the option of collocating the RO entity function within some 517 MNNs and/or CNs -- in those scenarios in which these modifications 518 can be done. This brings the following question: 519 o is it permitted for a solution to collocate the RO entity function 520 within certain MNNs and/or CNs in case their software upgrade is 521 possible and that change brings operation benefits? 523 3.7. Does the solution allow for a hierarchical scheme? 525 Solutions based on the deployment of RO entities that perform the 526 required route optimization operations may benefit from adopting 527 hierarchical schemes. This, for example, may help to reduce 528 signaling and produce faster handovers. Therefore, a consideration 529 that could also be taken into account when designing a solution is if 530 it would support a hierarchical mode of operation. 532 Another somehow related design consideration is the following: a 533 particular solution might benefit from deploying NetLMM-alike access 534 networks and collocating the functionality of the NEMO RO entity with 535 that of the LMA. This could improve the overall performance, 536 although at the prize of increasing the global complexity and 537 requiring ACSPs to be NetLMM-alike. 539 3.8. What is the target protocol complexity? 541 It is obvious that a solution should be as less complex as possible, 542 but there is always a trade-off involved: less complex solutions 543 usually provide less features/performance gains/etc., and the other 544 way around. There are some particular requirements of the 545 aeronautical NEMO RO scenario that would likely impact on the 546 solution complexity, and that should be taken into account. 548 For example, in order to meet the separability requirement [12], RO 549 entities in charge of performing the RO would have to be able to 550 decide whether a certain flow has to be optimized or not. This could 551 be done by local policies or explicit signaling. Even in the case of 552 local policies, some mechanisms would be needed to support the 553 update/modification of the policies. It seems likely that it would 554 be up to the mobile networks to decide what flows are to be optimized 555 and which not. Therefore, the costs associated to meet the 556 separability requirement would likely involve some sort of signaling 557 between the mobile networks and the RO entities (at least to trigger 558 the NEMO RO of a particular flow). This cost should be evaluated and 559 taken into account when designing an RO entity-based solution. As an 560 example, if a solution collocates one RO entity function within the 561 MR, this solution would likely require less signaling to meet the 562 separability requirement than another solution that makes use of RO 563 entities placed on the network infrastructure. 565 3.9. How is routing performed within the ATN? 567 Routing policies and related issues within the ATN are an important 568 input to be considered when designing an RO entity-based solution. 569 Therefore, we should address the following questions: 570 o is it OK to have asymmetrical optimized routes? depending on the 571 design of the solution, it might be possible that some sort of 572 asymmetric routing appears. 573 o what are the routing policies followed by the ACSPs (especially 574 gACSPs)? do they do cold or hot-potato routing? cold-potato 575 routing may lead to very suboptimal routes under some particular 576 scenarios, even when a NEMO RO solution is used. 578 3.10. Does the solution allow for implementing legal/political/ 579 economical requirements? 581 In some Internet scenarios, it is preferred that data traffic does 582 not traverse certain networks because of different reasons, such as 583 legal, political or economical ones. Is that also the case for the 584 aeronautics use case?. If so, it might be important to provide NEMO 585 RO solutions with the required mechanisms to implement the policies 586 that translate those potential legal/political/economical 587 requirements. 589 3.11. What is the robustness of the solution (i.e. what type of failure 590 affects to the reachability)? 592 It is also important to analyze the robustness of a particular 593 solution design, in terms of the types of failures that might affect 594 to the reachability of the network. For example, a solution may 595 provide an RO path despite of a broken path between the NEMO and its 596 home network, while another one may not. It is important to identify 597 which are the failures that can happen in an ATN, which ones would 598 only affect the reachability of a craft only when using a NEMO RO 599 solution, and if it is fine to have those failures. 601 4. Security Considerations 603 This document analyzes a general approach to perform NEMO RO for the 604 aeronautics use case. As such, it identifies some security issues 605 that should be taken into account in the design of a concrete 606 solution. 608 5. IANA Considerations 610 This document has no actions for IANA. 612 6. Acknowledgments 614 The work of Carlos J. Bernardos has been partly supported by the 615 Spanish Government under the POSEIDON (TSI2006-12507-C03-01) project. 617 7. References 619 7.1. Normative References 621 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 622 Levels", BCP 14, RFC 2119, March 1997. 624 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 625 IPv6", RFC 3775, June 2004. 627 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 628 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 629 January 2005. 631 7.2. Informative References 633 [4] Manner, J. and M. Kojo, "Mobility Related Terminology", 634 RFC 3753, June 2004. 636 [5] Ernst, T. and H-Y. Lach, "Network Mobility Support 637 Terminology", RFC 4885, July 2007. 639 [6] Eddy, W., Ivancic, W., and T. Davis, "NEMO Route Optimization 640 Requirements for Operational Use in Aeronautics and Space 641 Exploration Mobile Networks", draft-ietf-mext-aero-reqs-02 642 (work in progress), May 2008. 644 [7] Baldessari, R., Ernst, T., Festag, A., and M. Lenardi, 645 "Automotive Industry Requirements for NEMO Route Optimization", 646 draft-ietf-mext-nemo-ro-automotive-req-01 (work in progress), 647 July 2008. 649 [8] Ng, C., Hirano, J., Petrescu, A., and E. Paik, "Consumer 650 Electronics Requirements for Network Mobility Route 651 Optimization", draft-ng-nemo-ce-req-02 (work in progress), 652 February 2008. 654 [9] Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA to HA 655 protocol", draft-thubert-mext-global-haha-00 (work in 656 progress), March 2008. 658 [10] Wakikawa, R., Shima, K., and N. Shigechika, "The Global HAHA 659 Operation at the Interop Tokyo 2008", 660 draft-wakikawa-mext-haha-interop2008-00 (work in progress), 661 July 2008. 663 [11] Bernardos, C., Calderon, M., and I. Soto, "Correspondent Router 664 based Route Optimisation for NEMO (CRON)", 665 draft-bernardos-mext-nemo-ro-cr-00 (work in progress), 666 July 2008. 668 [12] Bauer, C. and S. Ayaz, "ATN Topology Considerations for 669 Aeronautical NEMO RO", draft-bauer-mext-aero-topology-00 (work 670 in progress), July 2008. 672 Appendix A. Change Log 674 Changes from -00 to -01: 675 o Terminology changes: s/correspondent entity/RO entity. 676 o New solution design issue: robustness. 677 o Marcelo Bagnulo enlisted as author. 678 o Some editorial changes. 680 Authors' Addresses 682 Carlos J. Bernardos 683 Universidad Carlos III de Madrid 684 Av. Universidad, 30 685 Leganes, Madrid 28911 686 Spain 688 Phone: +34 91624 6236 689 Email: cjbc@it.uc3m.es 690 URI: http://www.it.uc3m.es/cjbc/ 692 Marcelo Bagnulo 693 Universidad Carlos III de Madrid 694 Av. Universidad, 30 695 Leganes, Madrid 28911 696 Spain 698 Phone: +34 91624 9500 699 Email: marcelo@it.uc3m.es 700 URI: http://www.it.uc3m.es/marcelo/ 702 Full Copyright Statement 704 Copyright (C) The IETF Trust (2008). 706 This document is subject to the rights, licenses and restrictions 707 contained in BCP 78, and except as set forth therein, the authors 708 retain all their rights. 710 This document and the information contained herein are provided on an 711 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 712 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 713 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 714 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 715 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 716 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 718 Intellectual Property 720 The IETF takes no position regarding the validity or scope of any 721 Intellectual Property Rights or other rights that might be claimed to 722 pertain to the implementation or use of the technology described in 723 this document or the extent to which any license under such rights 724 might or might not be available; nor does it represent that it has 725 made any independent effort to identify any such rights. Information 726 on the procedures with respect to rights in RFC documents can be 727 found in BCP 78 and BCP 79. 729 Copies of IPR disclosures made to the IETF Secretariat and any 730 assurances of licenses to be made available, or the result of an 731 attempt made to obtain a general license or permission for the use of 732 such proprietary rights by implementers or users of this 733 specification can be obtained from the IETF on-line IPR repository at 734 http://www.ietf.org/ipr. 736 The IETF invites any interested party to bring to its attention any 737 copyrights, patents or patent applications, or other proprietary 738 rights that may cover technology that may be required to implement 739 this standard. Please address the information to the IETF at 740 ietf-ipr@ietf.org.