Personal A. O'Neill Internet Draft Flarion Technologies Document: draft-oneill-mip-parallel-00.txt 8 May 2002 Expires: Oct 2002 Parallel MIP for Aggregated Mobility Management <draft-oneill-mip-parallel-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Nested MIP [NestMIP] provides a means to support both localization and aggregation of MIP signalling. It achieves this by providing two distinct layers of MIP signalling and forwarding; a local access layer that provides local mobility management and local access services, and a remote access layer that provides remote access back to a home subnet. Nested MIP and an associated proposal, Concatenated MIP [ConcatMIP] are necessary because existing MIP signalling is HA/HoA specific and therefore not easily amenable to aggregation for supporting multiple MIP sessions per MN. This document describes an alternative proposal for introducing aggregation that has significantly lower functionality but that is a smaller change from existing MIP standards and implementations. It is described here for completeness as part of the overall problem space. The solution uses a single HA/HoA specific MIP Registration as a master signal within which is carried an extension that defines an include/exclude list of the other HA/HoA pairs that should/should not be handed off. This extension can be carried in inter- FA hand-off signals and in regional registrations, and is also used within Nested/Concat MIP. A.W. O'Neill Expires Oct 2002 [Page 1]
INTERNET-DRAFT Parallel MIP for Aggregated Mobility Management May 2002 INDEX Abstract 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . . . . 3 3. Terminology used in this document . . . . . . . . . . . . . . . . . 3 4. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. The Parallel Model. . . . . . . . . . . . . . . . . . . . . . . . . 3 5.1. Registration and Visitor Lists. . . . . . . . . . . . . . . . . . 3 5.2. Inter-FA Hand-off . . . . . . . . . . . . . . . . . . . . . . . . 4 5.3. Regional Regsitration . . . . . . . . . . . . . . . . . . . . . . 4 5.4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . . . 5 6. Hand-off Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 7. Other Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Notice Regarding Intellectual Property Rights. . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Nested MIP [NestMIP] provides a means to support both localization and aggregation of MIP signalling. It achieves this by providing two distinct layers of MIP signalling and forwarding; a local access layer that provides local mobility management and local access services, and a remote access layer that provides remote access back to a home subnet. Nested MIP and an associated proposal, Concatenated MIP [ConcatMIP] are necessary because existing MIP signalling is HA/HoA specific and therefore not easily amenable to aggregation for supporting multiple MIP sessions per MN. This document describes an alternative proposal for introducing aggregation that has significantly lower functionality but that is a smaller change from existing MIP standards and implementations. The solution uses a single HA/HoA specific MIP Registration as a master signal within which is carried an extension that defines an include/exclude list of the other HA/HoA pairs that should/should not be handed off. This extension can be carried in inter-FA hand-off signals and in regional registrations, and is also used within Nested/Concat MIP. A complementary HoA Response Extension is used to confirm that the aggregated hand-off has been undertaken by returning the include/exclude list to the MN via the FA. Essentially, this means that the aggregated signals become MN centric rather than HA/HoA centric and is clearly only possible when the MIP Registration is not actually directed at the HA. A.W. O'Neill Expires Oct 2002 [Page 2]
INTERNET-DRAFT Parallel MIP for Aggregated Mobility Management May 2002 Parallel MIP is described here for completeness as part of the overall problem space covered by Nested and Concatenated MIP, and specifically its limitations contribute strongly to the architecture developed for Nested/Concat MIP. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 3. Terminology used in this document Much of the terminology used in this document borrows from Mobile IPv4 [MIPv4], MIP Regional Tunneling [RegTun], MIP Reverse Tunneling [RevTun], MIP Route Optimisation [RoutOpt] and Nested/Concatenated MIP. This draft introduces the following additional terminology. HoA Request List Extension (HoAList) - HA/HoA pairs in aggregate HoA Response List Extension (HoAResp) - Modified HA/HoA pairs returned 4. Motivation The motivation for this work is described fully in [NestMIP] and in the introduction text. The intension is to describe the limitations of an aggregation model that is parallel rather than layered, but that can potentially be more readily deployed in constrained circumstances. 5. The Parallel Model 5.1 Registration and Visitor lists Each MIP session still clearly requires a Registration between the MN and the HA via the FA when necessary. This registration is HA/HoA specific and installs HA/HoA/CoA state in the MIP elements where the CoA can be shared across multiple such registrations from the same MN (CCoA) or FA (FA CoA). If the MN needs many such sessions then existing MIP will lead to a signalling round trip to each HA for each HA/HoA pair. Clearly though the visitor list state in the MN and FA can be aggregated such that the MN specific state (link-layer address, CoA etc) is stored once with each registration generating additional HA/HoA pairs, MN-HA and FA-HA SAs, Identification field maintenance, flags etc. This is however a minor benefit from aggregation A.W. O'Neill Expires Oct 2002 [Page 3]
INTERNET-DRAFT Parallel MIP for Aggregated Mobility Management May 2002 5.2 Inter-FA hand-off When a MN moves between access routers that contain FAs, the opportunity exists to undertake transient forwarding and CT between those FAs to forward arriving in-flight packets to the new FA and to also transfer control state. Presently, the [lowlat] and [RoutOpt] mechanisms for achieving this are HA/HoA specific and not MN specific. Therefore, a MN that has multiple MIP sessions with distant HAs will need to generate a registration per HA/HoA pair towards the HA as well as (in the case of PFANE) a BU to the old FA per HA/HoA pair. The HA update is clearly unavoidable but a single BU, to represent the movement of the MN rather than of its MIP sessions should be possible. Nested/Concat MIP use such a MN specific signal but a similar result can be achieved by using a BU for a single master HA/HoA pair along with a HoAlist extension that lists the other HA/HoA pairs to move through an include/exclude list. The include/exclude idea is borrowed from IGMPv3 to enable an efficient representation to be made by the MN. For example, the presence of the extension in exclude mode with a zero list will cause all HA/HoA pairs to be forwarded. An extension is required here so that the return of a HoAResp can be triggered at the oFA so that the nFA and MN know that the sessions are being forwarded and hence provides backwards compatibility. The FA should prime its HA/HoA state from the Registrations towards the HAs and inter-FA forwarding should be supported for those HA/HoA pairs implied by the HoAlist as modified by the changes described in the HoAResp include/exclude list. The HoAResp should echo the HoAList if no additional changes are necessary. The HoAResp can exclude a HA/HoA pair for policy reasons or due to a registration timeout at the old FA, and can include a HA/HoA pair that was missing from the HoAlist as a reminder or to indicate an error, and should not forward for that HA/HoA pair unless an additional BU is sent. The HoAlist and HoAResp extensions need to be protected by authentication. In the case of PFANE, the MN needs to calculate an authenticator that includes the HoAlist extension which must not therefore be modified by the FA. The MN- FA protects the HoAlist extension over the air interface. The HoAResp in the BUack is protected by the oFA-MN auth extension and can be read by the nFA but any changes from the HoAlist must not acted on by the FA which should wait for any triggered MN action. The HoAlist/Resp extensions are defined in [RMAsig]. 5.3 Regional Registration When a MN is using a GFA, an additional opportunity exists for aggregation of signalling between the MN-FA-GFA during a regional registration rather than a home registration. The MN issues parallel home registration messages via the GFA and gets back multiple identifications fields for matching, ordering and replay protection purposes. The MN then needs to start a separate identification field exchange as part of the regional registration using a master HA/HoA pair to refresh the FA CoA. The regional registration also however includes the HoAlist extension that enables a single MIP regional registration to update the CoA field for all HA/HoA pairs in that GFA. A.W. O'Neill Expires Oct 2002 [Page 4]
INTERNET-DRAFT Parallel MIP for Aggregated Mobility Management May 2002 This is only possible if all the MIP flags and other features are shared for all the HA/HoA specific sessions between the MN, FA and GFA. Restating, the flags in the home registration, for each HA/HoA pair, are interpreted as only representing the features between the GFA and that HA. The regional registration overrules the features on the section between the GFA and FA/MN when the HoAlist extension is included. The GFA then needs to map between the common features and the HA specific features wrt tunneling technique. One exception to this is reverse tunneling which can clearly be handled independently at the FA based on the home registration flags. Once again, the HoAResp is used to indicate addition HA/HoA pairs that can trigger an additional regional registration. This can also indicate a failure for a specific HA/HoA pair that might trigger a HA specific home registration. Note also that in general, returned error codes now need to be indexed by the HA/HoA pair in a new HoAErr extension unless they are general or associated with the master HA/HoA pair. 5.4 Backwards Compatibility Clearly, if a HoAlist extension is not sent by a MN then the FA and GFA will only act on the HA/HoA included in the MIP registration. If a HoAResp extension is not returned by a GFA or FA then the MN needs to issue multiple registrations as the extensions are not supported. If the FA does not understand the HoAlist/Resp extensions then they are stripped so that the GFA and the MN can determine that no aggregated forwarding is possible. 6. Hand-off Limitations Special mention needs to be made of the consequences of each FA and/or GFA hand-off. In the case of the FA hand-off, some aggregation benefits are achieved for the inter-FA forwarding by avoiding the need for multiple Bus. No such forwarding however exists between GFAs (although is supported in Nested MIP), during inter-GFA hand-off. One of the benefits of supporting inter-GFA, and old GFA to new FA transient forwarding is to enable time in which the home registrations can be spread out to reduce data interference, with only the master registration needing to be sent immediately to acquire the new GFA and to set-up transient forwarding from the old GFA. Therefore, the aggregation benefits in the GFA model only come with subsequent messaging following the immediate flood of MIP home registrations that is triggered by the new GFA, to configure that new GFA in the HAs. The aggregated regional registration to the GFA is also fine for refreshing state from an old FA but, most critically, on FA hand-off, is unable to rebuild the state at the new FA that exists at the old FA. This state, in the absence of a GFA, is built by the individual registrations back to the HA that are triggered by the inner-FA hand-off. By analogy, the aggregated regional registration must therefore list all HA/HoA pairs in the HoAlist so that the new FA can install this new state into the visitor list, and additional extensions must be devised to carry the aggregation of the all flags and features for this MN in the old FA. This clearly completely compromises the aggregation objective. A.W. O'Neill Expires Oct 2002 [Page 5]
INTERNET-DRAFT Parallel MIP for Aggregated Mobility Management May 2002 An alternative is to use the inter-FA HoAlist extension and the BU to trigger Context Transfer of all the old FA state, for the implied HA/HoA pairs, forward to the new FA. This is however potentially a significant amount of information, and it must be very reliably and instantaneously delivered to the new FA. With the laws of physics preventing either of these objectives being possible it is clear that the architecture is pretty flawed in the case of a GFA, and is equally limited in the absence of a GFA due to flood of home registrations. This therefore fully motivates the alternative architecture behind Nested/Concat MIP where this critical limitation is avoided. 7. Other Limitations Firstly, in the case of inter-FA and GFA signalling it is clear that as the number of HA/HoA pairs grows then the HoAlist/Resp can potentially become cumbersome when all the sessions are not to be transferred. In addition, the HoAErr extension could also become damaging when a large number of errors are generated. In both cases, the extension size must be strictly limited to avoid disturbing traffic at the cost of loss of forwarding or information. Secondly, HA/HoA specific hand-off features and tunnelling features are not supported but this is a natural consequence of aggregation. Features are also arranged on a master RA layer HA/HoA pair rather than on a separate LA layer as used in Nested/Concat MIP. This leads to complications when the MIP session of the master pair is lost due to an error or dropped intentionally. More problematic, in the case of GFA, is the fact that the GFA is intended to be a node at the top of a domain and hence for a large domain, with many such GFAs, aggregation through a single GFA comes at the cost of indirectness of forwarding for many of the HA/HoA specific sessions. The RMA from Nested MIP is in contrast low in the domain and close to the FAs at the nearest POP. Finally, the GFA model as with the Concat model has a common regional tunnel for a number of HA/HoA sessions, whose preferences for that tunnel must be potentially overruled. This is not the case in Nested MIP where the RA layer features are unaffected by the LA layer features to a large extent. 8. IPv6 Considerations The Parallel model is equally applicable, and equally problematic, to MIPv6 with the major changes being that the MN in MIPv6 is able to rapidly acquire a local interface address from each edge subnet and the obvious absence of an FA. The aggregation is once again achieved through a simple extension request and response mechanism. 9. Security Considerations No new security issues are raised by this draft than are already considered in the design of MIPv4, regional tunnelling [RegTun], [RoutOpt] and reverse tunnelling [RevTun]. At all times all information elements are authenticated to the same level as that demanded by MIP and AAA exchanges. A.W. O'Neill Expires Oct 2002 [Page 6]
INTERNET-DRAFT Parallel MIP for Aggregated Mobility Management May 2002 10. Notice Regarding Intellectual Property Rights Flarion's submissions will conform with RFC 2026. Flarion may seek patent protection on some or all of the technical information submitted by its employees in connection with the IETF's standards process. If part(s) of a submission by Flarion is (are) included in a standard and Flarion owns patent(s) and/or pending patent application(s) that are essential to implementation of such included part(s) in said standard, Flarion is prepared to grant a license on fair, reasonable, reciprocal (license back) and non- discriminatory terms on such included part(s). 11. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [NestMIP] A.W. O'Neill, ``Nested MIP for mobility management," Internet- draft, draft-ietf-oneill-mip-nested-00.txt, May 2002. [ConcatMIP] A.W. O'Neill, ``Concatenated MIP for mobility management," Internet-draft, draft-ietf-oneill-mip-nested-00.txt, May 2002. [RegTunMods] A.W. O'Neill, ``Modifications to Regional Tunneling," Internet- draft, draft-ietf-oneill-mip-regtun-mods-00.txt, April 2002. [RevTunHO] A.W. O'Neill, ``Hand-Off Extensions for Reverse Tunneling," Internet-draft, draft-ietf-oneill-mip-revtun-ho-00.txt, April 2002. [PCCoA] A.W. O'Neill, ``Proxy CCoA Tunneling for Mobile IP," Internet-draft, draft-oneill-mip-proxyCCoA-00.txt, May 2002. [MIPv4] C.E. Perkins, Ed., `` IP Mobility Support for IPv4, revised," Internet-draft, draft-ietf-mobileip-rfc2002-bis-08.txt, 19 September 2001 [RegTun] E. Gustafsson. Ed., " Mobile IPv4 Regional Registration, Internet- draft, draft-ietf-mobileip-reg-tunnel-06.txt, 1March 2002. [RoutOpt] C. Perkins, D. Johnson, "Route Optimization in Mobile IP", Internet-Draft, draft-ietf-mobileip-optim-11.txt), 6 September 2001. [LowLat] K.E. Malki, Ed., "Low Latency Handoffs in Mobile IPv4", Internet- Draft, draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt, November 2001. [MIPv6] D. Johnson, C. Perkins, ``Mobility Support in IPv6", Internet-Draft, draft-ietf-mobileip-ipv6-16.txt (work in progress), 22 March 2002. Author's Addresses Alan O'Neill Flarion Technologies Phone: +1 908 947 7033 Email: oneill@flarion.com A.W. O'Neill Expires Oct 2002 [Page 7]