idnits 2.17.1 draft-oneill-mip-parallel-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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 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 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 171 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([ConcatMIP], [NestMIP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 48 has weird spacing: '...defines an in...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (8 May 2002) is 7995 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: 'RevTun' is mentioned on line 309, but not defined == Missing Reference: 'RMAsig' is mentioned on line 189, but not defined == Unused Reference: 'RFC2026' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'RegTunMods' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'RevTunHO' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'PCCoA' is defined on line 343, but no explicit reference was found in the text == Unused Reference: 'LowLat' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'MIPv6' is defined on line 358, but no explicit reference was found in the text -- No information found for draft-ietf-oneill-mip-nested - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NestMIP' -- No information found for draft-ietf-oneill-mip-nested - is the name correct? -- Duplicate reference: draft-ietf-oneill-mip-nested, mentioned in 'ConcatMIP', was also mentioned in 'NestMIP'. -- Possible downref: Normative reference to a draft: ref. 'ConcatMIP' -- No information found for draft-ietf-oneill-mip-regtun-mods - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RegTunMods' -- No information found for draft-ietf-oneill-mip-revtun-ho - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RevTunHO' -- No information found for draft-oneill-mip-proxyCCoA - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PCCoA' == 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. '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 Summary: 7 errors (**), 0 flaws (~~), 17 warnings (==), 15 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-parallel-00.txt 8 May 2002 4 Expires: Oct 2002 6 Parallel MIP for Aggregated Mobility Management 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] provides a means to support both localization and 35 aggregation of MIP signalling. It achieves this by providing two distinct 36 layers of MIP signalling and forwarding; a local access layer that provides 37 local mobility management and local access services, and a remote access 38 layer that provides remote access back to a home subnet. Nested MIP and an 39 associated proposal, Concatenated MIP [ConcatMIP] are necessary because 40 existing MIP signalling is HA/HoA specific and therefore not easily amenable 41 to aggregation for supporting multiple MIP sessions per MN. 43 This document describes an alternative proposal for introducing aggregation 44 that has significantly lower functionality but that is a smaller change from 45 existing MIP standards and implementations. It is described here for 46 completeness as part of the overall problem space. The solution uses a single 47 HA/HoA specific MIP Registration as a master signal within which is carried 48 an extension that defines an include/exclude list of the other HA/HoA pairs 49 that should/should not be handed off. This extension can be carried in inter- 50 FA hand-off signals and in regional registrations, and is also used within 51 Nested/Concat MIP. 53 INDEX 54 Abstract 56 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . . . . 3 60 3. Terminology used in this document . . . . . . . . . . . . . . . . . 3 62 4. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 5. The Parallel Model. . . . . . . . . . . . . . . . . . . . . . . . . 3 65 5.1. Registration and Visitor Lists. . . . . . . . . . . . . . . . . . 3 66 5.2. Inter-FA Hand-off . . . . . . . . . . . . . . . . . . . . . . . . 4 67 5.3. Regional Regsitration . . . . . . . . . . . . . . . . . . . . . . 4 68 5.4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . . . 5 70 6. Hand-off Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 72 7. Other Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 6 76 9. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . . . 6 78 10. Notice Regarding Intellectual Property Rights. . . . . . . . . . . 7 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 Nested MIP [NestMIP] provides a means to support both localization and 85 aggregation of MIP signalling. It achieves this by providing two distinct 86 layers of MIP signalling and forwarding; a local access layer that provides 87 local mobility management and local access services, and a remote access 88 layer that provides remote access back to a home subnet. Nested MIP and an 89 associated proposal, Concatenated MIP [ConcatMIP] are necessary because 90 existing MIP signalling is HA/HoA specific and therefore not easily amenable 91 to aggregation for supporting multiple MIP sessions per MN. 93 This document describes an alternative proposal for introducing aggregation 94 that has significantly lower functionality but that is a smaller change from 95 existing MIP standards and implementations. The solution uses a single HA/HoA 96 specific MIP Registration as a master signal within which is carried an 97 extension that defines an include/exclude list of the other HA/HoA pairs that 98 should/should not be handed off. This extension can be carried in inter-FA 99 hand-off signals and in regional registrations, and is also used within 100 Nested/Concat MIP. A complementary HoA Response Extension is used to confirm 101 that the aggregated hand-off has been undertaken by returning the 102 include/exclude list to the MN via the FA. Essentially, this means that the 103 aggregated signals become MN centric rather than HA/HoA centric and is 104 clearly only possible when the MIP Registration is not actually directed at 105 the HA. 107 Parallel MIP is described here for completeness as part of the overall 108 problem space covered by Nested and Concatenated MIP, and specifically its 109 limitations contribute strongly to the architecture developed for 110 Nested/Concat MIP. 112 2. Conventions used in this document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 115 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 116 be interpreted as described in RFC-2119 [RFC2119]. 118 3. Terminology used in this document 120 Much of the terminology used in this document borrows from Mobile IPv4 121 [MIPv4], MIP Regional Tunneling [RegTun], MIP Reverse Tunneling [RevTun], MIP 122 Route Optimisation [RoutOpt] and Nested/Concatenated MIP. This draft 123 introduces the following additional terminology. 125 HoA Request List Extension (HoAList) - HA/HoA pairs in aggregate 126 HoA Response List Extension (HoAResp) - Modified HA/HoA pairs returned 128 4. Motivation 130 The motivation for this work is described fully in [NestMIP] and in the 131 introduction text. The intension is to describe the limitations of an 132 aggregation model that is parallel rather than layered, but that can 133 potentially be more readily deployed in constrained circumstances. 135 5. The Parallel Model 137 5.1 Registration and Visitor lists 139 Each MIP session still clearly requires a Registration between the MN and the 140 HA via the FA when necessary. This registration is HA/HoA specific and 141 installs HA/HoA/CoA state in the MIP elements where the CoA can be shared 142 across multiple such registrations from the same MN (CCoA) or FA (FA CoA). If 143 the MN needs many such sessions then existing MIP will lead to a signalling 144 round trip to each HA for each HA/HoA pair. Clearly though the visitor list 145 state in the MN and FA can be aggregated such that the MN specific state 146 (link-layer address, CoA etc) is stored once with each registration 147 generating additional HA/HoA pairs, MN-HA and FA-HA SAs, Identification field 148 maintenance, flags etc. This is however a minor benefit from aggregation 150 5.2 Inter-FA hand-off 152 When a MN moves between access routers that contain FAs, the opportunity 153 exists to undertake transient forwarding and CT between those FAs to forward 154 arriving in-flight packets to the new FA and to also transfer control state. 155 Presently, the [lowlat] and [RoutOpt] mechanisms for achieving this are 156 HA/HoA specific and not MN specific. Therefore, a MN that has multiple MIP 157 sessions with distant HAs will need to generate a registration per HA/HoA 158 pair towards the HA as well as (in the case of PFANE) a BU to the old FA per 159 HA/HoA pair. The HA update is clearly unavoidable but a single BU, to 160 represent the movement of the MN rather than of its MIP sessions should be 161 possible. Nested/Concat MIP use such a MN specific signal but a similar 162 result can be achieved by using a BU for a single master HA/HoA pair along 163 with a HoAlist extension that lists the other HA/HoA pairs to move through an 164 include/exclude list. The include/exclude idea is borrowed from IGMPv3 to 165 enable an efficient representation to be made by the MN. For example, the 166 presence of the extension in exclude mode with a zero list will cause all 167 HA/HoA pairs to be forwarded. An extension is required here so that the 168 return of a HoAResp can be triggered at the oFA so that the nFA and MN know 169 that the sessions are being forwarded and hence provides backwards 170 compatibility. 172 The FA should prime its HA/HoA state from the Registrations towards the HAs 173 and inter-FA forwarding should be supported for those HA/HoA pairs implied by 174 the HoAlist as modified by the changes described in the HoAResp 175 include/exclude list. The HoAResp should echo the HoAList if no additional 176 changes are necessary. The HoAResp can exclude a HA/HoA pair for policy 177 reasons or due to a registration timeout at the old FA, and can include a 178 HA/HoA pair that was missing from the HoAlist as a reminder or to indicate an 179 error, and should not forward for that HA/HoA pair unless an additional BU is 180 sent. 182 The HoAlist and HoAResp extensions need to be protected by authentication. In 183 the case of PFANE, the MN needs to calculate an authenticator that includes 184 the HoAlist extension which must not therefore be modified by the FA. The MN- 185 FA protects the HoAlist extension over the air interface. The HoAResp in the 186 BUack is protected by the oFA-MN auth extension and can be read by the nFA 187 but any changes from the HoAlist must not acted on by the FA which should 188 wait for any triggered MN action. The HoAlist/Resp extensions are defined in 189 [RMAsig]. 191 5.3 Regional Registration 193 When a MN is using a GFA, an additional opportunity exists for aggregation of 194 signalling between the MN-FA-GFA during a regional registration rather than a 195 home registration. The MN issues parallel home registration messages via the 196 GFA and gets back multiple identifications fields for matching, ordering and 197 replay protection purposes. The MN then needs to start a separate 198 identification field exchange as part of the regional registration using a 199 master HA/HoA pair to refresh the FA CoA. The regional registration also 200 however includes the HoAlist extension that enables a single MIP regional 201 registration to update the CoA field for all HA/HoA pairs in that GFA. 203 This is only possible if all the MIP flags and other features are shared 204 for all the HA/HoA specific sessions between the MN, FA and GFA. Restating, 205 the flags in the home registration, for each HA/HoA pair, are interpreted as 206 only representing the features between the GFA and that HA. The regional 207 registration overrules the features on the section between the GFA and FA/MN 208 when the HoAlist extension is included. The GFA then needs to map between the 209 common features and the HA specific features wrt tunneling technique. One 210 exception to this is reverse tunneling which can clearly be handled 211 independently at the FA based on the home registration flags. 213 Once again, the HoAResp is used to indicate addition HA/HoA pairs that can 214 trigger an additional regional registration. This can also indicate a failure 215 for a specific HA/HoA pair that might trigger a HA specific home 216 registration. Note also that in general, returned error codes now need to be 217 indexed by the HA/HoA pair in a new HoAErr extension unless they are general 218 or associated with the master HA/HoA pair. 220 5.4 Backwards Compatibility 222 Clearly, if a HoAlist extension is not sent by a MN then the FA and GFA will 223 only act on the HA/HoA included in the MIP registration. 225 If a HoAResp extension is not returned by a GFA or FA then the MN needs to 226 issue multiple registrations as the extensions are not supported. 228 If the FA does not understand the HoAlist/Resp extensions then they are 229 stripped so that the GFA and the MN can determine that no aggregated 230 forwarding is possible. 232 6. Hand-off Limitations 234 Special mention needs to be made of the consequences of each FA and/or GFA 235 hand-off. In the case of the FA hand-off, some aggregation benefits are 236 achieved for the inter-FA forwarding by avoiding the need for multiple Bus. 238 No such forwarding however exists between GFAs (although is supported in 239 Nested MIP), during inter-GFA hand-off. One of the benefits of supporting 240 inter-GFA, and old GFA to new FA transient forwarding is to enable time in 241 which the home registrations can be spread out to reduce data interference, 242 with only the master registration needing to be sent immediately to acquire 243 the new GFA and to set-up transient forwarding from the old GFA. Therefore, 244 the aggregation benefits in the GFA model only come with subsequent messaging 245 following the immediate flood of MIP home registrations that is triggered by 246 the new GFA, to configure that new GFA in the HAs. 248 The aggregated regional registration to the GFA is also fine for refreshing 249 state from an old FA but, most critically, on FA hand-off, is unable to 250 rebuild the state at the new FA that exists at the old FA. This state, in the 251 absence of a GFA, is built by the individual registrations back to the HA 252 that are triggered by the inner-FA hand-off. By analogy, the aggregated 253 regional registration must therefore list all HA/HoA pairs in the HoAlist so 254 that the new FA can install this new state into the visitor list, and 255 additional extensions must be devised to carry the aggregation of the all 256 flags and features for this MN in the old FA. This clearly completely 257 compromises the aggregation objective. 259 An alternative is to use the inter-FA HoAlist extension and the BU to trigger 260 Context Transfer of all the old FA state, for the implied HA/HoA pairs, 261 forward to the new FA. This is however potentially a significant amount of 262 information, and it must be very reliably and instantaneously delivered to 263 the new FA. With the laws of physics preventing either of these objectives 264 being possible it is clear that the architecture is pretty flawed in the case 265 of a GFA, and is equally limited in the absence of a GFA due to flood of home 266 registrations. 268 This therefore fully motivates the alternative architecture behind 269 Nested/Concat MIP where this critical limitation is avoided. 271 7. Other Limitations 273 Firstly, in the case of inter-FA and GFA signalling it is clear that as the 274 number of HA/HoA pairs grows then the HoAlist/Resp can potentially become 275 cumbersome when all the sessions are not to be transferred. In addition, the 276 HoAErr extension could also become damaging when a large number of errors are 277 generated. In both cases, the extension size must be strictly limited to 278 avoid disturbing traffic at the cost of loss of forwarding or information. 280 Secondly, HA/HoA specific hand-off features and tunnelling features are not 281 supported but this is a natural consequence of aggregation. Features are also 282 arranged on a master RA layer HA/HoA pair rather than on a separate LA layer 283 as used in Nested/Concat MIP. This leads to complications when the MIP 284 session of the master pair is lost due to an error or dropped intentionally. 286 More problematic, in the case of GFA, is the fact that the GFA is intended to 287 be a node at the top of a domain and hence for a large domain, with many such 288 GFAs, aggregation through a single GFA comes at the cost of indirectness of 289 forwarding for many of the HA/HoA specific sessions. The RMA from Nested MIP 290 is in contrast low in the domain and close to the FAs at the nearest POP. 292 Finally, the GFA model as with the Concat model has a common regional tunnel 293 for a number of HA/HoA sessions, whose preferences for that tunnel must be 294 potentially overruled. This is not the case in Nested MIP where the RA layer 295 features are unaffected by the LA layer features to a large extent. 297 8. IPv6 Considerations 299 The Parallel model is equally applicable, and equally problematic, to MIPv6 300 with the major changes being that the MN in MIPv6 is able to rapidly acquire 301 a local interface address from each edge subnet and the obvious absence of an 302 FA. The aggregation is once again achieved through a simple extension request 303 and response mechanism. 305 9. Security Considerations 307 No new security issues are raised by this draft than are already considered 308 in the design of MIPv4, regional tunnelling [RegTun], [RoutOpt] and reverse 309 tunnelling [RevTun]. At all times all information elements are authenticated 310 to the same level as that demanded by MIP and AAA exchanges. 312 10. Notice Regarding Intellectual Property Rights 314 Flarion's submissions will conform with RFC 2026. Flarion may seek patent 315 protection on some or all of the technical information submitted by its 316 employees in connection with the IETF's standards process. If part(s) of a 317 submission by Flarion is (are) included in a standard and Flarion owns 318 patent(s) and/or pending patent application(s) that are essential to 319 implementation of such included part(s) in said standard, Flarion is prepared 320 to grant a license on fair, reasonable, reciprocal (license back) and non- 321 discriminatory terms on such included part(s). 323 11. References 325 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, 326 RFC 2026, October 1996. 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement 329 Levels", BCP 14, RFC 2119, March 1997 331 [NestMIP] A.W. O'Neill, ``Nested MIP for mobility management," Internet- 332 draft, draft-ietf-oneill-mip-nested-00.txt, May 2002. 334 [ConcatMIP] A.W. O'Neill, ``Concatenated MIP for mobility management," 335 Internet-draft, draft-ietf-oneill-mip-nested-00.txt, May 2002. 337 [RegTunMods] A.W. O'Neill, ``Modifications to Regional Tunneling," Internet- 338 draft, draft-ietf-oneill-mip-regtun-mods-00.txt, April 2002. 340 [RevTunHO] A.W. O'Neill, ``Hand-Off Extensions for Reverse Tunneling," 341 Internet-draft, draft-ietf-oneill-mip-revtun-ho-00.txt, April 2002. 343 [PCCoA] A.W. O'Neill, ``Proxy CCoA Tunneling for Mobile IP," Internet-draft, 344 draft-oneill-mip-proxyCCoA-00.txt, May 2002. 346 [MIPv4] C.E. Perkins, Ed., `` IP Mobility Support for IPv4, revised," 347 Internet-draft, draft-ietf-mobileip-rfc2002-bis-08.txt, 19 September 2001 349 [RegTun] E. Gustafsson. Ed., " Mobile IPv4 Regional Registration, Internet- 350 draft, draft-ietf-mobileip-reg-tunnel-06.txt, 1March 2002. 352 [RoutOpt] C. Perkins, D. Johnson, "Route Optimization in Mobile IP", 353 Internet-Draft, draft-ietf-mobileip-optim-11.txt), 6 September 2001. 355 [LowLat] K.E. Malki, Ed., "Low Latency Handoffs in Mobile IPv4", Internet- 356 Draft, draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt, November 2001. 358 [MIPv6] D. Johnson, C. Perkins, ``Mobility Support in IPv6", Internet-Draft, 359 draft-ietf-mobileip-ipv6-16.txt (work in progress), 22 March 2002. 361 Author's Addresses 363 Alan O'Neill 364 Flarion Technologies 365 Phone: +1 908 947 7033 366 Email: oneill@flarion.com