idnits 2.17.1 draft-oneill-mip-rmasig-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 20 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 59 longer pages, the longest (page 1) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 59 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** There are 1779 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 30 instances of lines with control characters in the document. ** The abstract seems to contain references ([ConcatMIP], [NestMIP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2436 has weird spacing: '...ss flag set...' == Line 2454 has weird spacing: '...ss flag set...' == Line 2877 has weird spacing: '...ncelled the R...' -- 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 (8 May 2002) is 8024 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: 'ParallelMIP' is mentioned on line 1101, but not defined == Missing Reference: 'RouteOpt' is mentioned on line 2824, but not defined == Missing Reference: 'AAA-NAI' is mentioned on line 2991, but not defined == Unused Reference: 'RFC2026' is defined on line 3060, but no explicit reference was found in the text == Unused Reference: 'RevTunMods' is defined on line 3083, but no explicit reference was found in the text == Unused Reference: 'RMAsig' is defined on line 3092, but no explicit reference was found in the text == Unused Reference: 'MIPAAA' is defined on line 3095, but no explicit reference was found in the text == Unused Reference: 'MIPv6' is defined on line 3104, but no explicit reference was found in the text == Unused Reference: 'AAANAI' is defined on line 3107, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'NestMIP' -- No information found for draft-oneill-mip-proxyCCoA - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PCCoA' ** Obsolete normative reference: RFC 3220 (ref. 'MIPv4') (Obsoleted by RFC 3344) == Outdated reference: A later version (-09) exists of draft-ietf-mobileip-reg-tunnel-06 -- Possible downref: Normative reference to a draft: ref. 'RegTun' -- Possible downref: Normative reference to a draft: ref. 'RegTunMods' -- Possible downref: Normative reference to a draft: ref. 'RevTunMods' -- Possible downref: Normative reference to a draft: ref. 'ConcatMIP' -- Possible downref: Normative reference to a draft: ref. 'RMAsig' == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-aaa-key-09 -- Possible downref: Normative reference to a draft: ref. 'MIPAAA' -- Possible downref: Normative reference to a draft: ref. 'RoutOpt' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-lowlatency-handoffs-v4-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-mobileip-lowlatency-handoffs-v4 (ref. 'LowLat') == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-16 -- Possible downref: Normative reference to a draft: ref. 'AAANAI' Summary: 10 errors (**), 0 flaws (~~), 22 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Personal A. O'Neill 2 Internet Draft Flarion Technologies 3 Document: draft-oneill-mip-rmasig-00.txt 8 May 2002 4 Expires: Oct 2002 6 Regional Mobility Agent Signalling 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 30 Copyright (C) The Internet Society (2002). All Rights Reserved. 32 Abstract 34 Nested MIP [NestMIP] and Concatenated MIP [ConcatMIP] provide means to 35 support both localization and aggregation of MIP signalling. They achieve 36 this by providing two distinct layers of MIP signalling and forwarding; a 37 local access layer that provides local mobility management and local access 38 services, and a remote access layer that provides remote access back to a 39 home subnet. The local access layer provides a regional address from a 40 Regional Mobility Agent (a regional HA) that is then used as a CCoA for the 41 remote access layer. Inter-FA movement and MIP signalling at the local access 42 layer then automatically supports the hand-off of potentially multiple 43 parallel remote access sessions. Nested MIP achieves this through 44 encapsulation whilst Concatenated MIP achieves it though various forms of CoA 45 switching. 47 This draft describes the localised and aggregated MIP signalling model for 48 managing both the Local Access and Remote Access MIP layers. This includes 49 inter-FA and Inter-RMA hand-offs within and between Nesting and Concatenating 50 Regional Mobility Agents. This is necessary to support incremental, 51 heterogeneous deployment that is required given that Nested MIP is deployable 52 now whilst Concatenated MIP requires additional and significant standards and 53 development work. 55 INDEX 57 Abstract 59 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Conventions used in this document . . . . . . . . . . . . . . . . . 4 63 3. Terminology used in this document . . . . . . . . . . . . . . . . . 4 65 4. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. MIP Registration Overview . . . . . . . . . . . . . . . . . . . . . 5 68 5.1 LA Signalling Summary . . . . . . . . . . . . . . . . . . . . . 7 69 5.2 RA Signalling Summary . . . . . . . . . . . . . . . . . . . . . 7 70 5.3 Combined LA/RA Signalling Summary . . . . . . . . . . . . . . . 8 71 5.4. LA / RA Visitor Lists. . . . . . . . . . . . . . . . . . . . . 9 72 5.5. Summary of LA and RA Forwarding Modes. . . . . . . . . . . . . 11 73 5.6. Distinguishing LA and RA MIP Messages. . . . . . . . . . . . . 17 74 5.7 Summary of MIP Signalling Additions . . . . . . . . . . . . . . 19 75 5.8 Backwards Compatibility Issues . . . . . . . . . . . . . . . . 21 76 5.9 Signalling and Forwarding Evolution . . . . . . . . . . . . . . 22 78 6. Registration Refresh and Hand-Off Processing. . . . . . . . . . . . 23 79 6.1 LA Refresh. . . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 6.2 LA Hand-off (Inter-FA). . . . . . . . . . . . . . . . . . . . . 24 81 6.3 LA Hand-off (Inter-RMA, Inter-FA) . . . . . . . . . . . . . . . 25 82 6.4 Enhanced LA Hand-off (Inter-RMA, Inter-FA). . . . . . . . . . . 26 83 6.5 RA Layer Registration Update. . . . . . . . . . . . . . . . . . 27 84 6.6 RA Hand-off (inter-RMA, optionally inter-FA). . . . . . . . . . 29 85 6.7 Combined LA/RA Hand-off (for the oRMA). . . . . . . . . . . . . 30 86 6.8 Combined RA/LA Hand-off (for other global HAs). . . . . . . . . 32 88 7. Summary of Inter-FA Forwarding during Hand-off. . . . . . . . . . . 32 89 7.1 Transient forwarding for standard FA CoA switching. . . . . . . 33 90 7.2 Transient forwarding for Concat CoA switching . . . . . . . . . 33 92 8. Summary of Inter-Region Transient Forwarding. . . . . . . . . . . . 34 93 8.1 Transient forwarding from Nested oRMA to Nested nFA . . . . . . 34 94 8.2 Transient forwarding from Concat oRMA to Nested nFA . . . . . . 34 95 8.3 Transient forwarding from GFA oRMA to Nested nFA. . . . . . . . 35 97 9. Summary of Inter-RMA Transient Forwarding during Hand-off . . . . . 35 98 9.1 Nested to Nested using Nested inter-RMA transient forwarding. . 36 99 9.2 Nested to Concat using a Concat inter-RMA transient forwarding. 37 100 9.3 Concat to Concat using Concat inter-RMA transient forwarding. . 38 101 9.4 Concat to Nested using Nested inter-RMA transient forwarding. . 39 102 9.5 Nested to Nested using Concat inter-RMA transient forwarding. . 40 103 9.6 Nested to Concat using Nested inter-RMA transient forwarding. . 41 104 9.7 Concat to Nested using Concat inter-RMA transient forwarding. . 41 105 9.8 Concat to Concat using a Nested inter-RMA transient forwarding. 42 106 9.9 Nested <-> Concat Option Comparisons. . . . . . . . . . . . . . 42 107 9.10. Inter-RMA Transient Forwarding with GFA mode. . . . . . . . . 43 109 10. Additional Modifications, Options and Extension Definitions. . . . 43 110 10.1 Hybrid Concat/GFA Modes. . . . . . . . . . . . . . . . . . . . 43 111 10.2 GFA and private HoAs . . . . . . . . . . . . . . . . . . . . . 43 112 10.3 Heterogeneous RA forwarding modes. . . . . . . . . . . . . . . 44 113 10.4 HA/HoA Specific Processing and Context Transfer. . . . . . . . 44 114 10.5 Previous Foreign Notification Extension (PFANE). . . . . . . . 46 115 10.6 Previous RMA Notification Extension (PRANE). . . . . . . . . . 46 116 10.7 Style Extension (Stylext). . . . . . . . . . . . . . . . . . . 47 117 10.8 HFAIPext . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 118 10.9 HFAext . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 119 10.10 HoAList . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 120 10.11 HoAResp . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 121 10.12 HoAErr. . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 122 10.13 FA-NAI regional structure . . . . . . . . . . . . . . . . . . 50 123 10.14 Unicast FAA for MN specific FA CoA assignment . . . . . . . . 50 124 10.15 When the LA layer is hidden from the RA Layer . . . . . . . . 50 125 10.16 When both the LA and RA layers are exposed to the FA. . . . . 50 126 10.17 When the RA/LA layers terminate on different elements . . . . 51 127 10.18 RoA Address Allocation. . . . . . . . . . . . . . . . . . . . 52 128 10.19 Proxied HA Update . . . . . . . . . . . . . . . . . . . . . . 54 130 11. IPv6 Considerations. . . . . . . . . . . . . . . . . . . . . . . . 56 132 12. Security and AAA Considerations. . . . . . . . . . . . . . . . . . 56 133 12.1 FA and RMA Auto-configuration. . . . . . . . . . . . . . . . . 57 134 12.2 AAA Key Material Distribution. . . . . . . . . . . . . . . . . 57 135 12.3 Inter-operator PRANE . . . . . . . . . . . . . . . . . . . . . 58 136 12.4 Forwarding Checks. . . . . . . . . . . . . . . . . . . . . . . 58 138 13. Notice Regarding Intellectual Property Rights. . . . . . . . . . . 58 140 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 59 142 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 143 1. Introduction 145 Nested MIP [NestMIP] and Concatenated MIP [ConcatMIP] provide means to 146 support both localization and aggregation of MIP signalling. They achieve 147 this by providing two distinct layers of MIP signalling and forwarding; a 148 local access layer that provides local mobility management and local access 149 services, and a remote access layer that provides remote access back to a 150 home subnet. The local access layer provides a regional address from a 151 Regional Mobility Agent (RMA) (initially simply a local HA) that is then used 152 as a CCoA for the remote access layer. Inter-FA movement and MIP signalling 153 at the local access layer then automatically supports the hand-off of 154 potentially multiple parallel remote access sessions. Nested MIP achieves 155 this through encapsulation whilst Concatenated MIP achieves it though various 156 forms of CoA switching. 158 The signalling for Nested and Concatenated MIP is wholly based on existing 159 MIP signalling capabilities re-using standard MIP Registration Requests and 160 Replies, along with the extensions to those messages in support of regional 161 elements. The additional signalling mechanisms are limited to new extensions 162 and processing rules in support of the RMA, and in support of the additional 163 hand-off requirements. 165 This draft describes the localised and aggregated MIP signalling model for 166 managing both the local access (LA) and remote access (RA) layers through a 167 series of evolutionary steps starting from standard MIP. This includes inter- 168 FA and Inter-RMA hand-offs within and between Nesting and Concatenating 169 Regional Mobility Agents. This is necessary to support incremental, 170 heterogeneous deployment that is inevitable given that Nested MIP is 171 deployable now whilst Concatenated MIP requires additional and significant 172 standards and development work. 174 2. Conventions used in this document 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 177 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 178 be interpreted as described in RFC-2119 [RFC2119]. 180 3. Terminology used in this document 182 Much of the terminology used in this document borrows from Mobile IPv4 183 [MIPv4], MIP Regional Tunnelling [RegTun], MIP Reverse Tunnelling [RevTun] 184 and MIP Route Optimisation [RoutOpt]. This draft introduces the following 185 additional terminology. 187 Local access service - Internet access using a topologically local address 188 Remote access service - Internet access using a topologically remote address 189 Regional Mobility Agent (RMA) - a regional node capable of at least HA mode 190 Regional Address (RoA) - A HoA from the RMA HA function 191 RMA Region - the set of FAs able to allocate that RMA to a MN 192 LA/RA MIP - Local access MIP functionality between the MN and the RMA/HA 193 HoA visitor list - the standard MIP visitor list for HoA/CoA binding 194 LA visitor list - the MIP visitor list for the RoA / FA CoA binding 195 RA visitor list - the MIP visitor list for the HoA / CCoA=RoA binding 196 SHCoA - Shared CoA for multiple MNs from the FA or RMA. 197 MSCoA - Mobile Node specific CoA from the FA or RMA. 198 LA/RA Hand-off - a hand-off effected using the LA/RA MIP layer 199 LA/RA MIP Reg - An MIP Reg in the LA/RA layer direct to the present RMA/HA. 200 Inter-FA Hand-off - a hand-off between two FAs that updates the FA CoA. 201 Inter-RMA Hand-off - a MIP hand-off between two RMAs that changes MN RoA. 202 HFAIPext - the HFA IP address extension (generalization of GFAIPext) 203 PRANE - Previous Regional Agent Notification Extension 204 HoAlist - HoA/HA list extension 205 HoAResp - the matching HoA/HA response extension 206 HoAErr - extension to communicate HA/HoA specific errors 207 Style Extension (Stylext) - used to select LA/RA options 209 4. Motivation 211 The motivation for this work is described fully in [NestMIP] and [ConcatMIP] 212 but can be summarized here as extending MIP signalling (Registration and 213 Hand-off) to support efficient local Internet access in conjunction with 214 potentially multiple parallel remote access sessions. In the case of this 215 draft, the MIP signalling is enhanced to enable the instantiation, 216 maintenance and hand-off of local and remote access sessions. 218 5. MIP Registration Overview 220 There is a single LA session for an unlimited number of dependent RA 221 sessions. The existence of both a local access and remote access MIP layer 222 results in the need to support two layers of Registrations and hand-off in 223 the Nested/Concat MIP model. LA Registrations configure and refresh the LA 224 layer whilst RA Registrations configure and refresh the RA layer. Both layers 225 also support hand-off with the RA layer 'hand-off' updating the CCoA in the 226 global HA to use a new RMA, whilst the LA updates the CoA in the RMA and also 227 handles transient forwarding for the two types of LA hand-off. These are 228 called inter-RMA hand-off and inter-FA hand-off. 230 A region is defined as the set of FAs under a specific RMA such that an 231 inter-FA hand-off is occasionally also an inter-region hand-off. These hand- 232 offs are enabled by the LA MIP Registration Request / Reply, and by the RA 233 MIP Registration Request / Reply, as described in the following sections, in 234 support of three main forwarding modes; Nested [NestMIP], Concatenated 235 [ConcatMIP] and GFA as in [RegTun]. 237 +--------+ 238 | | 239 Global HAs | HA | 240 |HoA->CoA| 241 +--------+ 242 | \ 243 ... ... ... ... ... 244 | 245 +--------+ +--------+ 246 Regional RMAs | oRMA | | nRMA | 247 inter-RMA h/o | oRoA | | nRoA | 248 |CoA->CoA| |CoA->CoA| 249 +--------+ +--------+ 250 <-------region--------> <-------region--------> 251 / \ / \ 252 +--------+ +--------+ +--------+ +--------+ 253 Local FAs | | | | | | | | 254 inter-FA h/o | FA1 | | FA2 | | FA3 | | FA4 | 255 | CoA | | CoA | | CoA | | CoA | 256 +--------+ +--------+ +--------+ +--------+ 257 | | 258 | +--------+ +--------+ 259 ... | | | | 260 | MN | | MN | 261 | | | | 262 +--------+ +--------+ 264 Figure 1 above illustrates the topology. 266 The LA layer signalling specifies the type of requested/supported/assigned 267 LA features which include; 269 - the access service mode (local access only, remote access only, local 270 and remote access), 271 - the RMA RA forwarding mode (standard, nested, Concat, GFA) 272 - the RoA (public or private address) 273 - the FA CoA (shared or MN specific address). 275 These need to be sufficient for all the active or planned RA sessions and 276 commensurate with the operator policy and MN AAA profile. The default LA 277 layer signalling and processing is both local and remote access service, 278 using nested mode RA forwarding in the RMA for a public or private RoA to a 279 shared FA CoA. This can be seen to be equivalent to standard MIP with the RMA 280 acting simply as a local HA for the RoA address, with the addition that the 281 RoA can also be used as an interface address for local access. The MN can 282 then use standard MIP mechanisms to use the RoA as a MN CCoA for RA MIP 283 Registration directly with a global HA. The routing entries for the RoA 284 always point towards the RMA and the RMA uses MIP mechanisms to redirect the 285 packets to the MN using that RoA. The MN uses LA MIP extensions to request 286 changes to this default behaviour and these extensions can be checked and 287 modified by the FA and the RMA. The FA can inform the MN of the facilities 288 available at that FA and within that RMA region, and complementary 289 information can also be communicated through successful and failed 290 Registration Replies. The signalling exchanges to support the LA and RA 291 layers through a series of evolutionary steps are defined next. 293 5.1 LA Signalling Summary 295 There are four versions of LA MIP Registration Request/Reply. 297 5.1.1 LA Reg v1 (intra-RMA, intra-FA) 299 This is sent via the old FA to an old RMA when refreshing a binding at that 300 old RMA. The CoA, RMA and RoA are therefore already known when sending the LA 301 Reg. This is possible using existing MIP standards. 303 5.1.2 LA Reg v2 (intra-RMA, inter-FA) 305 This is sent to the old RMA via a new FA as part of an FA hand-off within 306 the region of the old RMA or from a new FA outside of that region that has or 307 can rapidly acquire an SA with the oRMA for authentication purposes. The RMA 308 and RoA are once again already known when the LA Reg is sent by the MN. The 309 need for inter-FA hand-off is detected before sending the LA Reg. The LA Reg 310 can then include an inter-FA hand-off extension such as PFANE to trigger a BU 311 back to the oFA. The BU facilitates transient forwarding from the oFA to the 312 nFA during the RMA changeover. This is possible using existing MIP standards. 314 5.1.3 LA Reg v3 (inter-RMA, inter-FA) 316 This is sent to the new RMA from the new FA when starting a new LA session or 317 when recovering from a failed RMA. This therefore requires dynamic assignment 318 of an RMA and an RoA from that RMA. If the MN detects the need for an inter- 319 RMA hand-off then it can be sent with an inter-FA hand-off extension such as 320 PFANE to trigger a BU back to the oFA. The BU facilitates transient 321 forwarding from the oFA to the nFA during the RMA changeover. This is 322 possible using existing MIP standards with the dynamic allocation using the 323 equivalent mechanisms to that for dynamic HA/HoA assignment. 325 5.1.4 LA Reg v4 (inter-RMA, interFA) 327 This is sent to the new RMA from the new FA along with an inter-FA hand-off 328 extension such as PFANE, and a new inter-RMA hand-off extension called a 329 Previous RMA Notification Extension or PRANE. Dynamic assignment of RMA and 330 RoA are again required. The PFANE triggered BU facilitates transient 331 forwarding from the oFA to the nFA during the RMA changeover. In addition, 332 the PRANE is added to also trigger a BU back to the oRMA from the nFA and/or 333 the nRMA depending on state in the new FA and in the PRANE itself. This BU is 334 used to facilitate more efficient transient forwarding, of in-flight packets 335 arriving at the old RMA, directly to the nFA and/or to the nFA via the nRMA. 336 This avoids excessive use of expensive inter-FA transient forwarding 337 especially in the case of singley-homed FAs, connected over expensive access 338 circuits, that is typical in cellular networks. This type of registration is 339 possible with existing MIP standards and simply requires a new extension to 340 trigger the request for oRMA transient forwarding, and associated 341 modifications to MN, FA and RMA (local HA). 343 5.2 RA Signalling Summary 345 The RA MIP layer manages remote access sessions between a global HA/HoA and 346 the MN. There are three versions of RA MIP Registration signalling. 348 5.2.1 RA Reg v1 350 This is sent directly between the MN and the global HA for the global HoA. 351 This is unseen by the FA and the RMA and is possible with existing MIP 352 standards if the MN has a CCoA. This draft extends the standard MIP 353 Registration definition to enable the CCoA to be the RoA assigned from the LA 354 MIP layer. 356 5.2.2 RA Reg v2 358 This is sent to the global HA via the FA and therefore requires the FA to be 359 able to process both LA and RA MIP Registrations. Whilst the MIP standard 360 Registration message can be sent via the FA, neither the standard MIP MN nor 361 FA has the required intelligence to distinguish between and appropriately 362 deal with LA and RA messages, and the associated packet forwarding. 364 5.2.3 RA Reg v3 366 This is sent to the global HA via the FA and the RMA from the LA layer. This 367 therefore requires the FA and the RMA to be able to process both LA and RA 368 MIP Registrations. Whilst the MIP standard Registration message can be sent 369 via the FA, neither the standard MIP MN nor FA has the required intelligence 370 to distinguish between and appropriately deal with LA and RA messages. The 371 RMA in the LA layer is a local HA whilst in the RA layer it is a regional 372 element on the way to a global HA. Again, neither existing HAs nor in fact 373 regional elements such as GFAs have the required intelligence to distinguish 374 between and appropriately deal with LA and RA MIP Registrations. Also, 375 neither the MN, FA, HA nor GFA have the ability to deal with subsequent 376 packet forwarding and the regional signalling extensions to enable 377 registrations through a regional element are not yet completed. 379 5.3 Combined LA/RA Signalling Summary 381 There are two forms of combined LA/RA signalling that have been designed for 382 efficiency reasons. These are; 384 5.3.1 Combined LA/RA Reg v1 386 This is a combination of an LA Reg v3 and an RA Reg v3. It is sent to the 387 oRMA for the oRoA, via the nFA and the nRMA. It carries an inter-FA hand-off 388 extension to trigger a BU to the oFA from the nFA to facilitate inter-FA 389 transient forwarding. In the FA, this registration triggers nRMA and FA CoA 390 assignment, and in that nRMA it triggers nRoA assignment and the type of RA 391 forwarding. In the oRMA, the nRoA is installed as the CoA for the oRoA (oRMA 392 becomes a global HA) which facilitates persistent forwarding of traffic 393 arriving on the oRoA address towards the nRMA. In the nRMA and nFA, 394 forwarding is enabled both for traffic arriving on the oRoA and the nRoA. 395 This enables inter-region hand-off with inter RMA forwarding and persistent 396 use of the oRMA and oRoA by elevating them into the RA layer (global HA/HoA) 397 whilst away from the region of that oRMA. 399 5.3.2 Combined LA/RA Reg v2 401 This is a combination of an LA Reg v4 and an RA Reg v3. This is therefore 402 sent to the global HA for the HoA via the nRMA and the nFA. Inter-FA and 403 inter-RMA hand-off extensions are included by the MN to trigger BUs to the 404 oFA and the oRMA. These BUs facilitate transient forwarding between oFA and 405 nFA, and between the oRMA and the nFA/nRMA. The RA session for the combined 406 message can be selected by the MN either based on the remaining lifetime, 407 order of importance or to minimise the effect of hand-off (latency/packet 408 redirection etc) for that particular session. This version is used instead of 409 the Combined LA/RA Reg v1 when the oRMA/oRoA are not required to transition 410 into an RA session as a persistent global HA/HoA pair for the MN, and hence 411 only transient forwarding is required. 413 5.4. LA / RA Visitor Lists 415 LA MIP Registrations create and update the LA visitor list in the FA and the 416 RMA. The LA visitor list contains forwarding entries for packets addressed to 417 the RoA from any source in the Internet, including HAs, but can be 418 constrained by the use of additional firewall entries. Firewall entries can 419 be created to control various remote access techniques, as well as for 420 controlling specific traffic sources, protocol types, port numbers etc... 422 The RA visitor list can be considered to be a specific type of firewall entry 423 maintained by MIP signalling. Logically you can imagine a packet first being 424 matched against state in the RA visitor list (more specific checks that can 425 cause a packet to be discarded, re-marked, accounted differently or to 426 undergo alternative forwarding) and then being checked against the LA visitor 427 list before undergoing default local access forwarding. Of course there are 428 many options for the implementation of these two lists from two distinct 429 layers through to a single integrated list. 431 RA MIP Registrations create and update the RA visitor lists in the MIP nodes 432 through which it is forwarded and processed. The RA visitor list specifically 433 ensures that data packets addressed to the MN are only received from the 434 correct previous MIP node as learnt during the RA Registration process. This 435 is a generalisation of the forwarding rules in [RegTun] to deal with Nesting, 436 Concat modes as well as CoA Switching. The RMA, the FA and the MN need to 437 keep MN specific state in the visitor list to undertake this check if the RA 438 Registration signalling traverses that node, and that node changes the packet 439 source address for the downstream node. 441 The RMA must check that the data packet came from the registered HA. 442 The FA must check that the data packet came from the registered HA or RMA. 443 The MN must check that the data packet came from the registered HA,RMA,FA. 445 The MN specific state used for this source check in the FA should not include 446 the HoA. Avoiding HoA specific state in the FA means that it does not need to 447 be maintained through inter-FA hand-off using Context Transfer (because we 448 want to avoid independent MIP hand-off signalling for each HoA). The problem 449 with HoA specific state and aggregated signalling is covered in more detail 450 in [ParallelMIP]. The appropriate level of RA checks in each element is a 451 trade-off between the processing required to undertake those checks, against 452 being able to efficiently eliminate incorrect packets as early as possible. 454 The level of checking is operator dependent. HoA specific processing 455 features such as accounting and QoS are particularly an issue for the 456 operator but in these cases are under the control of the AAA profile. 458 Each foreign agent MUST be configured with a shared care-of address. In 459 addition, for each pending or current LA registration the foreign agent 460 MUST maintain an LA visitor list entry containing the following 461 information obtained from the mobile node's LA Registration Request: 463 - the link-layer source address of the mobile node 464 - LA layer MN-NAI to identify the MN profile 465 - the IP Source Address (the mobile node's Home Address = RoA). 466 - the IP Destination Address (as specified in [MIPv4] 3.6.1.1) 467 - the UDP Source Port 468 - the Home Agent address = RMA 469 - the Identification field 470 - the requested registration Lifetime, and 471 - the remaining Lifetime of the pending or current registration. 473 In addition, for each pending or current RA registration the foreign agent 474 MUST maintain an RA visitor list entry containing the following 475 information obtained from the mobile node's RA Registration Request: 477 - the link-layer source address of the mobile node 478 - RA layer MN-NAI to identify any additional RA layer session profile 479 - the IP Source Address (the mobile node's CCoA = RoA). 480 - the IP Destination Address (as specified in [MIPv4] 3.6.1.1) 481 - the UDP Source Port 482 - the Home Agent address = global HA 483 - the forwarding mode (standard, Nested, Concat or GFA) 484 - the FA CoA (MSCoA for Concat mode) 485 - the Identification field 486 - the requested registration Lifetime, and 487 - the remaining Lifetime of the pending or current registration. 489 Both lists are then supplemented with additional information that is 490 particular to the chosen RA layer forwarding mode. The LA forwarding mode is 491 always to encapsulate towards the nFA CoA. 493 The LA and RA visitor lists can be implemented for example as a single list 494 of visitor entries containing both LA and RA state entries. The forwarding 495 search should check the more restrictive RA entries (specific HAs) before 496 checking the LA layer entries (any CN). 498 The RMA needs to keep the same visitor list as an existing HA for its role in 499 the LA layer related to the RoA address. In addition, it must be able to 500 store RA visitor state if the registration is routed via the RMA. The FA 501 knows either from configuration, from MIP Replies or from the RMA state 502 returned from the AAA system whether or not the RMA supports RA registration. 504 The HA visitor list is unchanged by this draft. 506 5.5. Summary of LA and RA Forwarding Modes 508 5.5.1 The LA Layer Forwarding 510 The LA layer supports the forwarding of local access traffic. There is one 511 type of forwarding at the LA layer and this is to 'Nest' the oRoA within a 512 tunnel between the RMA (the local HA) and the FA as in normal MIP forwarding. 513 This Nested forwarding is unaffected by the RMA RA layer features which can 514 support Nested, GFA and Concatenated forwarding of packets from a global HA. 516 Local traffic sent by a Correspondent Node (CN) to the RoA arrives at the RMA 517 that owns that RoA, and is then encapsulated into the FA CoA registered for 518 that RoA. It is then forwarded to the FA owning that CoA and through which 519 the MN typically sent the LA layer MIP Reg. The FA decapsulates, inspects the 520 RoA to identify the MN, and then forwards to that MN. The FA CoA is either a 521 SHCoA or a MSCoA depending on the RA forwarding mode negotiated at the LA 522 layer, for all RA sessions. Note that the FA must inspect the RoA within an 523 MSCoA to ensure it agrees with the MN LA state and to prevent packet mis- 524 delivery. 526 CN HA oRMA nRMA oFA MN 528 Forward LA CN----------------------------------------------------->oRoA 529 oRMA=============>oFACoA 530 Reverse LA CN<-----------------------------------------------------oRoA 532 RevTun LA CN<-----------------------------------------------------oRoA 533 (Direct) oRMA<=============oFACoA 534 (Encaps) oRMA<=============oFACoA x <=====oRoA 536 Figure 2. LA layer forwarding. 538 Note that the RoA is just a HoA from the RMA and therefore reverse tunnelling 539 features [RevTun] are unaffected, including the ability in 'Encapsulating 540 style' to revtun some packets via the RMA and reverse some directly to the 541 CN. Note also that the FA needs to undertake a source address check on the 542 RoA to ensure that RoA is registered in that FA for that MN. 544 A range of forwarding models for the RA layer are then possible depending on 545 the evolution stage, the deployed RMA/FA operator capabilities, the MN AAA 546 profile and the MN LA Registration contents. The LA layer is however 547 responsible for preparing the RA layer forwarding mode, which should 548 generally be the same for all RA access sessions through that RMA for that 549 MN. This requires the discovery, negotiation and agreement at the LA layer of 550 the required forwarding mode. This is necessary so that each LA hand-off can 551 immediately acquire the correct type of FA CoA and then configure the RA mode 552 via the nRMA before the RA sessions are refreshed. 554 Before examining the RA forwarding options, a special mention needs to be 555 made of Route Optimisation here [RouteOpt]. Initially, a MN will register 556 through to a HA and packets will come through that HA to the MN, experiencing 557 the RA layer forwarding to be discussed next. However, after subsequent 558 signalling between MN and CN, the two nodes can tunnel directly to each other 559 and bypass the HA. At this point these packets are from the CN to the RoA and 560 from the RoA to the MN which are therefore forwarded as local access traffic. 562 If the RA visitor list inspects inner packet headers to identify them as 563 remote access traffic, those packets can still be exposed to RA layer 564 processing (that may even be HoA specific). The state required to undertake 565 this check can be built from the route optimisation messages that are 566 exchanged via the HA, although this creates CN specific state which is only 567 practical to maintain in the RMA. One benefit though that the architecture 568 brings to route optimisation is the fact that the RoA changes much less 569 frequently and so binding update traffic is significantly reduced, with the 570 reduction improving as the size of regions is increased at the cost of less 571 optimal forwarding via the RMA. 573 There are four types of forwarding possible at the RA layer between the 574 global HA and the MN, three of which are defined in this draft. These are 575 covered in the next sections. 577 5.5.2 Standard MIP remote access 579 This is a direct tunnel from the global HA to the MN CCoA from the oFA 580 subnet, with any optional reverse tunnel being between the MN CCoA and the 581 HA. This tunnel is used whether or not the MN registers via the FA at the RA 582 layer. 584 CN HA oRMA nRMA oFA MN 586 Forward RA CN------------------------------------------------------>HoA 587 HA==========================================>oCCoA 588 Reverse RA CN<------------------------------------------------------HoA 589 RevTun RA HA<==========================================oCCoA 591 Figure 3. Standard MIP RA. 593 Note that the CCoA here is from the FA subnet and hence must be updated on 594 every FA hand-off. 596 5.5.3 Nested MIP remote access 598 RA Nested Forwarding is as for LA Nested forwarding in that the RMA 599 encapsulates packets addressed to the RoA, in the FA SHCoA that was LA 600 registered by the MN via the present FA. The FA then decapsulates and 601 forwards to the MN that has been assigned that RoA. Nested MIP RA can be 602 configured using any of RA Reg v1, v2 or v3 as described above because 603 neither the RMA nor the FA need to receive any additional RA information to 604 successfully forward the traffic towards the MN CCoA. This is because the HA 605 is sending to the RoA, and the RMA and FA can forward this at the LA layer. 607 CN HA oRMA nRMA oFA MN 609 Forward RA CN------------------------------------------------------->HoA 610 HA===========================================>oRoA 611 oRMA================>oSHCoA 613 Reverse RA CN--------------------------------------------------------HoA 614 (PCCoA only using RevTun LA) oRMA<================oRoA 616 RevTun CN--------------------------------------------------------HoA 617 RevTun RA HA<===========================================oRoA 618 RevTun RA/LA oRMA<================oSHCoA 620 Figure 4. Nested MIP RA 622 There is a forward tunnel from the HA to the MN CCoA within a tunnel between 623 the RMA and the FA. The RMA to FA tunnel is managed by the LA layer whilst 624 the HA to MN CCoA is managed by the RA layer. Reverse tunnelled remote access 625 traffic does not need to traverse the oRMA but is sent from the MN CCoA=RoA 626 to the HA. LA reverse tunnelling can be used to ensure that the RMA is also 627 traversed if that is necessary for policy/feature reasons. 629 Forward and reverse traffic that is not tunnelled at the RA layer over the 630 air interface is not generally supported with CCoAs in this model. However, 631 proxy CCoAs [PCCoA] potentially offer a way to achieve this, and save 632 encapsulation overhead or header compression load if the FA is visited by the 633 registration signalling and end to end IPSEC is not employed. A PCCoA is a 634 CCoA whose tunnel management is handled at the other end of the link in the 635 FA. In the forward direction this causes the FA to also decapsulate from the 636 RoA and forward to the MN with a HoA destination address. In the reverse 637 direction, the packet now has a HoA source address and so some form of 638 ingress filtering must be performed. This can be undertaken by the FA if it 639 has HoA state supported using Context Transfer. Preferably though, the FA can 640 simply process based on the incoming link-layer address (to identify the MN 641 and hence the RoA entry) and then reverse tunnel the packet at the LA layer 642 from the oRoA to the RMA where HoA state can practically undertake the source 643 address check for that MN. PCCoA processing is clearly complex however and 644 the cost benefits of this mode need to be determined. 646 The major difference compared to standard MIP remote access mode is that the 647 MN CCoA is the Regional Address (RoA) which comes from the RMA, rather than a 648 CCoA from the FA subnet as in standard MIP specs. In the latter case, the FA 649 hand-offs result in CCoA changes and a need to update the global HA, wheras 650 with Nested MIP the RoA is valid across a number of FAs beneath a single RMA. 652 The RA visitor list in the MN ensures that the correct HA sent the correct 653 HoA in the correct RoA, and that the packet was received from the registered 654 FA. If the RA Registration traverses the FA then an RA visitor list in the FA 655 can ensure, after decapsulating from the FA CoA, that the packet came via the 656 registered RMA for that RoA by checking the source address on the 657 encapsulation towards the FA CoA. If the RA Registration traverses the RMA 658 then the RA visitor list in the RMA checks that the source HA has been 659 registered for that RoA. 661 Note that the FA and RMA may also undertake HoA specific processing which 662 also requires the inner HoA to be interrogated. An optional RA visitor list 663 in the RMA, based on the received RoA, may check that the HA address is 664 correct for the encapsulated HoA and that the HoA is registered for that RoA 665 and MN. The FA can check that the MN that owns that RoA also owns the HoA or 666 it can simply rely on the fact that this check may be performed by the RMA 667 and must be by the MN. 669 5.5.4 GFA CoA switching 671 This is CoA switching from [RegTun] which uses a HoA specific RA visitor list 672 in the RMA (acting like a GFA) and FA to route packets arriving on shared RMA 673 and FA CoAs (SHCoAs). This mode is supported in this document for backwards 674 compatibility and transition reasons if GFAs and GFA aware MNs have been 675 deployed. 677 CN HA oRMA nRMA oFA MN 679 Forward RA CN------------------------------------------------------>HoA 680 HA====>oRMA x oRMA===============>oSHCoA 682 RevTun RA CN-------------------------------------------------------HoA 683 HA<====oRMA x oRMA<===============oSHCoA 685 Figure 5. GFA MIP RA 687 The forward tunnel is from the HA to the RMA CoA, and then from the RMA to 688 the FA CoA. The reverse tunnel is the exact reverse of the forward tunnel. 689 Reverse traffic that is not tunnelled at the RA, and therefore has the HoA as 690 the source address, can clearly be supported in this model because the FA has 691 HoA specific state. In this case, the RoA is not needed by the RA layer and 692 is used simply for the LA layer that is not shown. 694 This mode of forwarding can only be supported with an RA MIP v3 Reg because 695 specific state needs to be installed into the RMA and the FA for the 696 switching. The GFA forwarding should only generally be supported for MNs 697 that are limited to a single remote access session (a single HoA) and that 698 are using a globally unique HoA, these being known limitations of GFA 699 forwarding. The HoA specific RA visitor list state must be maintained at each 700 new FA and RMA, for multiple RA sessions, using the HoA independent LA layer 701 signalling. This can be accomplished, for a single RA session, by the LA MIP 702 Reg including the HoA information, in a HFAext, to support inter-FA and 703 inter-RMA hand-off. For multiple RA sessions (HoAs), the HFAext can be 704 replaced with the HoAList extension and Context transfer mechanisms are then 705 required between FAs and RMAs, triggered by the aggregated LA hand-off, which 706 is discussed in more detail in section 10. 708 The RA visitor list in the MN ensures that a correct HoA was used and that 709 the packet was received from the registered FA. The RA visitor list in the 710 RMA must check that the HA address is valid for the received HoA. After 711 decapsulating from the FA CoA, the FA checks that the packet came via the 712 registered RMA for that MN by checking the source address on the 713 encapsulation towards the FA CoA. The FA and/or RMA must undertake HoA 714 specific processing as part of the GFA model, which can be useful for other 715 previously mentioned reasons, based on AAA profile or operator policy. 717 Note that if local access is also requested, then the RMA needs to be able to 718 distinguish between encapsulated packets sent from a specific HA as part of 719 RA GFA forwarding, and unencapsulated/encapsulated packets sent from CNs as 720 part of the local access service. This is to avoid the RMA attempting to 721 incorrectly strip the RoA. Therefore, to support LA as well as RA access, the 722 GFA needs to inspect the incoming source address to match it against a known 723 HA before undertaking CoA switching. Alternatively, because local access 724 traffic arrives on the RoA whilst remote access traffic arrives to a SHCoA, 725 then the SHCoA can trigger the forwarding to the GFA module where the HA 726 source address can be checked. This is a change from the [RegTun] GFA 727 mechanism which enables local access traffic to bypass the GFA module in the 728 RMA (and equivalently in the FA for packets arriving to the RoA and the FA 729 SHCoA). 731 5.5.5 Concatenated CoA Switching 733 This is a new form of somewhat complex CoA switching to overcome the 734 perceived limitations in the GFA model. This mode of forwarding can only be 735 supported with an RA MIP v3 Reg or Combined Reg because specific state needs 736 to be installed into the RMA and the FA for the switching. The concatenated 737 processing, unlike GFA processing, can be supported for public and private 738 HoA addresses and for multiple concurrent RA sessions. The concatenated 739 request can be refused as a result of AAA state in the FA, which can then 740 convert the request to either GFA or Nested MIP. 742 CN HA oRMA nRMA oFA MN 744 Forward RA CN------------------------------------------------------->HoA 745 HA====>oRoA x oRMA===============>oMSCoA=====>oRoA 747 ReverseRA CN---------------------------------------------------------HoA 748 (PCCoA only) oRMA<===============oMSCoA 750 CN---------------------------------------------------------HoA 751 RevTun RA only HA<===========================================oRoA 752 RevTun LA/RA HA<====oRoA x oRMA<===============oMSCoA<=====oRoA 754 Figure 6. Concatenated MIP RA 756 The forward tunnel is between the HA and the RMA which switches traffic into 757 a second tunnel between the RMA and the FA. The RA layer reverse tunnel is 758 similar to that for Nested though in that it can bypass the oRMA. Note that 759 the RA traffic in Concat, as in Nested, requires a tunnel over the air 760 interface, whilst it is not required for GFA. If either or both LA and RA 761 reverse tunnelling is selected then the processing rules ensure that the 762 source address is correct for the information in the destinations binding for 763 the forward direction. 765 Forward and reverse traffic that is not tunnelled at the RA layer over the 766 air interface is not generally supported with CCoAs in this model. However, 767 proxy CCoAs [PCCoA] potentially offer a way to achieve this, and save 768 encapsulation overhead or header compression load if the FA is visited by the 769 registration signalling and end to end IPSEC is not employed. The reverse 770 forwarding is then as for Nested by reverse tunnelling to the RMA, but this 771 time from the oMSCoA to match on the forward entry in the RMA. 773 The other modifications wrt [RegTun] are that the RMA CoA and FA CoA are MN 774 specific (MSCoAs) so that neither the RMA nor the FA need to keep HoA 775 specific state for forward or reverse RA tunnels. This enables a single LA 776 MIP Reg to move all the RA sessions together and also ensures that Context 777 Transfer of HoA specific state, for basic RA forwarding, can be avoided 778 during FA hand-off. Note that Context Transfer might still be required to 779 optionally support HoA specific processing in the FA and/or RMA, and is 780 discussed in detail in section 10. If HoA specific state is added in the RMA 781 and FA for such reasons then the MN specific CoA and RoA can also be used to 782 assure that the concatenation of the MSCoA+HoA or RoA+HoA is always locally 783 unique. An example of this HoA specific processing is the source address 784 check in the RMA for reverse packets that are not tunnelled at the RA layer. 786 The RA visitor list in the MN ensures that a correct HoA was used and that 787 the packet was received from the registered FA. A mandatory RA visitor list 788 in the RMA must check that the HA address is valid for the received RoA. An 789 RA visitor list in the FA must keep MSCoA and RoA state to be able to 790 correctly identify and forward to the receiving MN by switching from the 791 MSCoA into the RoA destination address whilst generally ignoring the inner 792 destination address (ie the HoA). Of course, if the inner destination address 793 is the RoA (local access traffic) then the RoA re-encapsulation is not 794 required. This complicates the FA visitor compared to the Nested Model where 795 the RoA is always visible. After decapsulating from the FA CoA, the FA checks 796 that the packet came via the registered RMA for that MN by checking the 797 source address on the encapsulation towards the FA. The FA and/or RMA may 798 also undertake HoA specific processing for other previously mentioned 799 reasons, based on AAA profile or operator policy. The HoA is made locally- 800 unique in the FA through the concatenation with the MSCoA, and in the RMA 801 through concatenation with the RoA. 803 Note that if local access is also requested, then the RMA needs to be able to 804 distinguish between encapsulated packets sent from a specific HA as part of 805 RA RMA forwarding, and unencapsulated/encapsulated packets sent from CNs as 806 part of the local access service. This is to avoid the RMA attempting to 807 incorrectly strip the RoA. In both cases, the packets are addressed to the 808 RoA. Therefore, to support LA as well as RA access, the RMA Concat module 809 must inspect the incoming source address to match it against a known HA 810 before undertaking concatenated switching. Similarly, the FA needs to have an 811 additional entry for the LA visitor list for the RoA, which is created as 812 part of the LA MIP Layer signalling. The Concat module must therefore analyse 813 all packets whilst the GFA module only inspects packets from registered HAs. 814 However, when the GFA module needs to inspect and switch a packet, this 815 processing is more intensive (source, dest, HoA check) than necessary for the 816 Concat module which simply uses the incoming interface (source/dest check). 817 This enables the Concat module to easily switch packets, encapsulated from a 818 registered HA to a specific RoA (RA layer), whilst encapsulating packets from 819 arbitrary CNs (whether encapsulated or not) to the same RoA (LA layer) in a 820 single module. 822 5.5.6 RMA Availability 824 A detailed comparison between the four modes, and specifically between the 825 two new modes and the existing standard and GFA modes, is distributed 826 throughout this document. A specific and very important issue covered here is 827 the RMA availability and its impact on the system. 829 GFA mode here and in [RegTun] requires a highly stateful core node that is 830 tied into both the MN and the HA through installed registration state. Such a 831 core box, which can have a large number of installed flows needs to be 832 high availability such that its failure is very rare, but even then still 833 catastrophic. This is because recovery requires each MN to re-install 834 bindings into the remote HAs as well as into the regional element. Hot 835 standby can be used between regional nodes to quickly recover the MN to GFA 836 state but this does not help with the remote access layer binding in the 837 global HA and incures obvious complexity and cost. 839 A major benefit of the design of Nested and Concat modes is that the CoA in 840 the HA is the RoA. This means that multiple RMAs can advertise routes to 841 prefixes covering the RoAs so that if one RMA is lost then traffic to the RoA 842 from global HAs will automatically be redirected to the next best RMA 843 according to routing, so enabling prefixes to be distributed across the 844 remaining RMAs. Note also that the RMA protection mechanisms are almost 845 exactly the same as the mechanisms used today for HAs, and given the RMAs 846 role as a local HA it is clear that these protection mechanisms would already 847 be required. In addition, the it is also clear that the RMA can also play the 848 role of a global HA, allocating out regional and global home addresses from 849 its subnet. Once again, the protection mechanisms envisaged for the RMA are 850 constent with that which is required for its role as a HA. 852 Replication between these boxes of the LA and RA state in the RMA can then 853 enable the LA and RA to recover quickly without MN activity. The replication 854 state for nested mode is significantly smaller than that required for Concat 855 mode but Concat mode forwarding is less bandwidth expensive. Alternatively, 856 each FA could use the routing entry failure for an RMA as indication that it 857 should trigger any mobiles that use that failed RMA to re-register to an 858 alternate RMA. This can be done simply by immediately sending 859 the address of the standby RMA address in an FAA to make the MNs not using 860 that standby RMA but were using the failed RMA (1+1 protection) to undertake 861 an RMA hand-off. This will cause them to issue a new LA Reg to the standby 862 RMA but because the region hasn't changed in the FAA will avoid them 863 achieving that by issuing a Combined RA/LA Reg to the oRMA. They will instead 864 simply issue an LA Reg v3 or v4. This is much less costly than replication 865 but requires MN activity. It is also slower than replicating LA and RA state 866 due to the time to detect the route failures to the RMA. 868 5.6. Distinguishing LA and RA MIP Messages 870 LA MIP messages and RA MIP messages need to be distinguished from each other 871 in the elements through which they are both forwarded. It may therefore be 872 appropriate to use new MIP messages type fields, flags or extensions for 873 these messages so that the required processing can be cleanly identified. The 874 correct balance between backwards compatibility and forward feature 875 enhancement needs to be determined. However, the following rules show how, 876 without these changes, that an MIP node can distinguish between LA, RA and 877 Combined LA/RA messaging when using standard MIP Registration messages and 878 the regional extensions from [RegTunMods]. 880 LA messages are sent from a zero source address to the FA, and then onto a 881 dynamically allocated RMA. The RMA address may be advertised by the FA and 882 inserted either by the MN into the HA field or by the FA into the HFAIPext. 884 LA messages are subsequently sent from the RoA address to the RMA address via 885 each new FA. The CoA in the message is the FA CoA, which is either entered by 886 the MN or the FA, and can be either shared or MN specific. If the FA adds the 887 CoA then it is inserted into a HFAext and forwarded to the RMA. At each new 888 RMA, the LA must revert to sending the first LA message with a zero source 889 address until the new RoA is known. 891 RA MIP messages are always sent by the MN from the RoA address to the HA with 892 a CoA=RMA CoA which can be either a MN specific CoA (MSCoA=RoA) or an RMA 893 shared CoA (SHCoA). The message is potentially routed via the FA and/or the 894 RMA. 896 The FA can therefore distinguish between LA and RA messages because an LA 897 message will either be sent from a zero source address, or sent from the 898 RoA address with a HA field set to a local RMA. In contrast, RA messages 899 are never sent to the FA with a zero source address and when they are sent 900 from the RoA address they never have a HA field=local RMA because that by 901 definition is an LA MIP message. 903 The RMA can distinguish between LA MIP messages and RA MIP messages by 904 checking the HA (which might be zero) or the HFAIPext of the message. An 905 LA message will have one of these set to the address of the RMA. Otherwise 906 it is an RA message and the HA or HFAIPext will be set to a global HA. 908 A HA is only visited by RA messages and the HA (which might be zero) or 909 HFAIPext will then match the address of the HA. 911 Combined LA/RA messages are only sent during inter-RMA hand-off via a new 912 RMA. They are always sent with a zero source address with the HA field set to 913 either the global HA or the oRMA. 915 The FA can distinguish this from an LA Reg because the HA field is neither 916 zero nor a local RMA at that FA. The FA can distinguish this from an RA 917 Reg because of the zero source address. 919 The nRMA can distinguish this from the LA Reg because the HA field is set 920 and not equal to the nRMA address. The nRMA can distinguish this from a 921 normal RA because the HFAIPext from the FA is included and contains the 922 nRMA address 924 The oRMA/HA can distinguish this from a normal RA or LA message because 925 the HFAIPext and HFAext is included. 927 It is for further study if these rules are sufficient for all scenarios or 928 ideal from an inplementation perspective. Specifically, the RA layer is the 929 standard MIP remote access layer and this should clearly not change MIP 930 message types. A new type for LA layer MIP messages will make RA v LA message 931 detection in the FA and RMA much more efficient with no backwards 932 compatibility consequences because the LA does not presently exist. The RA 933 layer can undertake MIP hand-offs and utilise regional signalling as 934 presently proposed in MIP but only the LA layer will support aggregated 935 regional hand-off, and the RMA discovery and state construction in support of 936 this. A major area of development and standards work is to ensure through LA 937 and RA stack communications and AS, AA message processing that the activities 938 of the two layers are clean and coordinated. This is discussed in section 10. 940 5.7 Summary of MIP Signalling Additions 942 The FAA, LA and RA messages can behave initially very much like existing 943 standard MIP messages in Nested Mode but become more complex as features are 944 added and specifically regional extensions (RA RREQ v3 etc) are supported. 946 5.7.1 Feature selection 948 The LA layer elements all need to agree between options such as; 950 Service mode Is LA service required ? 951 RMA RA forwarding mode Standard, Nested, Concat, GFA for all RA sessions 952 RoA address type Public or private address 953 NAT Option Permitted or barred (for private RoA) 954 FA CoA type MSCoA or SHCoA 956 The LA layer needs to indicate if the MN is seeking local access service and 957 if so whether a private or public RoA is requested. If the RoA is private 958 then the MN can request to also access NAT features to be able to gain public 959 Internet access. This has implications on the reverse tunnelling requirements 960 which are discussed in section 10. The default RA forwarding mode needs to be 961 agreed in advance at the LA layer for all RA sessions above that LA layer so 962 that the correct type of FA CoA can be assigned. This default can be 963 overruled though for a specific RA session at the RA layer potentially 964 causing a change in the type of CoA for all RA sessions (MSCoA instead of 965 SHCoA for example). 967 The RA layer elements need to select and agree between options such as; 969 Service Mode Is RA service required ? 970 RMA RA forwarding mode Standard, Nested, Concat, GFA for one RA session 971 HoA address type Public or private HoA 972 NAT Traversal Option Permitted or Barred (for RA MIP RREQ/RREP) 973 RMA CoA type MSCoA or SHCoA 975 This time it is the RA service layer that is being configured and includes 976 the type of HoA address and RMA CoA, for the specific RA session. If re-using 977 the LA default values then these are merely repeated here. The NAT traversal 978 option is to enable permission for the RA layer registration to traverse a 979 NAT if the RoA is private. This enables the MN to request and the operator to 980 restrict the scope of registration which might be intra or inter-domain. 982 The style extension is used to communicate these various settings and is 983 optionally carried in all Registration messages, as discussed in section 10. 984 If it is absent then the default settings according to either operator policy 985 as modified by the MN profile are applied. The LA layer can include both LA 986 and RA layer stylexts so that the AAA requirements back to the AAAH can be 987 determined in one RTT. In addition, both LA and RA layer stylext can be 988 included in the RA layer for a Combined RA/LA MIP Reg. If the stylext was 989 understood and correctly processed by the FA and RMA then the returned 990 stylext will indicate the RMA/FA capabilities and installed 991 features. The specific type of support at the RMA, is known to the FA, as it 992 shares a close topological and configuration relationship with its RMA(s). 993 The FA can therefore tailor the stylext settings to match the known/learned 994 RMA capabilities before forwarding the LA MIP Reg to the RMA. 996 5.7.2 FAA Modifications 998 The FAA needs to include the FA-NAI and the shared FA CoA for movement 999 detection purposes. The FA-NAI must be structured to indicate the FA, the 1000 region of that FA and the domain of that FA. This is used for inter-region 1001 movement detection in the absence of the 'I' bit being set in the FAA. An FA- 1002 NAI with region information informs a MN that it is capable of at least 1003 Nested Mode. 1005 The FAA needs to additionally indicate through the 'R' bit if the MN should 1006 RA register through the FA for remote access sessions. The MN can then decide 1007 whether to send an RA Reg v1 or RA Reg v2. 1009 The FAA must indicate if regional signalling is supported via the 'I' bit. 1010 The 'I' bit is advertised in FAAs if the FA knows in advance that it has at 1011 least one RMA that supports regional registration. The 'I' bit also indicates 1012 that the FAA contains RMA address information for tracking regional movement. 1013 The 'I' bit is therefore rescoped from [RegTun] and used to indicate to the 1014 MN, in combination with an FA-NAI with region structure, that RA Reg v3, 1015 combined LA/RA Signalling, and GFA/Concatenated Mode are likely supported in 1016 the FA/RMA pair, as well as HFAext and HFAIPext extensions and associated 1017 authentication. 1019 A number of other FAA changes are then required depending on how the LA and 1020 RA layers are implementated. These are discussed in section 10. 1022 5.7.3 Regional Signalling 1024 To support the full range of service and forwarding modes, the following 1025 changes to MIP signalling are required which are outlined in [RegTunMods]. 1027 The LA message needs to be able to be sent with a zero CoA so that the FA can 1028 dynamically allocate a MN specific CoA and insert it into the HFAext when 1029 Concat mode is added. This can be avoided if the FA is alternatively able to 1030 advertise a MN specific CoA to the MN in a unicast FAA when Concat mode is 1031 mandated. The FA must always return the HFAext to the MN in the RREP. 1033 The LA message needs to be sent with a zero HA address so that the FA can 1034 dynamically allocate the RMA, from a set of RMAs, rather than the MN always 1035 using the default RMA that is advertised in the FAA. The FA inserts the 1036 allocated RMA address into the HFAIPext and returns it to the MN in the RREP. 1038 The RA message needs to occasionally be sent with a zero CoA when using Reg 1039 v3 and Combined RA/LA signalling. This is specifically necessary in the case 1040 of Reg v3 for GFA mode. The RMA uses the HFAext to inform both the HA (RREQ) 1041 and the MN (RREP) of the RMA CoA. The GFA CoA can alternatively be generated 1042 in advance of the RA Reg, as a result of the LA layer Registration, with the 1043 RMA returning the GFA CoA to the MN in an HFAext. This is the GFA SHCoA that 1044 is required for GFA mode only. This is because the GFA CoA for Nested and 1045 Concat is the RoA which is already returned in the LA Reply. The GFA CoA 1046 should be suitable for the default RA forwarding mode identified in the LA 1047 Reg. The RA Reg can then generally avoid using a CoA=0 except when the GFA 1048 CoA is HA specific due to disparate addressing plans. For combined 1049 signalling, the GFA CoA is always zero through a new RMA because the GFA CoA 1050 is not known yet for any RA mode. 1052 The HA needs to be able to receive and process HFAext and HFAIPext for 1053 combined LA/RA signalling. 1055 The PFANE and BU semantics for inter-FA hand-off need to be generalised to 1056 support other transient forwarding modes by being able to carry both MN 1057 specific and shared FA CoAs. 1059 The LA and RA layer needs to be able to carry the PRANE extension for inter- 1060 RMA and oRMA-nFA transient forwarding. 1062 The LA and RA layers need to be able to carry the Style extension (stylext). 1063 Specifically, the LA layer must be able to carry both LA and RA stylext so 1064 that a single AAA exchange from the FA can fetch the required state for both 1065 layers. In addition, the RA layer also needs to carry both LA and RA stylext 1066 so that combined signalling is possible at each new RMA. 1068 The LA layer needs to carry a MN-NAI and a MN-AAA auth ext so that the MN can 1069 obtain AAA state via the FA, from the home wireless operator via the local 1070 wireless operator. The RA layer also needs to be able to carry an NAI and AAA 1071 auth to be able to fetch RA session specific state from a third party service 1072 provider that is specifically not the home wireless operator. The discussion 1073 underpinning these requirements are detailed in [NestMIP]. 1075 Other changes are detailed in the text in this draft. 1077 5.8 Backwards Compatibility Issues 1079 5.8.1 General 1081 A legacy FA cannot support this draft without being able to advertise the FA- 1082 NAI and undertaking configuration changes to restructure the FA-NAI scheme. A 1083 compliant MN can detect the difference between a legacy and non-legacy FA by 1084 the FA-NAI structure whilst a legacy MN will either ignore the FA-NAI or 1085 process it and correctly miss the additional regional information in the NAI. 1087 A compliant FA must at least advertise a FA-NAI with the region information, 1088 and must undertake ingress filtering on the dynamically assigned RoA. With 1089 the 'R' bit set, the FA must be able to also support both LA and RA visitor 1090 lists as documented above. This simply means that a single MN must be able to 1091 have two active Registrations with two HAs (the RMA and the global HA). The 1092 FA must then update both LA and RA visitor lists when an LA hand-off occurs. 1094 A legacy MN will not interpret the FAA regional information and therefore 1095 will be unaware of the existence of regions or the ability to undertake two 1096 coordinated LA and RA MIP layers. This MN can undertake standard MIP and 1097 request either LA (local HA) or RA access (global HA) at the RA layer, which 1098 the AAA system may accept. It is likely that the RA layer request might be 1099 refused if the HA is not owned by specific operators, whose HA availability 1100 and performance is trusted, and will most likely be refused if another MIP 1101 session already exists due to issues identified in [ParallelMIP]. 1103 The RMA is a new element and in the basic Nested model with RA RREQ v1/v2 can 1104 be a standard HA that supports dynamic HA and HoA assignment with associated 1105 AAA and security mechanisms. 1107 When the 'I' bit in the FAA is not set, a legacy global HA sees only a 1108 request to forward to a CCoA with the 'D' bit set, and therefore is fully 1109 supported because the HA/HoA/CoA fields will have been populated by the AAA 1110 system and by the LA layer. 1112 For the FA, RMA and the global HA, the following specific issues also occur 1113 when the 'I' bit is advertised to the MN in the FAA. 1115 5.8.2 LA RREQ Zero CoA field (dynamic FA CoA assignment) 1117 The MN should only send a zero CoA in the MIP Reg if the 'I' bit is set which 1118 indicates that the RMA supports this feature. Dynamic FA CoA assignment 1119 requires the FA to send the CoA to the RMA in the HFAext. If the RMA does not 1120 support this (a configuration error condition given the FA-RMA relationship) 1121 then the RREQ will be refused and the HFAext will not be returned to the FA 1122 as confirmation. This will be detected by the FA, which then inserts the 1123 HFAext into the RREP so that the MN can set the FACoA in a second attempt. 1125 5.8.3 RA RREQ zero CoA field (Dynamic RMA CoA Assignment) 1127 The MN should only send this if it believes that the HA supports this 1128 extension. The RMA assigns the CoA and forwards it to the global HA in the 1129 HFAext. If the HA does not support this extension then the HA will fail to 1130 return the HFAext which will be detected by the RMA. The RMA then inserts the 1131 HFAext so that the MN can set the CoA field itself in a second attempt. 1133 5.8.4 LA RREQ zero HA field (dynamic RMA assignment) 1135 The MN can allow the FA to assign the RMA, potentially via the AAA system. If 1136 this is achieved by routing the request through the AAA system, then the RREP 1137 will include the RMA and RoA. If the 'I' bit is set then this can 1138 alternatively be achieved using the HFAIPext. The FA should then return the 1139 HFAIPext including the dynamically assigned RMA to the MN in the RREP if the 1140 RREQ was successful at the RMA. Any local HA (RMA) that supports dynamic 1141 assignment can therefore support LA signalling in some form. 1143 5.9 Signalling and Forwarding Evolution 1145 From an evolutionary perspective, it can be seen that Nested MIP can be 1146 supported with very little changes to MIP standards, with these changes 1147 limited to the co-existance and cooperation between two MIP signalling layers 1148 in the MN, with the FA undertaking ingress filtering checks on the 1149 dynamically assigned RoA (local HoA), and the FA-NAI being structured to 1150 identify the FA as well as the region so that the MN can execute inter-region 1151 hand-offs as well as inter-FA hand-offs. These two MIP layers can next be 1152 exposed to the FA by enabling RA registration via that FA (setting the 'R' 1153 bit) and by adding the RA visitor list to the LA visitor list. The RA layer 1154 MIP stack needs to see FAAs to be able to detect the 'R' bit setting and such 1155 issues are discussed in more detail in section 10. In either case, inter- 1156 region hand-off is supported by using inter-FA transient forwarding and 1157 potentially by oRMA to nFA transient forwarding. Finally, the LA signalling 1158 can be enhanced to support inter-region forwarding from the oRMA to the nFA, 1159 and from the oRMA to the mRMA, using the Previous RMA Notification Extension 1160 (PRANE), and/or existing inter-regional SAs between the oRMA and nFA/nRMA. 1162 Major modifications are however required to MNs, FAs and HAs to enable RA 1163 Registration v3 signalling and efficient combined LA/RA signalling, to enable 1164 the FA to advertise the default RMA address in an FAA, and to enable the FA 1165 to undertake dynamic RMA and FA CoA assignment. Almost all of these changes 1166 are however equivalent to those proposed for Regional Registration {RegTun] 1167 and a common signalling plan should be devised. Once RA Reg v3 is possible 1168 then the HA FA and MN can be extended to support all four types of forwarding 1169 (standard HA, Nested, GFA and Concat) using the Style Extension to indicate 1170 the requested mode. Modifications are then possible in MNs, FAs and HAs to 1171 support the new inter-RMA hand-off extensions to enable hand-off between the 1172 different forwarding models to facilitate incremental and heterogeneous 1173 deployment. 1175 Essentially therefore, this draft documents an evolution of backwards 1176 compatible capabilities as MIP standards are evolved, yielding a flexible 1177 platform where the forwarding and hand-off can be optimised on a per MN, per 1178 region or per operator basis. At all stages, the operator is able to decide 1179 how stateful an element the RMA becomes with the benefit being the improved 1180 bandwidth efficiencies through switching rather than encapsulated forwarding. 1181 The operator is also able to use simple LA and RA signalling with inter-FA 1182 transient forwarding or scale up the LA and/or RA signalling complexity to 1183 first enable oRMA to nFA transient forwarding and finally inter-RMA transient 1184 forwarding. The additional complexity of the signalling improves the 1185 efficiency of the transient forwarding and reduces the burstiness of the RA 1186 layer hand-offs by giving the MN more time to execute these hand-offs. 1187 Restated, the increasing period for RA hand-offs increases the number of RA 1188 sessions that a single MN can maintain. 1190 6. Registration Refresh and Hand-Off Processing 1192 In summary, the LA layer messaging creates and moves the LA visitor list 1193 state between FAs and RMAs during hand-offs. This enables transient 1194 forwarding of the local access traffic on the oRoA. The LA hand-off also 1195 preserves RA layer traffic through transient forwarding by generally making 1196 the RA traffic look like LA traffic on the nRoA, that is valid in the updated 1197 LA visitor list. After transient forwarding ceases, the forwarding for the 1198 oRoA will be lost but the nRoA will then be in place and will be used for new 1199 local access sessions. This will in addition enable traffic to continue to be 1200 forwarded from the oRoA via that nRoA until the RA layer updates occur. The 1201 RA layer hand-off then bypasses the oRMA and can also optionally elevate the 1202 oRMA to global HA status so that any long term sessions on the oRoA can be 1203 maintained. 1205 6.1 LA Refresh 1207 -- LAReg +---+ LAReg +----+ 1208 |MN| --------> |oFA| --------> |oRMA| 1209 -- +---+ +----+ 1211 Figure 7. LA Refresh 1213 This is based on a standard MIP Registration (LA Reg v1) from the MN through 1214 the FA to the assigned RMA (local HA). 1216 This enables the RMA to continue to forward any local access packets arriving 1217 at that RMA, addressed to the RoA, to the stated FA CoA. The basic LA MIP 1218 Registration / Reply is the same for Nested, Concatenated and GFA forwarding 1219 modes. 1221 Major changes between the forwarding modes are only seen during inter-FA, and 1222 inter-RMA LA hand-offs, and of course in RA forwarding. 1224 6.2 LA Hand-off (Inter-FA) 1226 -- +---+ 1227 :MN: |oFA| 1228 -- +---+ 1229 ^ 1230 : � 1231 : MOVE �BU (PFANE) 1232 V � 1233 � 1234 -- LAReg +---+ LAReg +----+ 1235 |MN| --------> |nFA| --------> |oRMA| 1236 -- +---+ +----+ 1238 Figure 8. LA Hand-off 1240 This uses an LA MIP Reg v2 to the present RMA, through the new FA, to update 1241 the FA CoA for the MN specific RoA. This will cause any local access and 1242 remote access traffic for the MN to be redirected to the new FA CoA. The 1243 hand-off can in addition use the mechanisms from [RoutOpt] and [LowLat] to 1244 enable in-flight LA and RA packets, that have been tunnelled towards the old 1245 FA CoA, to be forwarded to the new FA CoA. This exchange can also enable the 1246 MN-FA SA to be context transferred to the nFA. 1248 The Inter-FA LA Hand-off can always be undertaken from a new FA that is 1249 within the region of the present RMA (intra-RMA). It can also be undertaken 1250 from a new FA that is outside the region of the present RMA if that new FA 1251 meets a number of special inter-region hand-off constraints, including having 1252 access to a suitable SA with the present RMA to authenticate the hand-off, 1253 and having a suitable way to authenticate the Binding Updates such as the 1254 PFANE extension. This mechanism would typically only be used if the new FA 1255 did not have an available RMA or access to that RMA was in some way delayed 1256 or constrained. This may well be the case for inter-technology hand-off. 1258 6.2.1 Nested Version (using PFANE) 1260 This LA Regv2 installs a persistent forwarding entry in the oRMA for the old 1261 RoA that points local and remote access packets for that MN to the new FA 1262 CoA. The LA Reg also installs a persistent entry in the newFA for the old RoA 1263 and the PFANE/BU reports the new FA CoA to the old FA for the existing oRoA 1264 to facilitate transient forwarding. Nested transient forwarding is based on 1265 the RoA and is towards the new FA SHCoA. This is the same as existing MIP 1266 specs with the exception that the RoA is being used for LA traffic and all RA 1267 layer sessions (with HoAs). 1269 6.2.2 Concatenated Version (using PFANE for RA RREQ v3 only) 1271 This LA Regv2 installs a forwarding entry in the RMA for the RoA (local and 1272 remote access) that points local and remote access packets for that MN to the 1273 new FA MSCoA and away from the old FA MSCoA. The PFANE installs a persistent 1274 entry in the newFA for the new MSCoA (local and remote access) pointing to 1275 the MN interface from either the oRMA or the oFA. The PFANE triggered BU 1276 causes the old FA to switch local and remote access traffic from the old FA 1277 MSCoA to the new FA MSCoA and forwards to the new FA. This is different to 1278 existing MIP specs but re-uses the same signalling messages. 1280 6.2.3 GFA Version (using PFANE for RA RREQ v3 only) 1282 This is as for Concatenated MIP except that the old and new CoA are FA SHCoAs 1283 and forwarding in the oRMA, oFA and nFA is for the RoA (local access) and the 1284 HoA (remote access). HoA and RoA state is therefore required and transient 1285 forwarding is as per existing MIP specs towards the new FA SHCoA. Note that 1286 the oRMA CoA is a SHCoA and not the oRoA. 1288 6.3 LA Hand-off (Inter-RMA, Inter-FA) 1290 -- +---+ +----+ 1291 :MN: |oFA| |oRMA| 1292 -- +---+ +----+ 1293 ^ 1294 : � 1295 : MOVE �BU(PFANE) 1296 V � 1297 � 1298 -- LAReg +---+ LAReg +----+ 1299 |MN| --------> |nFA| --------> |nRMA| 1300 -- +---+ +----+ 1302 Figure 9. LA Hand-off with PFANE 1304 The inter-RMA, inter-FA LA hand-off is normally be undertaken by sending a LA 1305 MIP Reg v3 to the new RMA, via a new FA (and FA CoA), and in the process 1306 acquiring a new RoA. The hand-off can in addition use the mechanisms from 1307 [RoutOpt] and [LowLat] to enable in-flight packets towards the old FA to be 1308 forwarded to the new FA. Note that the state for the nRoA is not in place 1309 until the RREP returns to the MN. This is fine because no traffic will have 1310 been initiated from the MN to that new local address. In addition, no inter- 1311 RMA forwarding that uses that nRoA is being requested. 1313 The visitor lists must temporarily support both the old RoA and the new RoA 1314 for this to succeed. The host RA/LA stack sees this hand-off as the addition 1315 of a new interface with the new RoA and the subsequent loss of the old 1316 interface with the old RoA. The network driver sees the RMA, FA, FA CoA and 1317 RoA change, deals with relaying of packets sent via the oFA, and also handles 1318 the timing of the interface up and down signals. The nature of the inter-FA 1319 forwarding depends on the capabilities of the old and new FA, as well as the 1320 requested type of RMA forwarding from the newRMA. There are two permutations 1321 that are covered in detail in section 7. 1323 There are nine types of old RMA / new RMA mode combinations with three simple 1324 examples given below but the full nine combinations are analysed in section 9 1325 as part of inter-RMA forwarding. Note that five of these combinations can be 1326 avoided, if GFA deployment does not occur, and hence avoiding the backwards 1327 compatibility requirement. 1329 6.3.1 Nested Version (Nested RMA to Nested RMA using PFANE) 1331 The LA Registration is directed to the new RMA rather than the old RMA. The 1332 new FA SHCoA is of course used to create the binding in the new RMA. The 1333 modified PFANE extension is used to trigger a BU in the newFA back to the 1334 oldFA. This installs a forwarding entry in the oFA that points local and 1335 remote access packets for that MN to the new FA SHCoA. The PFANE installs a 1336 temporary entry in the newFA for the old RoA as well as a new persistent 1337 entry for the new RoA that will be constructed by the LA Reg to the new RMA. 1339 6.3.2 Concatenated Version (Concat RMA to Concat RMA using PFANE) 1341 The LA Reg is as previously described in section 6.2.1. but this time 1342 installs the new FA MSCoA from the new FA into the new RMA. The PFANE 1343 triggered BU installs a forwarding entry in the oFA for the previous oRoA 1344 (local access) and MSCoA (remote access) that points packets for that MN to 1345 the new FA MSCoA. The modified PFANE installs a temporary entry in the newFA 1346 for the old RoA from the oFA (local and remote access), as well as a 1347 persistent entry for the new RoA from CNs (local access) and for the new FA 1348 MSCoA from the nRMA (remote access). 1350 6.3.3 GFA Version (GFA RMA to GFA RMA using PFANE) 1352 This is as for Concatenated MIP except that the old and new FA CoA are shared 1353 and forwarding is for the RoA (local access) and the HoA (remote access). 1355 6.4 Enhanced LA Hand-off (Inter-RMA, Inter-FA) 1357 -- +---+ +----+ 1358 :MN: |oFA| |oRMA| 1359 -- +---+ +----+ 1360 ^ / ^ 1361 : � / � 1362 : MOVE �BU(PF) / �BU (PRANE) 1363 V � /BU(PRANE)� 1364 � / � 1365 -- LAReg +---+ LAReg +----+ 1366 |MN| --------> |nFA| --------> |nRMA| 1367 -- +---+ +----+ 1369 Figure 10. LA hand-off with PRANE 1371 The inter-RMA, inter-FA LA hand-off in 6.2 can be enhanced by the MN 1372 including a Previous RMA Notification Extension (PRANE) in the LA Reg along 1373 with the PFANE (PF) (creating an LA Reg v4). The nFA can send an 1374 authenticated BU to the oRMA to facilitate inter-region transient forwarding 1375 from the oRMA (to the nFA) instead of simply relying on the more expensive 1376 (latency, bandwidth) inter-FA forwarding. 1378 The MN pre-calculates the BU authentication for the nFA in a similar manner 1379 to that used for PFANE in [RoutOpt]. This forwarding relies on the existing 1380 MN-oRMA SA and ensures that the oRMA can safely redirect the forwarding away 1381 from the oFA to the nFA. The constraints on this are covered in section 10, 1382 with the transient forwarding shown in section 8. 1384 If the nRMA shares an authenticating SA with the oRMA, then the PRANE can 1385 trigger the nRMA to issue a BU to the oRMA on behalf of the MN with the BUack 1386 again being returned to the MN. The SA is required to authenticate the 1387 dynamically allocated RMA CoA that must be added by the nRMA as it cannot be 1388 known in advance by the MN and hence authenticated. This SA also enables the 1389 oRMA to forward the MN-RMA SA and the oRMA-HA SAs to the nRMA as part of the 1390 hand-off. This inter region SA will be common within an operators domain and 1391 may be even be available across operator boundaries to ensure that inter-RMA 1392 traffic is exposed to inter-operator policy in the core of the network, and 1393 to minimise the need for extensive inter-FA inter-operator security 1394 configuration. In the latter case, the short period of inter-FA forwarding 1395 across operator boundaries could be enabled simply on the PFANE and in 1396 advance of the authentication check for the MN in the new operators domain. 1398 Note that the state for forwarding the nRoA is not fully in place until the 1399 RREP returns to the MN, because the nRoA was not in the RREQ. This is fine 1400 because no traffic will have been initiated from the MN to that new local 1401 address. In addition, any inter-RMA forwarding that uses that nRoA is being 1402 requested by a BU whilst the RMA returns the RREP to the MN. The nRMA does 1403 not therefore wait for the result of the BU as the MN will see the BUack 1404 itself and any failure will be compensated by the other forms of inter-region 1405 forwarding. There may be a requirement to slightly delay the forwarding by 1406 the oRMA towards the nRMA using the nRMA to ensure that the RREP has reached 1407 the MN. This dependence on the RREP being received is a specific week point 1408 in the design and is not generally applicable to GFA forwarding when it uses 1409 a known GFA CoA in the RREQ. Other strategies to overcome this can therefore 1410 include using a GFA SHCoA instead of the nRoA for transient forwarding of 1411 traffic on the oRoA, but this is not further detailed here as the 1412 cost/benefit of this needs further assessment. 1414 Another technique might be to modify the BUack so that in this case it 1415 contains the nRoA and not the oRoA, and hence can enable the MN to resend the 1416 RREQ for the nRMA, nRoA pair, if received before the RREP, to ensure the 1417 visitor list entries are in place. 1419 6.5 RA Layer Registration Update 1421 The MN populates the CoA field with the RoA (Nested, Concat) that was 1422 assigned at the LA layer to create a CCoA and sets the 'D' bit. In the case 1423 of GFA mode, the RMA SHCoA (GFA) is instead used and the 'D' bit is not set. 1424 The message is directed to the HA for the HoA of the Remote Access session 1425 via a range of routes as discussed below. 1427 6.5.1 RA RREQ v1 (Nested only) 1429 -- RAReg +----+ 1430 |MN| ------------------------------------------> | HA | 1431 -- +----+ 1433 Figure 11. RA Reg v1 1435 This uses a standard MIP Registration with the MN populating the HA/HoA 1436 fields with its statically assigned address information from the home subnet, 1437 or using MIP to dynamically assign those elements. The MN then forwards the 1438 MIP Reg directly to the global HA with the 'D' bit set. Forwarding by the HA 1439 is into a tunnel with the RoA as a destination address, and the RMA adds an 1440 additional tunnel to forward to the present FA CoA. This is default Nested 1441 MIP forwarding. 1443 The Style Extension is optionally be used here to overrule the default RA 1444 forwarding mode that was agreed at the LA layer. 1446 The RA visitor list is maintained in the MN to ensure that packets for the 1447 HoA are only received from the registered HA. There is no RA visitor list in 1448 the FA because the FA is not visited by the Registration signalling. This 1449 means however that injected packets towards the HoA, from illegal 'HA' 1450 sources can only be detected at the MN and after consuming backhaul and air- 1451 link resources. The operator can however configure a firewall in the FA to 1452 snoop packets and to therefore indirectly control allowed packet flows. 1454 6.5.2 RA RREQ v2 (Nested Only) 1456 -- RAReg +---+ RAReg +----+ 1457 |MN| --------> :oFA: -------------------------> | HA | 1458 -- +---+ +----+ 1460 Figure 12. RA Reg v2 1462 This uses a standard MIP CCoA Registration via the FA. The FA forwarding 1463 option can be used by the MN when the FA indicates support for this by 1464 setting the 'R' bit in the FAA. The 'R' bit is not specific to Nested MIP and 1465 therefore a MN should not assume that the 'R' bit signifies support for the 1466 Nested MIP feature. This can only be discovered through the processing of the 1467 Style Extension at the LA layer. The stylext can be included at the RA layer 1468 to control RA service features. If the Stylext is missing or ignored, then 1469 the Registration looks like a standard remote access registration with a CCoA 1470 via an FA, and no Nested MIP specific additional features will be invoked. 1472 The RA visitor list is again maintained in the MN to ensure that packets for 1473 the HoA are only received in the MN from the correct HA, via the correct FA. 1474 The RA visitor list in the FA can check that the RoA flow arrived from the 1475 correct RMA source address. 1477 The RA visitor list in the FA can optionally check to make sure that the HoA 1478 within the RoA flow was originally sent from the correct HA, and that the RoA 1479 and HoA are owned by the same MN. This enables some falsely injected packets, 1480 from unknown remote access gateways, to be removed before they consume air- 1481 link resources. However, this HoA specific state must then be maintained 1482 using Context Transfer, triggered by aggregated LA MIP Reg signalling, to 1483 survive inter-FA hand-off. 1485 6.5.3 RA RREQ v3 (Nested, Concat or GFA) 1487 -- RAReg +---+ RAReg +----+ or RAReg +----+ 1488 |MN| --------> :oFA: --------> :oRMA: --------> | HA | 1489 -- +---+ +----+ +----+ 1491 Figure 13. RA Reg v3 1493 This re-uses a similar model to the Home MIP Registration from [RegTun] as 1494 modified by [RegTunMods] and is available if the 'I' bit is set in the FAA. 1496 The MN forwards the MIP Reg to the FA as a result of the 'R' bit. The FA then 1497 makes an operator policy decision, based on the LA layer state, the RA Reg 1498 contents as well as operator and MN specific AAA state, whether to forward 1499 via the RMA (v3) or whether to send directly to the HA (v2). If the RREG is 1500 routed via the RMA then the full range of forwarding models are possible. 1502 The Style Extension is optionally used here simply for the MN to request a 1503 non default RA service features, as opposed to simply relying on the features 1504 in the MN AAA profile, and the forwarding mode agreed at the LA layer. 1506 The RA visitor list is maintained in the MN, and may be maintained in the FA 1507 and the RMA based on operator policy. These visitor lists act to ensure that 1508 packets for the HoA are only received in the MN from the correct HA. The 1509 checks in the FA and RMA minimize opportunities for falsely injected packets 1510 from consuming expensive backhaul and air-link resources. 1512 6.6 RA Hand-off (inter-RMA, optionally inter-FA) 1514 -- +---+ +----+ 1515 :MN: |oFA| |oRMA| 1516 -- +---+ +----+ 1517 ^ 1518 : | 1519 : MOVE | RAReg 1520 V | 1521 | 1522 -- RAReg +---+ RAReg +----+ or RAReg +----+ 1523 |MN| --------> :nFA: --------> :nRMA: --------> | HA | 1524 -- +---+ +----+ +----+ 1526 Figure 14. RA Reg v3 Hand-off 1528 The LA MIP hand-off configures the new RMA/RoA and installs the inter-region 1529 forwarding (inter-FA, inter-RMA and/or RMA->FA) for the RA MIP updates. 1531 The RA MIP Reg is then used, to each HA with which the MN has a remote access 1532 session, to update the CCoA (the RoA) of the HoA used for that session. 1534 In either the HA=oRMA or global HA cases, the CCoA (which was the old RoA 1535 from the old RMA), is replaced with the new RoA from the new RMA in the RA 1536 Reg. The updated visitor list in the HA causes remote access packets to now 1537 bypass the old RMA and instead be routed directly to the new RMA by using the 1538 nRoA. Here it will be handled by the RA visitor list installed by the RA 1539 hand-off message. If the RA hand-off is directed at the oRMA then it prepares 1540 the old RMA/RoA for continued use via remote access to the nRoA address. 1542 This is only possible if the oRMA-nRMA or the HA-nRMA share or can generate 1543 an authenticating SA to protect the extensions between these elements. These 1544 can be acquired from the AAA system based on the optional local and home AAA- 1545 NAIs, or the HA-RMA SA can be CTed from the oRMA at the LA layer if an RMA- 1546 RMA SA is in place, and the RMA-RMA SA can be manually or automatically 1547 configured in sympathy with the RMA LA hand-off neighbours. 1549 The RA MIP hand-off does not need to immediately follow the LA MIP hand-off 1550 for the following reasons. 1552 If the RA MIP hand-off was preceded by an LA MIP Reg v4 then inter-RMA 1553 forwarding will be valid for a significant number of inter-FA hand-offs in 1554 the new region. The MN can therefore distribute the RA MIP signalling load 1555 (across potentially multiple remote access sessions), and refresh them in 1556 order of the remaining lifetimes of the visitor list entries. Inter-FA 1557 forwarding in this case is only needed to forward the packets that are in- 1558 flight between the old RMA and the old FA, to the new FA. This is because 1559 in-flight packets between the HA and the old RMA will instead use inter- 1560 RMA forwarding. Note that if oRMA -> nFA forwarding is in place then the 1561 MN will preferably need to execute all of its RA MIP hand-offs before 1562 another two inter-FA hand-offs occur to avoid any inter-FA chaining. 1564 If the RA MIP hand-off was preceded by a LA MIP Regv3 then no inter-RMA 1565 forwarding will be in place but there will still be inter-FA forwarding. 1566 In this case the MN will preferably need to execute all of its RA MIP 1567 hand-offs before another inter-FA hand-off occurs to avoid any chaining. 1569 Methods for improving the speed of RA updates are discussed in section 10. 1571 6.7 Combined LA/RA Hand-off (for the oRMA) 1573 -- +---+ +----+ 1574 :MN: |oFA| |oRMA| 1575 -- +---+ +----+ 1576 ^ ^ 1577 : � � 1578 : MOVE �BU (PFANE) �CReg 1579 V � � 1580 � � 1581 -- CReg +---+ CReg +----+ 1582 |MN| --------> |nFA| --------> |nRMA| 1583 -- +---+ +----+ 1585 Figure 15. Combined RA/LA v1 1587 Combined LA/RA Signalling is a basic feature of this draft when the 'I' bit 1588 is set in the FAA (for HFAIPext and HFAext support) and no additional flags 1589 or extension mechanisms are required to support it. New error codes may be 1590 appropriate though but this is for further study. 1592 The LA layer is typically used to dynamically acquire the RMA and the RoA at 1593 each RMA, to trigger the fetching of the MN AAA profile, to negotiate the RA 1594 forwarding mode and to agree the access mode. The RA layer can also undertake 1595 this LA processing automatically by the FA using the HFAIPext (that is used 1596 in GFA) to inform the MN of the assigned RMA, and the HFAext can be used to 1597 carry the RMA CoA to the HA and the MN. 1599 This particular Combined Registration is based on a combination of a LA MIP 1600 Reg v3 and an RA MIP Reg v3. This Registration is routed via the new FA and 1601 the new RMA to the old RMA. The CoA in the oRMA, for forwarding to the nRMA, 1602 is the nRoA if Nested or Concat mode is requested at the nRMA. In GFA mode, 1603 this CoA is generally a nRMA SHCoA. The Combined LA/RA MIP Reg is routed via 1604 the new RMA to enable dynamic allocation of the new RoA. It is then sent to 1605 the old RMA to transition the oRMA into the RA layer and thereby become a 1606 global HA/HoA pair for the oRoA local address. This also cancels the LA 1607 forwarding in the oRMA towards the oFA CoA. The Combined LA/RA Reg therefore 1608 initialises persistent forwarding of LA traffic on the oRoA to the nRMA. This 1609 forwarding is then subsequently maintained using RA MIP messages as with any 1610 RA session. 1612 The Combined LA/RA Reg also initializes transient forwarding towards the 1613 nRMA, for remote access traffic from other global HAs sent towards the oRMA. 1614 This transient forwarding continues for the lifetime of the temporary binding 1615 signalled by the Reg. The precise mechanism for this forwarding depends on 1616 the nature of the existing and new registrations (Nested, Concat or GFA) and 1617 is discussed in section 9. A stylext should be used for both the LA and RA 1618 layers to indicate the required features in each layer away from the default 1619 features of this draft. 1621 The message routing to the oRMA via the nRMA requires the two RMAs to share a 1622 preconfigured or dynamically allocated security association to authenticate 1623 the message exchanges. The nRMA only forwards the message to the oldRMA if it 1624 has such an association otherwise the Combined LA/RA Reg fails to update the 1625 oRMA but still returns the LA MIP Reg state from the nRMA in an LA MIP RREP, 1626 returning the identification field from the RREQ. 1628 Note that if the inter-RMA forwarding relies on the nRoA then it is correctly 1629 installed by the RREQ in the nRMA and oRMA, but will not yet have been 1630 installed in the nFA because this nRoA address was not in the RREQ until it 1631 reached the oRMA where the nRoA is assigned. The oRMA must not therefore 1632 start forwarding via the nRMA until sufficient time is given for the RREP to 1633 return to the nFA via the nRMA. It is therefore preferable for the nRMA LA 1634 layer to immediately send a RREP and then have the RA layer send a second 1635 RREP from the oRMA in response to the Combined RREQ (although Identification 1636 field issues have yet to be addressed here). 1638 6.8 Combined RA/LA Hand-off (for other global HAs) 1640 -- +---+ +----+ 1641 :MN: |oFA| |oRMA| 1642 -- +---+ +----+ 1643 ^ ^ 1644 : � � 1645 : MOVE �BU (PFANE) �BU (PRANE) 1646 V � � 1647 � � 1648 -- CReg +---+ CReg +----+ CReg +----+ 1649 |MN| --------> |nFA| --------> |nRMA| --------> | HA | 1650 -- +---+ +----+ +----+ 1652 Figure 16. Combined RA/LA Reg v2 1654 This is a combination of an LA Reg v4 and an RA Reg v3. It is used when only 1655 transient forwarding is required from the oRMA for local and remote access 1656 traffic. A stylext should be used for both the LA and RA layers to indicate 1657 the required features in each layer away from the default features of this 1658 draft. Note that there is a risk that forwarding to a distant HA like this 1659 could result in an extended delay for the return of the combined Reg reply 1660 and the associated LA parameters for the LA hand-off. However, during this 1661 time, inter-RMA and inter-FA forwarding will continue for the oRoA. 1663 The oRoA is lost once the transient forwarding has finished on the expiry of 1664 the BU lifetime that is known to the MN. The oRMA in this case does not 1665 transition to become a global HA and the oRoA does not become another HoA for 1666 the MN. The target HA for the Combined RA/LA Reg can be any HA whether or not 1667 it is presently an active RA session for the MN. The MN selects the target HA 1668 based on local preference. 1670 The security requirements are as for the component LA and RA messages 1671 although the fact that the messages are combined places greater emphasis on 1672 the need for a pre-configured RMA-RMA SA to be in place to avoid a AAA look- 1673 up delaying any hand-off. 1675 Once again, if the RA aspects of the Combined Reg fails then the LA Reg 1676 aspects should still complete if possible, leaving in place an LA v4 hand-off 1677 with transient forwarding. The converse is not applicable because if the LA 1678 fails to the new RMA then the RA layer can also not complete as defined. 1680 Once again, the FA visitor list state for the nRoA is not in place until the 1681 RREP returns with that address. The GFA SHCoA, BU ack and the RREP solutions 1682 from the nRMA can be again used here to assist in avoiding packets being 1683 forwarded towards a black-hole. 1685 7. Summary of Inter-FA Forwarding during Hand-off 1687 The Inter-FA transient forwarding can be initiated using any mechanism 1688 associated with an MIP inter-FA hand-off from [LowLat] or [RoutOpt]. The 1689 below analysis assumes a PFANE triggered BU as in [RoutOpt] is used, being 1690 sent from the nFA to the oFA, pre-authenticated by the MN. This can be 1691 associated with an LA MIP RREQ v2,v3 or v4. 1693 For LA MIP RREQ v2, which is never used for an inter-RMA hand-off, the RMA 1694 forwarding mode is unchanged and so the BU does not need to indicate the nRMA 1695 forwarding mode. For LA MIP RREQ v3 and v4, the BU also does not need to 1696 inform the old FA of the nFA forwarding model because the only change is that 1697 the nFA CoA is either a SHCoA or a MSCoA. 1699 7.1 Transient forwarding for standard FA CoA switching 1701 CN HA oRMA oFA nFA MN 1703 Forward oLA CN----------------------------------------------------->oRoA 1704 oRMA===>oFACoA x oFA===>nSHCoA 1705 Forward RA CN------------------------------------------------------>HoA 1706 HA==========================================>oRoA 1707 oRMA===>oFACoA x oFA===>nSHCoA 1709 Figure 17. FA CoA switching 1711 The oFA decapsulates from the oFACoA inspects its binding cache for the 1712 oRoA(Nested), oRoA+HoA(GFA), or incoming oMSCoA. This identifies the nFA and 1713 so the oFA re-encapsulates into the nFA SHCoA. The nFA must then have visitor 1714 list state for the oRoA (Nested) or oRoA+HoA (GFA) so that the arriving 1715 packets can be forwarded to the correct MN. Note that when moving to or from 1716 an FA that does not support Nested or Concat MIP, nor even supports RMAs, the 1717 inter-FA forwarding is still installed towards the FA SHCoA due to the BU 1718 being unchanged by this draft. Forwarding is only changed at the nFA 1719 supporting Concat mode and only when moving to that nFA. 1721 7.2 Transient forwarding for Concat CoA switching 1723 CN HA oRMA oFA nFA MN 1725 Forward oLA CN----------------------------------------------------->oRoA 1726 oRMA===>oFACoA x oFA===>nMSCoA 1727 Forward RA CN------------------------------------------------------>HoA 1728 HA============================================>oRoA 1729 oRMA===>oFACoA x oFA===>nMSCoA 1731 Figure 18. Concat CoA Switching 1733 The oFA decapsulates from the oFACoA inspects its binding cache for the 1734 oRoA(Nested), HoA(GFA), or incoming oMSCoA. This identifies the nFA and so 1735 the oFA re-encapsulates into the nFA MSCoA. The nFA must then have visitor 1736 list state for the nFA MSCoA so that the arriving packets can be forwarded to 1737 the correct MN. 1739 8. Summary of Inter-Region Transient Forwarding (oRMA->nFA) 1741 When a MN is equipped with an LA MIP v4 (PRANE capability) then it can 1742 register with the nRMA and can in addition send a BU from the nFA to the oRMA 1743 to instigate inter-region forwarding. Inter-region forwarding from the oRMA 1744 to the nFA is more efficient (bandwidth, latency) which improves performance 1745 and reduces the load on expensive access circuits. 1747 The oRMA encapsulates LA packets sent to the oRoA into the nFA CoA. The oRMA 1748 also encapsulates RA packets into the nFA CoA, sent from the HA to either the 1749 oRoA (nested/concat) or the RMA SHCoA (GFA). The nFA does not yet know the 1750 agreed nRMA forwarding mode and so should request Nested mode which is 1751 supported by all RMAs and FAs. This also ensures that the MN can insert the 1752 FA SHCoA into the PFANE and calculate the authenticator for the BU which it 1753 could not do with a dynamically allocated FA MSCoA. The oRMA knows that such 1754 all BUs from nFAs are for Nested forwarding and knows its own forwarding 1755 mode. This means that once again the BU does not need to deal with signalling 1756 the nFA mode. 1758 8.1 Transient forwarding from Nested oRMA to Nested nFA 1760 CN HA oRMA oFA nFA MN 1762 Forward oLA CN----------------------------------------------------->oRoA 1763 oRMA================>nSHCoA 1764 Forward RA CN------------------------------------------------------>HoA 1765 HA===========================================>oRoA 1766 oRMA================>nSHCoA 1768 Figure 19. Nested to Nested inter-region forwarding 1770 The oRMA receives the BU containing the nFA CoA and the oRoA and encapsulates 1771 traffic sent to the oRoA, into the nFA SHCoA based on the RoA state in the RA 1772 visitor list. Both LA and RA traffic arrives at the nFA and is forwarded 1773 based on the oRoA. 1775 8.2 Transient forwarding from Concat oRMA to Nested nFA 1777 CN HA oRMA oFA nFA MN 1779 Forward oLA CN----------------------------------------------------->oRoA 1780 oRMA================>nSHCoA 1781 Forward RA CN------------------------------------------------------>HoA 1782 HA==>oRoA x oRMA==============================>nRoA 1783 oRMA================>nSHCoA 1785 Figure 20. Concat to Nested Inter-region forwarding 1787 The oRMA receives the BU containing the nFA CoA and the oRoA and switches 1788 traffic from the HA to the oRoA, into a tunnel from oRMA to the oRoA, based 1789 on the RA visitor list state. The oRMA then encapsulates this into the nFA 1790 SHCoA based on the RoA state in the LA visitor list. 1792 8.3 Transient forwarding from GFA oRMA to Nested nFA 1794 CN HA oRMA oFA nFA MN 1796 Forward oLA CN----------------------------------------------------->oRoA 1797 oRMA================>nSHCoA 1798 Forward RA CN------------------------------------------------------>HoA 1799 HA==>oRMA x oRMA==============================>oRoA 1800 oRMA================>nSHCoA 1802 Figure 21. Concat to Nested Inter-region forwarding 1804 This is as for Concat except that the traffic is received on the oRMA SH CoA, 1805 and the RA visitor list contains HoA state as well as RoA state. 1807 9. Summary of Inter-RMA Transient Forwarding during Hand-off 1809 Inter-RMA transient forwarding is between two regional nodes rather than 1810 between two edge FA nodes or a combination of RMA and FA. This is useful 1811 because it is more scalable for neighboring regional nodes to share pre- 1812 configured SAs and policies to secure and control the inter-regional 1813 forwarding. It also enables early exposure to the policing, QoS and 1814 accounting controls in the newRMA. The use of inter-RMA forwarding is also 1815 useful during inter-domain handoffs where inter-operator service and 1816 accounting policies need to applied. Finally, the transient forwarding can be 1817 for a significant amount of time due to the much slower hand-off dynamics at 1818 that layer, during which the MN can issue multiple RA MIP hand-offs to 1819 multiple other global HAs to update them with the new RoA address. 1821 The Inter-RMA transient forwarding can be initiated using either a BU from 1822 the nRMA to the oRMA as part of an LA MIP RREQ v4, or by using an RA MIP RREQ 1823 v3 to the oRMA via the nRMA after an LA MIP RREQ v3. The following examples 1824 assume an LA MIP RREQ v4 and cover the combinations from and to Nested and 1825 Concat RA layer forwarding modes in the old and new RMA. The examples are 1826 without proxy CCoAs and therefore with encapsulation over the air interface 1827 and only the forward directions are shown in a futile attempt for brevity. 1829 9.1 Nested to Nested using Nested inter-RMA transient forwarding 1831 CN HA oRMA nRMA FA MN 1832 a) 1833 Forward oLA CN----------------------------------------------------->oRoA 1834 oRMA================>oSHCoA 1835 Forward RA CN------------------------------------------------------>HoA 1836 HA===========================================>oRoA 1837 oRMA================>oSHCoA 1838 b) 1839 Forward oLA CN----------------------------------------------------->oRoA 1840 oRMA============================>nRoA 1841 nRMA===>nSHCoA 1842 Forward RA CN------------------------------------------------------>HoA 1843 HA===========================================>oRoA 1844 oRMA============================>nRoA 1845 nRMA===>nSHCoA 1846 c) 1847 Forward nLA CN----------------------------------------------------->nRoA 1848 nRMA===>nSHCoA 1849 Forward RA CN------------------------------------------------------>HoA 1850 HA===========================================>nRoA 1851 nRMA===>nSHCoA 1853 Figure 22. Forwarding for Nested to Nested via Nested 1855 a)Before LA Hand-off in the oFA/oRMA 1856 The local access traffic (CN:oRoA) is being encapsulated into the oFA SHCoA 1857 and then the oFA is decapsulating and forwarding to the MN using the oRoA. 1858 Any remote access (HA:oRMA[CN:HoA]) is being encapsulated into the oFA SHCoA 1859 and then the oFA is decapsulating and forwarding to the MN using the oRoA. 1860 Note that the FA could also be decapsulating the oRoA header to check for 1861 registered HA/HoAs if the FA optionally has HA/HoA specific processing. 1863 For LA Hand-off. 1864 The LA MIP Reg v4 sends the information to the nRMA, and a BU to the oRMA. 1865 The LA Reg (nest) prepares the nFA to decapsulate packets from the nFA SHCoA 1866 and forward nRoA and oRoA traffic to the MN (new state). The LA Reg (nest) 1867 prepares the nRMA to encapsulate packets sent to the nRoA (from CNs and oRMA) 1868 into the nFA SHCoA (new state, oRMA undertaking HA check). The inter-RMA BU 1869 (nest) prepares the oRMA to encaps packets sent to the oRoA (from CNs and 1870 registered HAs) into the nRoA and to cancel forwarding to the oFA SHCoA. All 1871 packets now go from the oRMA to the nRMA, to the nFA, to the MN as in (b). 1873 For RMA Hand-off 1874 MN now leisurely sends an RA Reg (Nest) for each HoA/HA pair via nFA/nRMA. 1875 The RA Reg (nest) prepares the nFA to decapsulate packets from the nFA SHCoA 1876 and forward any RoAs to the MN (note FA already doing this). The RA Reg 1877 (nest) prepares the nRMA to encapsulate packets from registered HAs to the 1878 nRoA, into the nFA SHCoA. (nRMA now doing HA check). The RA Reg (nest) 1879 prepares the HA to encapsulate packets to the HoA into the nRoA instead of 1880 into the oRoA (new state for oRMA bypass). 1882 c) After RA Hand-off completion 1883 HoA packets are encapsulated into the nRoA in the HA. Packets to the nRoA are 1884 encapsulated into the nFA SHCoA in the nRMA. Packets to the nFA SHCoA are 1885 decapsulated in the nFA, the nRoA inspected and the packets sent to the MN. 1887 9.2 Nested to Concat using a Concat inter-RMA transient forwarding 1889 CN HA oRMA nRMA FA MN 1890 a) 1891 Forward oLA CN----------------------------------------------------->oRoA 1892 oRMA================>oSHCoA 1893 Forward RA CN------------------------------------------------------>HoA 1894 HA==========================================>oRoA 1895 oRMA================>oSHCoA 1896 b) 1897 Forward oLA CN----------------------------------------------------->oRoA 1898 oRMA==>nRoA x nRMA==>nMSCoA 1899 Forward RA CN------------------------------------------------------>HoA 1900 HA==========================================>oRoA 1901 oRMA==>nRoA x nRMA==>nMSCoA 1902 c) 1903 Forward nLA CN----------------------------------------------------->nRoA 1904 nRMA==>nMSCoA 1905 Forward RA CN------------------------------------------------------>HoA 1906 HA=================>nRoA x nRMA==>nMSCoA====>nRoA 1908 Figure 23. Forwarding for Nested to Concat via Concat 1910 a)Before LA Hand-off in the oFA/oRMA 1911 The local access traffic (CN:oRoA) is being encapsulated into the oFA SHCoA 1912 and then the oFA is decapsulating and forwarding to the MN using the oRoA. 1913 Any remote access (HA:oRMA[CN:HoA]) is being encapsulated into the oFA SHCoA 1914 and then the oFA is decapsulating and forwarding to the MN using the oRoA. 1915 Note that the FA could also be decapsulating the oRoA header to check for 1916 registered HA/HoAs if the FA optionally has HA/HoA specific processing. 1918 For LA Hand-off 1919 The LA MIP Reg v4 (concat) sends the information to the nRMA, and a BU to the 1920 oRMA. The LA Reg (concat) prepares the nFA to decapsulate packets from the 1921 nFA MSCoA and forward oRoA, nRoA and HoA traffic to the MN that owns that 1922 MSCoA (new state). The LA Reg (concat) prepares the nRMA to encapsulate 1923 packets sent to the nRoA (from CNs) and to switch packets sent to the nRoA 1924 (from the oRMA), into the nFA MSCoA (new state, oRMA undertaking HA check). 1925 The inter-RMA BU (nest) prepares the oRMA to encaps packets sent to the oRoA 1926 (from CNs and registered HAs) into the nRoA and to cancel forwarding to the 1927 oFA SHCoA. All packets now go via the oRMA, nRMA, the nFA and the MN (b). 1929 For RMA Hand-off 1930 MN now leisurely sends an RA Reg (Concat) for each HoA/HA pair via nFA/nRMA. 1931 The RA Reg (concat) prepares the nFA to decapsulate packets from the nFA 1932 MSCoA and forward any oRoA, nRoA and HoAs to the MN that owns that MSCoA 1933 (note FA already doing this). 1935 The RA Reg (concat) prepares the nRMA to encapsulate packets from registered 1936 HAs sent to the nRoA, into the nFA MSCoA (nRMA now doing HA check). The RA 1937 Reg (concat) prepares the HA to encapsulate packets to the HoA into the nRoA 1938 instead of into the oRoA (new state for oRMA bypass). 1940 c) After RA Hand-off completion 1941 HoA packets are encapsulated into the nRoA in the HA. In the nRMA, packets to 1942 the nRoA from registered HAs are then switched into the nFA MSCoA. Packets to 1943 the nRoA from CNs are encapsulated by the nRMA into the nFA MSCoA. 1944 Registering via the RMA is therefore beneficial to the operator because of 1945 the reduced encapsulation. The nFA decapsulates from the FA MSCoA, identifies 1946 the target MN that owns that MSCoA, and the packets are then sent to the MN. 1948 9.3 Concat to Concat using Concat inter-RMA transient forwarding 1950 CN HA oRMA nRMA FA MN 1951 a) 1952 Forward oLA CN----------------------------------------------------->oRoA 1953 oRMA================>oMSCoA 1954 Forward RA CN------------------------------------------------------>HoA 1955 HA===>oRoA x oRMA================>oMSCoA===>oRoA 1956 b) 1957 Forward oLA CN----------------------------------------------------->oRoA 1958 oRMA==>nRoA x nRMA==>nMSCoA 1959 Forward RA CN------------------------------------------------------>HoA 1960 HA===>oRoA x oRMA==>nRoA x nRMA==>nMSCoA===>nRoA 1961 c) 1962 Forward nLA CN----------------------------------------------------->nRoA 1963 nRMA==>nSHCoA 1964 Forward RA CN------------------------------------------------------>HoA 1965 HA=================>nRoA x nRMA==>nMSCoA===>nRoA 1967 Figure 24. Forwarding for Concat to Concat via Concat 1969 a)Before LA Hand-off in the oFA/oRMA 1970 The local access traffic (CN:oRoA) is being encapsulated into the oFA MSCoA 1971 and then the oFA is decapsulating and forwarding to the MN using that 1972 oMSCoA/oRoA. Any remote access (HA:oRMA[CN:HoA]) is being encapsulated into 1973 the oFA MSCoA and then the oFA is decapsulating and forwarding to the MN 1974 using the oMSCoA. Note that the FA could also be decapsulating the oRoA 1975 header to check for registered HA/HoAs if the FA optionally has HA/HoA 1976 specific processing. 1978 For LA Hand-off 1979 The LA MIP Reg v4 (concat) sends the information to the nRMA, and a BU to the 1980 oRMA. The LA Reg (concat) prepares the nFA to decapsulate packets from the 1981 nFA MSCoA and forward oRoA, nRoA and HoA traffic to the MN that owns that 1982 MSCoA (new state). The LA Reg (concat) prepares the nRMA to encapsulate 1983 packets sent to the nRoA (from CNs) and to switch packets sent to the nRoA 1984 (from the oRMA), into the nFA MSCoA (new state, oRMA undertaking HA check). 1985 The inter-RMA BU (nest) prepares the oRMA to encaps packets sent to the oRoA 1986 (from CNs and registered HAs) into the nRoA and to cancel forwarding to the 1987 oFA MSCoA. All packets now go via the oRMA, nRMA, the nFA and the MN (b). 1989 For RMA Hand-off MN now leisurely sends an RA Reg (Concat) for each HoA/HA 1990 pair via nFA/nRMA. The RA Reg (concat) prepares the nFA to decapsulate 1991 packets from the nFA MSCoA and forward any oRoA, nRoA and HoAs to the MN that 1992 owns that MSCoA (note FA already doing this). The RA Reg (concat) prepares 1993 the nRMA to encapsulate packets from registered HAs sent to the nRoA, into 1994 the nFA MSCoA (nRMA now doing HA check). The RA Reg (concat) prepares the HA 1995 to encapsulate packets to the HoA into the nRoA instead of into the oRoA (new 1996 state for oRMA bypass). 1998 c) After RA Hand-off completion 1999 HoA packets are encapsulated into the nRoA in the HA. In the nRMA, packets to 2000 the nRoA from registered HAs are then switched into the nFA MSCoA. Packets to 2001 the nRoA from CNs are encapsulated by the nRMA into the nFA MSCoA. 2002 Registering via the RMA is therefore beneficial to the operator because of 2003 the reduced encapsulation. The nFA decapsulates from the FA MSCoA, identifies 2004 the target MN that owns that MSCoA, and the packets are then sent to the MN. 2006 9.4 Concat to Nested using Nested inter-RMA transient forwarding 2008 CN HA oRMA nRMA FA MN 2009 a) 2010 Forward oLA CN----------------------------------------------------->oRoA 2011 oRMA================>oMSCoA 2012 Forward RA CN------------------------------------------------------>HoA 2013 HA===>oRoA x oRMA================>oMSCoA===>oRoA 2014 b) 2015 Forward oLA CN----------------------------------------------------->oRoA 2016 oRMA===========================>nRoA 2017 nRMA===>nSHCoA 2018 Forward RA CN------------------------------------------------------>HoA 2019 HA===>oRoA x oRMA===========================>nRoA 2020 nRMA===>nSHCoA 2021 c) 2022 Forward nLA CN----------------------------------------------------->nRoA 2023 nRMA===>nSHCoA 2024 Forward RA CN------------------------------------------------------>HoA 2025 HA==========================================>nRoA 2026 nRMA===>nSHCoA 2028 Figure 25. Forwarding for Concat to Nested via Nested 2030 a)Before LA Hand-off in the oFA/oRMA 2031 The local access traffic (CN:oRoA) is being encapsulated into the oFA MSCoA 2032 and then the oFA is decapsulating and forwarding to the MN using that 2033 oMSCoA/oRoA. Any remote access (HA:oRMA[CN:HoA]) is being encapsulated into 2034 the oFA MSCoA and then the oFA is decapsulating and forwarding to the MN 2035 using the oMSCoA. Note that the FA could also be decapsulating the oRoA 2036 header to check for registered HA/HoAs if the FA optionally has HA/HoA 2037 specific processing. 2039 For LA Hand-off. 2040 The LA MIP Reg v4 sends the information to the nRMA, and a BU to the oRMA. 2041 The LA Reg (nest) prepares the nFA to decapsulate packets from the nFA SHCoA 2042 and forward nRoA and oRoA traffic to the MN (new state). The LA Reg (nest) 2043 prepares the nRMA to encapsulate packets sent to the nRoA (from CNs and oRMA) 2044 into the nFA SHCoA (new state, oRMA undertaking HA check). The inter-RMA BU 2045 (nest) prepares the oRMA to encaps packets sent to the oRoA (from CNs and 2046 registered HAs) into the nRoA and to cancel forwarding to the oFA MSCoA. All 2047 packets now go from the oRMA to the nRMA to the nFA to the MN as shown in (b) 2049 For RMA Hand-off 2050 MN now leisurely sends an RA Reg (Nest) for each HoA/HA pair via nFA/nRMA. 2051 The RA Reg (nest) prepares the nFA to decapsulate packets from the nFA SHCoA 2052 and forward the oRoA and nRoA to the MN (note FA already doing this). The RA 2053 Reg (nest) prepares the nRMA to encapsulate packets from registered HAs to 2054 the nRoA, into the nFA SHCoA. (nRMA now doing HA check). The RA Reg (nest) 2055 prepares the HA to encapsulate packets to the HoA into the nRoA instead of 2056 into the oRoA (new state for oRMA bypass). 2058 c) After RA Hand-off completion 2059 HoA packets are encapsulated into the nRoA in the HA. Packets to the nRoA are 2060 encapsulated into the nFA SHCoA in the nRMA. Packets to the nFA SHCoA are 2061 decapsulated in the nFA, the nRoA inspected and the packets then sent to the 2062 MN that owns that nRoA. 2064 9.5 Nested to Nested using Concat inter-RMA transient forwarding 2066 CN HA oRMA nRMA FA MN 2067 a) 2068 Forward oLA CN----------------------------------------------------->oRoA 2069 oRMA==================>oSHCoA 2070 Forward RA CN------------------------------------------------------>HoA 2071 HA==========================================>oRoA 2072 oRMA==================>oSHCoA 2073 b) 2074 Forward oLA CN----------------------------------------------------->oRoA 2075 oRMA===>nRoA x nRMA===>nMSCoA 2076 Forward RA CN------------------------------------------------------>HoA 2077 HA==========================================>oRoA 2078 oRMA===>nRoA x nRMA===>nMSCoA 2079 c) 2080 Forward nLA CN----------------------------------------------------->nRoA 2081 nRMA===>nSHCoA 2082 Forward RA CN------------------------------------------------------>HoA 2083 HA==========================================>nRoA 2084 nRMA===>nSHCoA 2086 Figure 26. Forwarding for Nested to Nested via Concat 2088 From Nested RN to Nested RN using concatenated LA MIP Reg is possible but 2089 neither preferred nor covered in detail here. 2091 9.6 Nested to Concat using Nested inter-RMA transient forwarding 2093 CN HA oRMA nRMA FA MN 2094 a) 2095 Forward oLA CN----------------------------------------------------->oRoA 2096 oRMA=================>oSHCoA 2097 Forward RA CN------------------------------------------------------>HoA 2098 HA==========================================>oRoA 2099 oRMA=================>oSHCoA 2100 b) 2101 Forward oLA CN----------------------------------------------------->oRoA 2102 oRMA===========================>nRoA 2103 nRMA===>nSHCoA 2104 Forward RA CN------------------------------------------------------>HoA 2105 HA==========================================>oRoA 2106 oRMA===========================>nRoA 2107 nRMA===>nSHCoA 2108 c) 2109 Forward nLA CN----------------------------------------------------->nRoA 2110 nRMA===>nSHCoA 2111 Forward RA CN------------------------------------------------------>HoA 2112 HA=================>nRoA x nRMA===>nMSCoA===>nRoA 2114 Figure 27. Forwarding for Nested to Concat via Nested 2116 From Nested RN to Concatenated RN using nested LA MIP Reg is possible but 2117 neither preferred nor covered in detail here. 2119 9.7 Concat to Nested using Concat inter-RMA transient forwarding 2121 CN HA oRMA nRMA FA MN 2122 a) 2123 Forward oLA CN----------------------------------------------------->oRoA 2124 oRMA================>oMSCoA 2125 Forward RA CN------------------------------------------------------>HoA 2126 HA===>oRoA x oRMA================>oMSCoA===>oRoA 2127 b) 2128 Forward oLA CN----------------------------------------------------->oRoA 2129 oRMA==>nRoA x nRMA==>nMSCoA 2130 Forward RA CN------------------------------------------------------>HoA 2131 HA===>oRoA x oRMA==>nRoA x nRMA==>nMSCoA===>nRoA 2132 c) 2133 Forward nLA CN----------------------------------------------------->nRoA 2134 nRMA==>nSHCoA 2135 Forward RA CN------------------------------------------------------>HoA 2136 HA=========================================>nRoA 2137 nRMA==>nSHCoA 2139 Figure 28. Forwarding for Concat to Nested via Concat 2141 Concat to Nested via LA MIP Reg is possible but neither preferred nor covered 2142 in detail here. 2144 9.8 Concat to Concat using a Nested inter-RMA transient forwarding 2146 CN HA oRMA nRMA FA MN 2147 a) 2148 Forward oLA CN----------------------------------------------------->oRoA 2149 oRMA================>oMSCoA 2150 Forward RA CN------------------------------------------------------>HoA 2151 HA===>oRoA x oRMA================>oMSCoA===>oRoA 2152 b) 2153 Forward oLA CN----------------------------------------------------->oRoA 2154 oRMA==========================>nRoA 2155 nRMA===>nSHCoA 2156 Forward RA CN------------------------------------------------------>HoA 2157 HA===>oRoA x oRMA==========================>nRoA 2158 nRMA===>nSHCoA 2159 c) 2160 Forward nLA CN----------------------------------------------------->nRoA 2161 nRMA===>nSHCoA 2162 Forward RA CN------------------------------------------------------>HoA 2163 HA================>nRoA x nRMA===>nMSCoA===>nRoA 2165 Figure 29. Forwarding for Concat to Concat via Nested 2167 Concat to Concat via a Nested LA MIP Reg is possible but neither preferred 2168 nor covered in detail here. 2170 9.9 Nested <-> Concat Option Comparisons 2172 The following table summarises the various choices when moving between RMAs 2173 using Nested and Concat modes, using Nested or Concat transient forwarding as 2174 described above. 2176 From oRMA To nRMA Via LA RREQ Comments 2178 Nested Nested Nested Triple encapsulations, simple 2179 Nested Concatenated Concatenated Single FA CoA, consistent 2180 Concatenated Nested Nested Single FA CoA, consistent 2181 Concatenated Concatenated Concatenated Minimal Encaps, 2182 Nested Nested Concatenated MSCoA and SHCoA assigned 2183 Nested Concatenated Nested MSCoA and SHCoA assigned 2184 Concatenated Nested Concatenated MSCoA and SHCoA assigned 2185 Concatenated Concatenated Nested MSCoA and SHCoA assigned 2187 The summary is intended to indicate why the last four options are not 2188 presently preferred which is because they result in the nRMA mode changing 2189 between the LA hand-off and the RA hand-off. 2191 This is against the basic LA hand-off model whereby the RA layer uses the 2192 default RA forwarding behaviour agreed at the LA layer. There may be good 2193 reasons why a specific RA session may need to overrule the LA layer decision 2194 in which case the non-preferred modes do need to be supported. In addition, 2195 avoiding the triple encapsulation may justify Nested to Nested via Concat for 2196 example. The other comparison is between the cost of the triple encapsulation 2197 when moving from Nested to Nested via Nested transient forwarding whilst 2198 Concat to Concat via Concat is more complex and requires MSCoAs. Given the 2199 different characteristics and deployment requirements there is a potential 2200 need for both, which therefore requires the Nested <-> Concat hand-offs. 2202 9.10. Inter-RMA Transient Forwarding with GFA mode 2204 This is not covered in detail but is summarised briefly. When leaving a GFA 2205 oRMA, the oRMA look-up uses HoA state but is forwarded using a nRMA CoA that 2206 is commensurate with the nRMA mode. When moving to a nRMA that is using GFA 2207 mode, from an oRMA in Nested, Concat or GFA mode, the nRMA provides the oRMA 2208 with a SH CoA and Context Transfer is used to move the HA/HoA state to the 2209 nRMA to support RA layer GFA forwarding in advance of RA layer RREQ/RREP 2210 hand-off. 2212 10. Additional Modifications, Options and Extension Definitions 2214 10.1 Hybrid Concat/GFA Modes 2216 The RA MIP Reg v3 sends the RoA to the HA where it is used as the destination 2217 address for the HoA encapsulation. The RoA is also used as the LA layer 2218 address for local access service. If local access is not required, and the 2219 HoA is a public address, then the RMA can instead allocate a SHCoA for the 2220 HoA binding and then forward based on the inner HoA as in GFA mode. This 2221 saves RoA addresses when they are not needed but avoids the need for HoA 2222 specific state in the FA by still using an MSCoA in the FA. The MN cannot 2223 know this RMA SHCoA in advance and so must use a blank CoA field in the RA 2224 MIP Reg v3. The RMA then adds the SHCoA into the HFAext, sends it to the HA, 2225 and the RMA returns it in a HFAext to the MN. The MN can of course populate 2226 the CoA field in subsequent refreshes via the same RMA. 2228 Equally, in GFA mode, a RMA SHCoA is used but this can be avoided if the MN 2229 also has Local access and an RoA. The RoA can be inserted into the HA such 2230 that an RMA failure can be locally recovered in another RMA without having to 2231 update the HA. In addition, the RoA is known at the LA layer and so the 2232 backwards compatibility issue with a CoA=0 is avoided. 2234 10.2 GFA and private HoAs 2236 Private HoAs cannot safely be supported in GFA or hybrid mode because 2237 forwarding is dependent on a potentially non-unique private HoA. This limits 2238 GFA mode, and the above hybrid mode to public HoAs. This restriction can be 2239 relaxed however if a FA MSCoA is used instead of a FA SHCoA because the 2240 concatenation of the MSCoA+HoA ensures uniqueness. This is not necessary in 2241 the RMA because the HoA can be made unique through the concatenation of the 2242 HA and the HoA, making an RMA SHCoA permissible. 2244 10.3 Heterogeneous RA forwarding modes 2246 In section 5,it was explained how the LA MIP Reg identifies the capabilities 2247 of the RMA and installs a single mode of RA forwarding for all RA sessions 2248 from that MN. This is reasonable because the HA is not aware of the RMA 2249 forwarding mode and the HA changes are simply to be able to support 2250 [RegTunMods] home registration extensions to enable the use and transfer of 2251 dynamically assigned CoAs and RMA addresses. However, there may well be 2252 reasons why the MN (possible as a result of the home operator AAA profile) 2253 will have a preference over which mode is used by the MN to that HA. If such 2254 a preference does exist then this can be easily supported using the following 2255 rules. 2257 Firstly, the LA layer must include a request in the stylext for the default 2258 LA mode which should be the Nested mode as this places the lowest burden on 2259 CoA resources and matches the LA forwarding mode. 2261 Each RA MIP Reg can then overule this default by including a stylext that 2262 indicates either Concatenated or GFA forwarding. The use of combined 2263 signalling means therefore that the LA and RA styleext must be able to be 2264 distinguished using a flag bit. When multiple RA sessions are in progress 2265 then there is a danger that a MN could acquire both a MSCoA (for concat) and 2266 a SHCoA (for GFA/Nested) at the FA, as well as a SHCoA at the RMA (GFA with 2267 no local access). This can be avoided by the LA layer always using a MSCoA 2268 instead of a SHCoA at the LA layer for all RA sessions once a MSCoA has been 2269 assigned. This requires the FA and RMA to update the visitor lists 2270 accordingly for the MN. 2272 Secondly, during inter-FA hand-off, the LA MIP Reg must be able to support 2273 all the different dependent RA layer sessions at the new FA in advance of the 2274 RA visitor list being refreshed. The LA MIP Reg should therefore signal 2275 wildcard mode to the FA/RMA using a FA SHCoA, unless a FA MSCoA is required 2276 by one of the RA sessions. The FA then installs visitor list entries 2277 sufficient for any interpretation (superposition) of the information in the 2278 stylext of the LA Reg. Finally, the RMA uses the correct installed forwarding 2279 for the installed session specific RA state towards that FA. The FA removes 2280 unexercised visitor list entries when the MN leaves that FA. 2282 10.4 HA/HoA Specific Processing and Context Transfer 2284 HA/HoA specific state can be installed by the RA layer into the FA and RMA. 2285 It can also be installed by the LA MIP layer in the case of GFA mode. This 2286 state may simply be the HoA, the HA, or both and is used to supplement the RA 2287 visitor list for the associated MN/RoA. This requires the relevant node to 2288 potential look into an encapsulation to discover the HoA and/or HA source 2289 address in a packet before forwarding that packet. HA/HoA specific state must 2290 be installed in GFA mode to satisfy basic forwarding rules of that mode. 2291 HA/HoA specific state can be optionally stored and inspected in Nested and 2292 Concat mode in both the FA and the RMA. It is required in the RMA for both 2293 Nested and Concat modes when the MN is allowed to avoid RA reverse tunnelling 2294 and hence to send with the HoA as a source address. In this case, the packet 2295 must be LA reverse tunneled to the RMA to undergo a source check and the 2296 HA/HoA state must be CTed between RMAs on hand-off. 2298 HA/HoA state can also be inspected to distinguish between multiple ongoing RA 2299 sessions so that HA/HoA specific accounting, QoS and policy can be applied. 2301 HA/HoA Specific QoS processing is required to enable specific HA/HoA flows 2302 to get preferential forwarding services over the air or through the 2303 network. 2305 HA/HoA Specific Accounting processing is required so that accounting 2306 records can be built and delivery to the correct home operator and third 2307 party service providers. 2309 HA/HoA Specific Policy can be used to bar or allow specific HAs and HoA 2310 address ranges from being supported. For uplink traffic, discard is most 2311 efficient at the FA whilst for downlink it is at the RMA. 2313 During inter-FA LA hand-off, any RA layer HA/HoA state will be missing in the 2314 new FA and will not be immediately rebuilt at that FA due to the longer 2315 binding lifetimes used in the RA layer to avoid excessively loading global 2316 HAs. This state must therefore be Context Transfered between the FAs during 2317 the inter-FA hand-off. Similarly, during an inter-RMA hand-off, it is 2318 necessary to space out the RA layer updates via the nRMA to avoid a flood of 2319 such messages during the hand-off. Therefore, for a short while the HA/HoA 2320 specific state will be missing in the nRMA which could impact accounting, QoS 2321 or policing. The state is however still at the oRMA which is on the 2322 forwarding path until the RA layer update to the HA and so some functionality 2323 may not be lost. However, it may still be necessary for the HA/HoA specific 2324 state to be Context Transferred from the oRMA to the nRMA when either the BU 2325 or the Combined LA/RA Reg v1 is received at the oRMA. Again, the likely need 2326 for this is known at the oRMA by the type of HA/HoA specific processing. 2327 Therefore, in either FA or RMA cases, the need for CT is known at the oFA 2328 and/or old RMA and will be triggered by the BU from the newFA / new RMA. 2330 Note that the Context Transfer of HA/HoA state can be synchronized with the 2331 CT of other state such as the general AAA profile for the MN, the MN-FA SA 2332 between FAs, the MN-RMA SA between RMAs, along with the HoA specific profile 2333 information for those HoAs and for the base RoA. The Context Transfer ideally 2334 needs to be reliable because otherwise HA/HoA state will be lost. In the case 2335 of GFA mode, the loss of such state is catastrophic to that RA flow and is 2336 one reason that Concat mode is preferred. In Nested and Concat mode, CT is 2337 used simply to transfer state that is not needed for basic forwarding and 2338 hence late or lost state can be tolerated in general and then be rebuilt on 2339 the next RA refresh. The lost value added processing is that some packets 2340 will not be correctly accounted (undercount), flows may not receive 2341 preferential service for a while, and incorrect packets will progress further 2342 in the network than intended. Each of these situations have their own 2343 commercial consequences and the CT layer should therefore have suitable 2344 reliability mechanisms commensurate with those consequences however it should 2345 be restated that basic forwarding is still always ok ensuring graceful 2346 degradation. 2348 Note also that Context Transfer can be avoided by instead storing such state 2349 in a coordinated way in the local AAA servers. The nFA and nRMA can then 2350 fetch this state when the hand-off Registration is received which should 2351 contain the AAA-NAI for that state. 2353 10.5 Previous Foreign Notification Extension (PFANE) 2355 The traditional PFANE extension is used to trigger a BU to the oFA to cause 2356 the oFA to switch packets addressed to the HoA towards the new FA CoA. During 2357 inter-RMA hand-off, the LA layer forwarding between these two elements may be 2358 required in support of nested, concat or GFA from the old FA to Nested, 2359 Concat or GFA mode at the new FA. The PFANE and the associated BU do not 2360 however need to be modified because the behaviour between all the various 2361 mode combinations only varies at the nFA by the type of FA CoA (shared or MN 2362 specific) that is assigned. The oFA simply forwards towards that FA CoA and 2363 does not need to be aware of the CoA type or the nFA subsequent processing. 2364 The only change therefore is that the FA CoA can be MN specific. Note however 2365 that the MN can only pre-calculate the BU authentication if the FA CoA is 2366 advertised to the MN in the FAA. Therefore, for Concat mode, this requires 2367 the MSCoA to be unicast in an FAA in advance of the MN sending the LA RREQ. 2369 The PRANE is formatted the same as the PFANE but includes the oRMA address 2370 and the nFA CoA rather than the oFA address and the nFA CoA. The MN 2371 calculates the authenticator as for PFANE but can only do so if the FA CoA is 2372 advertised to it in an FAA before sending the LA RREQ or combined LA/RA RREQ 2373 to the HA via the nFA and nRMA. When the PRANE is protected by the MN-FA auth 2374 extension then this tells the FA that it should initiate the BU to the oRMA 2375 to instigate oRMA to nFA forwarding. 2377 The BU is sent from the FA to the oRMA and contains the HoA=oRoA and the 2378 CoA=nFA SHCoA as Nested mode in the nFA is always supported because it is 2379 required for LA layer forwarding for local access traffic. The BU does not 2380 then need to be modified in any way to deal with the various types of RA 2381 forwarding at the nFA because of this default feature. This decision is in 2382 preference to enabling the PRANE and the BU to be sent with a stylext to 2383 identify the required forwarding mode from the oFA. 2385 The PRANE can instead be wrapped in the MN-HA or MN-nRMA auth extension to 2386 instead cause the nRMA to send the BU to the oRMA. The MN-HA SA is used if 2387 the MN-nRMA SA is not immediately available but means that the nRMA cannot 2388 authenticate the PRANE but instead leaves authentication to the oRMA of the 2389 BU. The MN-nRMA can be used immediately if it is the same as the MN-oRMA SA 2390 and will be CTed to the nRMA, or fetched by the nRMA from the AAA system. 2392 The PRANE to the nRMA includes the oRMA address and the nRMA address 2393 advertised in the FAA (as the RMA SH CoA). The MN calculates the 2394 authenticator based on the MN-oRMA SA. The BU is sent by the nRMA to the oRMA 2395 for the oRoA and if authenticated will cause traffic on or associated with 2396 the oRoA to be forwarded to the nRMA using either the oRoA or the RMA SHCoA. 2397 The nRMA knows which forwarding mode is to be provided at the nRMA and so the 2398 BU needs to include this information in the BU (the Stylext) so that the oRMA 2399 can undertake the correct forwarding as recommended in section 9. The BUack 2400 is sent to the MN again via the tunnel created by the BU from the oRMA to the 2401 nRMA. The use of the RMA SHCoA for the RMA address advertised in the FAA 2402 limits this technique to intra-domain, inter-region forwarding where the nRMA 2403 SHCoA = RMA address in the FAA. 2405 On inter-operator boundaries, the nRMA CoA for the oRMA will likely not be 2406 the same as the nRMA address in the FAA from the MN and nFA perspective. With 2407 an oRMA/nRMA SA in place, which is most likely necessary and useful in the 2408 case of the inter-operator boundary, the MN would include the PRANE and leave 2409 the nRMA CoA field blank. The MN would pre-calculate the authenticator 2410 including the zero address. The nRMA would generate a BU from the PRANE in 2411 the LA MIP RREQ, using the MN authenticator and forward it to the oRMA, 2412 attaching a HFAext for the nRMA CoA chosen by the nRMA (nRoA or nRMA SH CoA) 2413 based on the forwarding mode and secured by the inter-operator SA. Once again 2414 the BU Ack is returned to the MN via the nRMA and nFA to confirm to the MN 2415 that inter-operator forwarding is in place. Note that the nRMA CoA=0 rather 2416 than nRMA CoA=nRMA in the FAA is only used to avoid operator addresses 2417 leaking out of the domain. For an intra-domain inter-RMA hand-off, the nRMA 2418 CoA in the PFANE should always be the nRMA address in the FAA. The nRMA can 2419 then inspect this address and decide if it wishes to add a HFAext = new nRMA 2420 CoA to override the value in the CoA field, secured by the inter-RMA SA. 2422 10.7 Style Extension (Stylext) 2424 The LA layer needs to select the options for the following parameters; 2426 0 1 2 3 2427 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2429 | Type | Length | flags | 2430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 | reserved | 2432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 'L' Layer flag set for RA, unset for LA (unset here) 2435 'S' Access flag set to access service at that layer 2436 'P' Address flag set if public, unset if private address (RoA) 2437 'N' NAT flag set if NAT is requested for a private address RoA 2438 'A' CoA flag set if FA MSCoA, unset if FA SHCoA 2439 'G' GFA flag set if the common RA mode at LA layer is GFA 2440 'C' Concat flag set of the common RA mode at LA layer is Concat 2442 The RA layer needs to select the options for the following parameters; 2444 0 1 2 3 2445 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | Type | Length | flags | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 | reserved | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2452 'L' Layer flag set for RA, unset for LA (set here) 2453 'S' Access flag set to access service at that layer 2454 'P' Address flag set if public, unset if private address (HoA) 2455 'N' NAT flag set if NAT traversal is requested 2456 'A' CoA flag set if RMA MSCoA, unset if RMA SHCoA 2457 'G' GFA flag set if the session specific RA mode is GFA 2458 'C' Concat flag set if the session specific RA mode concat 2460 Nested MIP, being the LA default mode, does not need to be signalled but if 2461 it is signalled is represented by the G and C flags being unset. In the case 2462 of the RA layer, both the G and C flags being unset also indicates a request 2463 for RA session specific nested mode, whilst both being set indicates that the 2464 LA layer common RA mode setting should be used. 2466 Combined LA/RA Registrations can include an LA stylext, an RA stylext or both 2467 depending on the level of feature complexity. 2469 The MN does not dynamically and explicitly request, via the Stylext, HoA/HA 2470 specific processing in the RMA and FA, nor Context Transfer services in 2471 support of the maintenance of such state during hand-off. These are instead 2472 operator features that may be determined based on the AAA profile and 2473 operator policy. They may also be mandated by specific combinations of the 2474 Stylext flags, and the MIP Reg flags, as stated below. 2476 In Concat mode, if the RA layer reverse tunnelling bit is not set, then the 2477 LA layer reverse tunnelling bit must be set so that the RMA can undertake the 2478 source address check. The RMA RA state is copied from the RA Reg v3 2479 RREQ/RREP. Context Transfer of this state between RMAs required to enable the 2480 nRMA to undertake these checks in advance of the RA Registrations via the 2481 nRMA. 2483 In GFA mode, the RA layer must be given a public HoA and HoA specific state 2484 must be installed into the FA and RMA by copying it from the RA Reg v3 2485 RREQ/RREP. 2487 10.8 HFAIPext 2489 This is a generalized form of the GFAIPext in RegTun with the addition of a 2490 sub-type to indicate the address sub-type and the associated required 2491 processing. This is used to inform an upstream or downstream node of the 2492 address of a dynamically assigned upstream node so that the downstream node 2493 can direct MIP messages and data to that upstream node. Examples include the 2494 RMA and HA addresses. 2496 0 1 2 3 2497 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 | Type | Length | sub-type | 2500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2501 | HFA IP Address | 2502 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2504 The HFAIPext must have sufficient flags to differentiate between a range of 2505 IP addresses that can be carried, which for this draft can include the 2506 dynamically assigned HA or RMA. 2508 10.9 HFAext 2510 This is a generalized form of the HFAext in RegTun with the addition of a 2511 sub-type to indicate the address sub-type and the associated required 2512 processing. 2514 This is used to inform an upstream node of the care of address assigned by a 2515 downstream node, to which that upstream node should forward and from which 2516 that upstream node should expect to receive reverse tunneled packets. It is 2517 also used to inform the MN of the dynamically assigned CoA that it should use 2518 in the Registration CoA field. 2520 0 1 2 3 2521 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 | Type | Length | sub-type | 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 | HFA Care of Address | 2526 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2528 The HFAext must have sufficient flags to differentiate between a range of IP 2529 addresses that can be carried which for this draft can include the FA SHCoA, 2530 FA MSCoA, RMA SHCoA and RMA MSCoA=RoA. The RoA can also be carried in the 2531 HFAext as part of dynamic addressing in Combined messages. 2533 10.10 HoAList 2535 During inter RMA hand-off and especially during inter-operator hand-off it is 2536 likely that the MN will not want to enable transient forwarding (inter-FA or 2537 inter-region) for specific RA sessions and associated HoAs. The HoAlist 2538 extension is an include/exclude list to inform the previous FA or RMA which 2539 HoAs to forward for. This can be used to also constrain what HA/HoA specific 2540 state is context transferred to the nFA from the oFA, and to the nRMA from 2541 the oRMA. In the absence of the HoAlist, then provided an authentication 2542 extension exists between the nodes, no HoA specific state is CTed across. 2543 This therefore works with legacy nodes that do not support HoAList Extension 2544 and also ensures that only explicit request to include HoAs can do so during 2545 hand-off. 2547 The HoAList in include form can also be used by the MN to populate the local 2548 FA with HA/HoA state, and avoid CT, when the list is short and hence 2549 bandwidth efficient. 2551 The format of the message is to be determined. 2553 10.11 HoAResp 2555 This extension is used to confirm reception of and action on the HoAlist. It 2556 can also be used to transfer the HA/HoA state to the nFA or nRMA from the oFA 2557 or oRMA. Its transport and format has yet to be determined and is not needed 2558 if the HA/HoA state is to be transferred as part of MN AAA state, or by the 2559 MN itself. 2561 10.12 HoAErr 2563 This extension is required to enable a HoAResp to contain HoA specific MIP 2564 error information for the nFA and MN. 2566 10.13 FA-NAI regional structure 2568 The FA-NAI is supported in legacy FAs and MNs and is required to support 2569 inter-region movement detection. The FA-NAI is required so that MNs seeking 2570 regional services can be suported along with legacy MNs that do not. This is 2571 achieved by structuring the username and domain parts of the NAI as 2572 'FAnameRMAname@domain'. The '%' character is an obvious 2573 suggestion. 2575 A legacy MN will correctly interpret the domain part to detect inter-operator 2576 hand-off and will not see the substructure in the username part, but will 2577 correctly distinguish between FAs and hence support inter-FA hand-off. Only a 2578 regional aware MN can see the sub-structure and will use this to determine 2579 when inter-FA and inter-RMA hand-offs are required. 2581 10.14 Unicast FAA for MN specific FA CoA assignment 2583 A MN specific FAA can be sent to the MN by determining the MN link-layer 2584 address from the LA visitor list and then sending the FAA just to that MN 2585 over a unicast link-layer connection to either the broadcast address or the 2586 address of the MN. The MN then uses this rather than any broadcasted FA CoA 2587 in its MIP registration. The MN can assume that such a FA CoA is MN specific 2588 and hence enables Concat mode to be requested without using the CoA=0 and 2589 HFAext= MSCoA as part of dynamic FA CoA assignment. 2591 10.15 When the LA layer is hidden from the RA Layer 2593 A legacy MN RA layer MIP implementation will not know about this draft. The 2594 preferred option therefore is that the LA layer is hidden from the MN OS 2595 apart from driver calls through a standardised API. The LA layer therefore 2596 intercepts the FAA with its FA and RMA movement information, and presents RMA 2597 changes to the MN as interface address changes by assigning each new RoA. The 2598 legacy RA MIP layer in the MN will then report this new interface address to 2599 the HA with which it shares an RA session. In this model the MN RA MIP 2600 implementation is pretty dumb and the LA layer monitors, intercepts and 2601 controls all AS and AA activity. 2603 This model, whilst great for initial deployment and backwards compatibility, 2604 has the draw-back however that the RA layer is not able to track regional 2605 movement, elect to preserve RMA/RoAs as RA sessions, know when it can use Reg 2606 v2 and Reg v3 or use combined RA/LA signalling etc. This can be improved by 2607 enabling the LA layer to proxy the FAA through to the RA layer but modify and 2608 hide some of the fields in the case of a legacy MN RA MIP stack so that it is 2609 not confused. However, not even this is adequate for many of the features. 2611 10.16 When both the LA and RA layers are exposed to the FA 2613 A more complete model therefore is instead to enable both the host RA layer 2614 MIP stack and the LA layer stack to send and receive AS/AA in a coordinated 2615 manner whilst giving the LA layer ultimate control over what is permitted to 2616 be sent over the air-interface to protect the local mobility management 2617 system. 2619 This can be implemented through a sophisticated API with all MIP 2620 messages ultimately being generated in the LA layer under OS control. 2621 Alternatively, both the RA and lA layer can generate their own messages, but 2622 with Combined messages only being sent by the RA layer under LA layer 2623 control. The LA layer must in all cases have capabilities to protect the 2624 operators local mobility management layer from abuse such as message rate 2625 limiting, checks on message fields, firewalling and movement verification. 2627 10.17 When the RA layer and LA layer terminate on different elements 2629 The model above where the LA layer sends all MIP messages does not support 2630 the case where the RA stack is separate from the device implementing the LA 2631 stack. This would happen with a hub or router having the LA layer on air- 2632 interface, and a LAN on the other supporting a number of nodes sharing the 2633 hub/router for local and remote access. This provides further motivation for 2634 the model whereby either RA or LA stacks can issue messages but with the LA 2635 stack having specific controls. 2637 The node with the LA stack acts as a private address allocator for the LAN. 2638 LAN MN members use their private addresses as source addresses for local and 2639 remote access. Directly reachable members are discovered via ARP as normal. 2640 The MNs can also use those private addresses for remote access with the LA 2641 stack node acting as a proxy FA. 2643 In this case, as the hub moves in the cellular infrastructure (in a car, on a 2644 train etc) then the LA stack acts as a proxy FA by relaying a modified FAA to 2645 the MNs. The FAA over the air-interface reports inter-FA and inter-RMA 2646 movement that causes the LA stack to acquire a new RoA at each new RMA. Each 2647 newRoA, RMA is reported to the LAN in the proxied FAA (and not the FA or FA 2648 CoA) so that the RA stacks can build fully populated RA Reg messages. 2650 The RA layer adds the MN-HA auth and he RA MIP registrations should then be 2651 routed via the proxy FA, learnt from the proxied FAA and have the 'D' bit set 2652 to indicate CCoA to the cellular infrastructure as required by Nested/Concat 2653 MIP. This enables the proxy FA to discover the HoA addresses so that the MNs 2654 do not have to encapsulate to the proxy FA but can be sent natively towards 2655 the RoA default gateway address. The RoA is then a form of proxy CCoA [PCCoA] 2656 with the tunnelling functions left to the proxy FA. 2658 The proxy FA adds the LA layer extensions and the MN-FA authenticating 2659 extension. The packets from the LAN, are then forwarded by the proxy FA, 2660 according to the registration state and forwarding mode to either the FA, 2661 RMA, HA or CN. For example, reverse tunnelling in Nested mode would require 2662 the packet to be re-encapsulated in the RoA as a source address and sent to 2663 the HA. In the downlink direction, packets are encapsulated to the RoA 2664 address owned by the proxy FA which strips away the HA source, RoA 2665 destination encapsulation. The proxy FA then forwards to the MN across the 2666 LAN based on the HoA. The Proxy FA needs to potentially also support 2667 encapsulation from the MN to the proxy FA using the private address/RoA pair 2668 when non-unique HoAs are evident on the LAN. This is discovered by the proxy 2669 FA during registration and will cause the proxy FA to instruct the MN to 2670 encapsulate remote access traffic to it (and expect encapsulated traffic in 2671 return) and to not set the 'D' bit but to let the proxy FA set that bit as it 2672 forwards the registration to cellular operator as normal. 2674 As far as the rest of the cellular infrastructure is concerned, the LAN 2675 appears to be a single node with multiple remote and one local access 2676 session. Only the node running the proxy FA function can utilise the RoA as a 2677 source / destination address for local access but that node can add support 2678 for a NATP function to enable local access from the multiple private 2679 addresses to share that single RoA out to the cellular domain. This then 2680 provides a scalable way for multiple MNs from different home networks to 2681 share a single wireless connection for either remote, local or remote and 2682 local services. This is possible because of the aggregation properties of the 2683 layered model. 2685 10.18 RoA Address Allocation 2687 MIP visitor list entries in the MN, FA, RMA and HA include state that enables 2688 encapsulated packets to be correctly forwarded. The state is installed by the 2689 MIP Registration between the MN and the RMA/HA, and then confirmed by the 2690 Reply in the reverse direction. This ensures that downstream nodes have 2691 visitor list state before upstream nodes so that when the visitor list is 2692 created in the RMA/HA, arriving packets in the forward direction, from the HA 2693 to the MN, will not hit MIP elements that lack visitor list state for that 2694 flow. 2696 Unfortunately, the RoA address is used by the MN but is obtained from the RMA 2697 in each new region. Therefore, the dynamically allocated RoA is not known in 2698 advance by the MN and therefore cannot be in the MIP Registration Request 2699 towards the new RMA via the FA. This provides an opportunity for the FA 2700 visitor list to be unpopulated when the MIP Request hits the RMA, which risks 2701 packets towards that RoA being dropped at the FA because the MIP Reply 2702 processing in the FA that creates the FA visitor list will be significantly 2703 slower that data packets reaching the FA (and being dropped). This mainly 2704 affects inter-RMA forwarding that is being redirected to the nRoA from the 2705 old RMA, using either a PRANE triggered BU or a Combined RA/LA Registration 2706 Request to the oRMA. It does not affect local access traffic because no 2707 incoming packets will be generated towards the nRoA until the MN starts to 2708 use that nRoA, which it will not do until it receives the MIP Reply (which 2709 will have installed the required FA state). 2711 The RoA can be assigned in a number of ways in the new region. 2713 a) The RoA can be allocated by the RMA using MIP dynamic address 2714 allocation in which case the RoA is returned in an MIP Reply message. 2716 b) The AAA system can allocate the RoA for the RMA in which cases the 2717 address is returned to the FA in an MIP Reply message embedded within a 2718 AAA message. 2720 c) The FA can act as a DHCP client and obtain the address from the RMA 2721 that acts as a DHCP server. The message is returned to the FA in a DHCP 2722 message and is then inserted into the MIP RREQ towards the RMA. 2724 d) The FA can be pre-assigned a pool of RoA addresses from each RMA in the 2725 region. The FA can then insert the RoA itself into any MIP RREQ from a MN 2726 that has a zero RoA field at the same time that it selects the RMA 2727 address. 2729 Case (a) has the problem that the FA only gets to see the RoA when receiving 2730 the RREP, by which time packets will likely already be arriving towards the 2731 RoA (inter-RMA forwarding) and therefore would normally be dropped in MIP 2732 because no visitor list entry exists. The use of the RoA should therefore be 2733 delayed upstream by some safety timer to ensure that the RREP with the new 2734 RoA has reached the FA, but this still fails if the RREP is lost 2736 Case (b) has a similar problem but can use reliable transport of the RREP in 2737 the AAA message. The use of AAA routing though means that the safety timer 2738 could need to be quite large which increases the amount of expensive inter-FA 2739 forwarding required. 2741 Case (c) incurs additional delay at the new FA before the RREQ can be sent 2742 although this delay, as with the safety timer, may well be fine in the case 2743 of make before break hand-off because the old link is still available. 2745 Case (d) requires the configuration of address pools in the FAs, that are 2746 divided out of the RMA address blocks. This can lead to significant address 2747 inefficiencies given that a MN can start at any FA within the region. There 2748 is also the problem that the FA needs to know when the address is released 2749 but that release is only presently known at the RMA, because the RoA can 2750 continue to be used at any FA and is only released explicitly using an inter- 2751 RMA hand-off BU. 2753 Case (d) is the fastest approach and consistent with the FA also assigning 2754 the RMA itself. To proceed with this method will require the RMA to provide 2755 the FA with information of when the RoA is released. In addition, the FA 2756 needs to be able to dynamically acquire additional addresses that it can 2757 allocate out. This could be achieved by the FA acting as a DHCP client with 2758 the RMA server for address management purposes. Addresses are then requested 2759 by and handed out to FAs in advance of MN arrivals, as the FA address stores 2760 get depleted. The RMA DHCP server tells the FA when addresses have been 2761 returned by reporting them as revoked (ie returned to the RMA). The FA can 2762 then reclaim that or any other address in blocks. Case (d) needs work but 2763 looks the best option due to the speed, and avoidance of the RREP reliability 2764 issue. In the absence of that, the order of preference is probably c, b, a 2765 due to the RREP being a bigger issue than the delay issue. 2767 A potential solution to the RREP issue is that if a data flow arrives from an 2768 RMA towards an RoA that has no visitor list state, then the FA can 2769 temporarily build a visitor list from the arriving data; 2771 For Concat, inspect the outer address (MSCoA) which was installed by the 2772 RREQ in the FA, to identify the MN address, dynamically build the visitor 2773 list state from the data packet contents, and send the data towards that 2774 MN encapsulated in the oRoA which is also already known. 2776 For nested, decapsulate from the SHCoA, inspect the dest address to see 2777 the nRoA, inspect the inner destination address to see the oRoA and 2778 identify the MN (the FA knows the MN/oRoA set), build the visitor list 2779 state and forward encapsulated within the nRoA so that the MN also learns 2780 the nRoA address. 2782 For GFA mode, the nRoA is only used for local access traffic and will only 2783 arrive once used by the MN. oRoA packets arrive encapsulated in the SHCoA. 2785 The MN on receiving packets then can optionally resend the RREQ containing 2786 the discovered nRoA to confirm the visitor list state...If the above is 2787 acceptable then the effect of the RREP is minimised and RoA assignment delay 2788 then becomes the critical issue. This results in a modified preference order 2789 of d, a, b, c. 2791 10.19 Proxied HA Update 2793 The architecture as described still requires each MN to update each global HA 2794 itself with the new RoA on each inter-RMA hand-off. It does so by sending an 2795 MIP Registration to that global HA, via the RMA, with the nRoA as the CCoA 2796 for the HoA assigned in that HA to the MN. The architecture simply enables 2797 these RA layer updates, for multiple HA/HoA pairs, to be once per region 2798 rather than once per FA, and to be distributed in time, whilst the MN is in 2799 that region, rather than having to be sent immediately as part of the inter- 2800 RMA hand-off. This can be improved upon by enabling the oRMA to instead 2801 update the HA for the MN. 2803 This relies on the MN actively communicating with the oRMA as part of the 2804 inter-RMA hand-off. The MN sends either a PRANE to the nRMA which triggers 2805 the BU to the oRMA, or it sends a Combined RA/LA message to the oRMA via the 2806 nRMA. Both of these messages contain the nRoA that is required to be inserted 2807 into the global HAs with which the MN is having a remote access session. 2808 Either the BU or the Registration Request can trigger the transfer of the 2809 oRMA-MN SAs to the nRMA, protected by the oRMA-nRMA SA. 2811 Context Transfer is then used between the oRMA and the nRMA to rapidly move 2812 the Remote Access state for all the HA/HoA pairs being employed by the MN, 2813 from the oRMA to the nRMA. This includes the oRMA-HA SA that can be used for 2814 secure communications with the HA. Alternatively, this HA/HoA state could 2815 instead be stored in the local AAA system and fetched directly from there by 2816 the nRMA. Either way, the nRMA acquires the SA and the HA/HoA information. 2817 Either oRMA or the nRMA are therefore potentially in position to update the 2818 global HAs with the new RoA address. The alternative approaches are described 2819 below. 2821 10.19.1 oRMA based Proxy HA Update 2823 The model is a hierarchical interpretation of Route Optimisation as described 2824 in [RouteOpt]. The global HA is sending to the RMA (local HA) and from the 2825 perspective of the RMA is a Correspondent Node at the LA layer. When the oRMA 2826 is informed of the nRoA then the RMA can send a BU to the HA (containing the 2827 HoA, nRoA information) using the existing oRMA-HA SA, requesting the HA to 2828 tunnel traffic for the HoA directly to the nRoA. This will cause the oRMA to 2829 be bypassed. 2831 The Binding Warning Registration extension is used to carry the Warning to 2832 the oRMA if the oRMA is the destination of the MIP RA layer RREQ. The oRMA 2833 then inspects the oRoA, determines the HoAs for the HAs from local state, and 2834 then issues the BUs secured by the oRMA-HA SA. The MN adds the Binding 2835 Warning and can therefore use this to decide which HAs get handed off 2836 immediately. 2838 If the nRMA is instead going to be contacted via an LA layer BU from the nRMA 2839 or nFA, then the BU is an explicit indication of an inter-region hand-off 2840 which contains the nRoA and so this should cause the oRMA to again issue BUs 2841 for all HA/HoA pairs tied to the oRoA, which will be forwarded to the nRoA 2842 (or nRMA SHCoA) 2844 If in either case the oRMA does not have the HA/HoA state, or simply wishes 2845 to wait to see if the RA session is still active, the Binding Update to a 2846 specific HA can be triggered by an arriving packet from that HA, addressed to 2847 the HoA and encapsulated towards the oRoA. The oRMA can also then dynamically 2848 determine the HoA. 2850 Irrespective of how the BU is generated, the BUack is mandated following the 2851 authentication check and is returned to the oRMA. 2853 The global HA in MIP standards does not presently received Binding Updates 2854 nor respond to them by redirecting an MIP visitor list entry to the new CoA 2855 in the BU. The FA can however presently act like a HA and respond to the BU 2856 by forwarding to the reported CoA but this is only allowed because the MN has 2857 signed it. 2859 In this case, the MN is not directly affected whether or not the BU is 2860 processed because in either case the MN receives packets via the nRoA. This 2861 is therefore simply a regional optimisation. The HA can be assured that this 2862 is true because the message is authenticated by the oRMA-HA, this oRMA has 2863 already been trusted for a long while to forward for the HA, and the action 2864 of the message is to stop packets going through it, which is hardly the 2865 action of an attacker. If a node somehow masquerades as the oRMA then the 2866 BUack still goes to the valid oRMA and so the attack is detected and the 2867 attacker can give themselves away if they actually include a nRoA in an 2868 attempt to capture packets. Essentially, though the chain of trust should be 2869 sufficient here between the RMA and the HA. 2871 The BU Identification field should be set according to the multitude of 2872 ongoing BUs sent between those nodes and independent of any MN-HA 2873 identification field for that HoA/HA pair. This is for ordering purposes and 2874 replay protection. 2876 Now if the BU or BUack fails then the oRMA can resend. If the MN has 2877 cancelled the RA session with that HA then the BU will be ignored. If the 2878 Registration or BU to the oRMA is lost then they will be resent by the MN. If 2879 the HA fails to redirect to the nRMA then packets will continue to arrive at 2880 the oRMA which can again trigger resending the BU. 2882 10.19.2 nRMA based Proxy HA update 2884 In this case the BU is sent from the nRMA once the Context Transfer of state 2885 has occurred from the oRMA. The BU is the same as before but at the HA this 2886 is a redirection to a node asking for that redirection which is clearly more 2887 dangerous, although it is still secured via a HA-nRMA SA (via CT or AAA). It 2888 is also much slower than the oRMA based approach and should therefore only be 2889 used if the oRMA has failed to update the HA at that stage. One advantage of 2890 the nRMA based approach is that the HA gets to know the nRMA address as well 2891 as the nRoA from the BU so that any redirection can be traced whilst the HA 2892 only knows the nRoA from the BU when sent by the oRMA. 2894 10.19.3 RA session Group HA Hand-off Extension 2896 Ideally, either approach would be totally secure if some form of MN-HA SA was 2897 used to protect an extension that actually stated that an inter-RMA hand-off 2898 was requested by that MN, and the old and new, region names, RMA addresses or 2899 RoA addresses as identified in the FAA to the MN. One such approach would be 2900 to use a group key as is commonly used in multicast between a single sender 2901 and a multicast group. The MN would provide the asymmetric group key to each 2902 HA and update it in periodic RA registrations. Asymmetry is required so that 2903 a rogue HA cannot pretend to be the MN. On an inter-RMA hand-off, the MN 2904 would sign a Group HA Hand-Off extension containing the new and old regions, 2905 RMA addresses and RoAs and send it to the oRMA and nRMA in the 2906 Registration/BU. Each RMA would then include this extension in the BUs to the 2907 HAs which would verify that they are acting on behalf of the MN and would 2908 bound the risk depending on the information detailed in the Group HA HO 2909 extension. For example, if the extension includes oRoA and nRoA then there is 2910 essentially no risk although this can only be sent by the MN once the nRoA is 2911 returned to the MN in the RREP, ie after an LA Reg to the nRMA. Therefore 2912 first undertaking an LA Reg and subsequently undertaking a proxy HA update 2913 via the old or newRMA is preferred. If the extension includes the oRMA/nRMA 2914 address then BUs sent from those addresses are safe. If the extension only 2915 includes the new region name then the HA has at least had confirmed that an 2916 inter-RMA hand-off is required and has good information of where the MN 2917 thinks it is going, and can compare it to a region name included by the 2918 oRMA/nRMA in its BU, or to historical state in the HA regarding trusted 2919 regions. 2921 11. IPv6 Considerations 2923 The Nested/Concat model is equally applicable to MIPv6 with the major change 2924 being that the MN in IPv6 is able to rapidly acquire a local interface 2925 address from each FA. This address can then be used as a MN CCoA for the LA 2926 MIP layer to the RMA. The RMA would still allocate the RoA to the MN and the 2927 MN would once again use this RoA as a MN CCoA for the RA layer HoA. The 2928 remote access layer is therefore unchanged conceptually from the MIPv4 model. 2929 The FA in MIPv6 is replaced by a Local Mobility Agent(LMA), and the LMA and 2930 RMA could once again cooperate to control and manage local and remote access 2931 services in sympathy with the MN privileges and the operator policies. 2933 12. Security and AAA Considerations 2935 The security requirements and mechanisms behind all the features within this 2936 architecture need significant work and review. However, no major new security 2937 issues are raised, by the basic features in this draft, than are already 2938 considered in the design of MIPv4, regional tunnelling [RegTun], [RoutOpt] 2939 and reverse tunnelling [RevTun]. This is because at all times all information 2940 elements are authenticated to the same level as that demanded by existing MIP 2941 and AAA exchanges. Some of the new or assumed security mechanisms are 2942 highlighted below to help support this analysis. 2944 12.1 FA and RMA Auto-configuration 2946 The FA can authenticate itself to the local AAA system based on a FA-AAA SA, 2947 and then have the AAA system return its regionname, default RMA address, set 2948 of associated RMA addresses in the region, the FA-NAI and the RMA-FA key 2949 material for those SAs. Similarly, each RMA has an RMA_AAA SA and can obtain 2950 its regionname, role (default or associated), the set of region RMAs, the set 2951 of region FAs, and the key material for the RMA-RMA and RMA-FA SAs. The RMA- 2952 NAI could be for example the 'regionnameandnumber@domain'. 2954 The FA and RMA must share a Security Association (SA) to protect FA-RMA 2955 extensions and specifically to enable the FA to dynamically assign the FA CoA 2956 and forward it to the RMA using the HFAext. This SA can be pre-configured, 2957 distributed and maintained through IKE/IPSEC (or other such system), or 2958 managed and distributed through MIP mechanisms from the RMAs in a region. 2960 12.2 AAA Key Material Distribution 2962 The AAA system can be used for initiation of the MN-FA, MN-RMA, MN-HA, FA-RMA 2963 and RMA-HA SAs. These are used for the authentication extensions, to 2964 authenticate MIP messages and contained extensions between MIP nodes. Local 2965 AAA mechanisms already exist to configure MN-FA, FA-RMA and MN-RMA SAs for 2966 dynamic RMA assignment where the RMA is a local HA, and the AAA request is 2967 sent from the FA triggered by the LA RREQ. The FA-RMA can also be pre- 2968 configured as discussed in 13.1. Any RMA dynamically assigned by the FA must 2969 be communicated to the AAA system, for example using the equivalent of the 2970 HA-NAI, so that it can configure the RMA with the required key material for 2971 RMA-MN and RMA-FA (if not also preconfigured). For incremental deployment, 2972 this draft also considers an additional capability whereby the RMA key 2973 material can instead be delivered by the AAA system to the FA, and then 2974 forwarded to the RMA in an undefined extension protected by the pre-existing 2975 FA-RMA SA.The global AAA system is in many cases already able to dynamically 2976 assign a global HA and HoA and provide the required MN-HA and FA-HA. RegTun 2977 extends this to enable an intermediate GFA to be supported. The missing piece 2978 however is to enable the AAA system to first assign the LA elements from the 2979 LA Reg and then to assign the missing elements for the RA Reg. In addition, a 2980 Combined RA/LA Reg should be able to create all the required SAs together in 2981 a co-ordinated manner to enable efficient configuration in a single AAAH-AAAF 2982 round trip, and to also avoid duplication for key material by sharing MN-FA 2983 and FA-RMA between the two MIP layers. Additional RA layer signalling should 2984 then only trigger the AAA system via the FA, to provide the additional 2985 session specific HA/HoA parameters along with material to generate new MN-HA 2986 and RMA-HA SAs. The AAA system must in addition be able to deliver the MN-HA 2987 and RMA-HA generation material to the RMA and HA either through Diameter AAA 2988 routing or via additional RADIUS look-ups at the RMA and HA when incoming 2989 Registrations are received that demand such action as a result of a missing 2990 SA. These activities are improved through the use of HA-NAI and AAA-NAI as 2991 discussed in [AAA-NAI]. 2993 If the AAA system cannot support RMA-MN and MN-RMA key material distribution, 2994 then in the case of the FA and RMA sharing a pre-configured association it is 2995 possible that the FA can act as a security server and use a MN-FA SA obtained 2996 through MN authentication, and the FA-RMA SA to mutually configure the MN-RMA 2997 SAs. 2999 12.3 Inter-operator PRANE 3001 There is a slight concern with the inter-RMA inter-operator BU, that is 3002 triggered by the PRANE and which has a zero nRMA CoA. This is because this is 3003 generally not known until the nRMA is traversed. The MN calculation of the 3004 authenticator is then still based on the oRMA-MN auth SA but does not 3005 authenticate the missing RMA CoA. The assigned nRMA CoA is instead protected 3006 by an inter-RMA SA and inserted in a HFAext to the oRMA. However, the MN is 3007 still specifically stating that it is undertaking an inter-operator hand-off 3008 in the BU, the oRMA can see that it was directed via a specific RMA and any 3009 vulnerability is only for the duration of the transient forwarding. 3011 12.4 Forwarding Checks 3013 The GFA model seeks tight checks on the previous hop when packets are 3014 tunnelled from the HA to the GFA and onto the MN. This is to ensure packets 3015 are not falsely injected towards the HoA by a rogue element which either does 3016 not know the HA or GFA address, or cannot use them because of ingress 3017 filtering of source addresses. In the Nested Model and Concat models, 3018 significant effort is made to avoid HA/HoA specific state in the FA but this 3019 reduces the granularity of any check. In the Nested case, the MN still sees 3020 the originating HA and so can meet the requirements but only after the air- 3021 link has been traversed. It can also however rely on the RMA undertaking this 3022 check by keeping HA specific state or even HoA specific state. Concat mode 3023 again relies on a chain of trust with the FA having only MSCoA state and 3024 relying on the RMA to check the RoA destination address and to map the flow 3025 to the correct MSCoA. The MN cannot see the originating HA address and so the 3026 RMA HA state to match the HA and RoA to registrations appears more critical 3027 here although the fact that a registered RoA is used maybe sufficient and 3028 hence we can avoid HA specific state in the RMA for basic Concat forwarding. 3030 However, saying all that it is also apparent that a MN that also has local 3031 access is open to traffic from a range of CNs and so maybe the need for tight 3032 source checking is less pronounced if we can assume correct ingress filtering 3033 is in place. 3035 In the reverse tunnelling case, the source checking is required to avoid 3036 packets being injected into a private domain via the GFA and HA. This again 3037 requires a chain of trust but in both the Nested and Concat modes the RA 3038 reverse tunnel is from the RoA direct to the HA which significantly reduces 3039 any threats. If the LA reverse tunnel is also used then packets are routed 3040 first to the RMA where 3042 13. Notice Regarding Intellectual Property Rights 3044 Flarion's submissions will conform with RFC 2026. Flarion may seek patent 3045 protection on some or all of the technical information submitted by its 3046 employees in connection with the IETF's standards process. If part(s) of a 3047 submission by Flarion is (are) included in a standard and Flarion owns 3048 patent(s) and/or pending patent application(s) that are essential to 3049 implementation of such included part(s) in said standard, Flarion is prepared 3050 to grant a license on fair, reasonable, reciprocal (license back) and non- 3051 discriminatory terms on such included part(s). 3053 14. Acknowledgements 3055 George Tsirtsis of Flarion Technologies undertook detailed reviews of this 3056 document. 3058 15. References 3060 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, 3061 RFC 2026, October 1996. 3063 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3064 Levels", BCP 14, RFC 2119, March 1997 3066 [NestMIP] A.W. O'Neill, ``Nested MIP," Internet-draft, draft-ietf-oneill-mip- 3067 nested-00.txt, April 2002. 3069 [PCCoA] A.W. O'Neill, ``Proxy CCoA Tunnelling for Mobile IP," Internet-draft, 3070 draft-oneill-mip-proxyCCoA-00.txt, May 2002. 3072 [MIPv4] C.E. Perkins, Ed., "IP Mobility Support for IPv4," RFC3220, Jan 2002. 3074 [RegTun] E. Gustafsson. Ed., " Mobile IPv4 Regional Registration, 3075 Internet-draft, draft-ietf-mobileip-reg-tunnel-06.txt, 1March 2002 3077 [RegTunMods] A. O'Neill, "Modifications to Regional Tunnelling", Internet- 3078 draft, draft-oneill-mip-regtun-mods-00.txt, 9 April 2002. 3080 [RevTun] G. Montenegro, Ed., "Reverse Tunnelling for Mobile IP, revised," 3081 Internet RFC 3024, January 2001. 3083 [RevTunMods] A. O'Neill, "Hand-off Extensions for Reverse Tunnelling", 3084 Internet-draft, draft-oneill-mip-revtun-ho-00.txt, 22 Feb 2002. 3086 [NestMIP] A. O'Neill, "Nested MIP for IP Mobility Management", Internet 3087 Draft, draft-oneill-mip-nested-00.txt, May 2002. 3089 [ConcatMIP] A. O'Neill, "Concatenated MIP for IP Mobility Management", 3090 Internet Draft, draft-oneill-mip-concat-00.txt, May 2002. 3092 [RMAsig] A. O'Neill, "Regional Mobility Agent Signalling", Internet-draft, 3093 draft-oneill-mip-rmasig-00.txt, May. 3095 [MIPAAA] Charles E. Perkins, Pat R. Calhoun, "AAA Registration Keys for 3096 Mobile IP", draft-ietf-mobileip-aaa-key-09.txt, 26 February 2002. 3098 [RoutOpt] C. Perkins, D. Johnson, "Route Optimization in Mobile IP", 3099 Internet-Draft, draft-ietf-mobileip-optim-11.txt, 6 September 2001. 3101 [LowLat] K.E. Malki, Ed., "Low Latency Handoffs in Mobile IPv4", Internet- 3102 Draft, draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt, November 2001. 3104 [MIPv6] D. Johnson, C. Perkins, ``Mobility Support in IPv6", Internet-Draft, 3105 draft-ietf-mobileip-ipv6-16.txt (work in progress), 22 March 2002. 3107 [AAANAI] T. Johansson, F. Johansson, 'AAA NAI for Mobile IPv4 Extension', 3108 Internet Draft, draft-johansson-mip-aaa-nai-01.txt, 09-Apr-02. 3110 Author's Addresses 3112 Alan O'Neill 3113 Flarion Technologies 3114 Phone: +1 908 947 7033 3115 Email: oneill@flarion.com