Personal A. O'Neill Internet Draft Flarion Technologies Document: draft-oneill-mip-rmasig-00.txt 8 May 2002 Expires: Oct 2002 Regional Mobility Agent Signalling 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] and Concatenated MIP [ConcatMIP] provide means to support both localization and aggregation of MIP signalling. They achieve 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. The local access layer provides a regional address from a Regional Mobility Agent (a regional HA) that is then used as a CCoA for the remote access layer. Inter-FA movement and MIP signalling at the local access layer then automatically supports the hand-off of potentially multiple parallel remote access sessions. Nested MIP achieves this through encapsulation whilst Concatenated MIP achieves it though various forms of CoA switching. This draft describes the localised and aggregated MIP signalling model for managing both the Local Access and Remote Access MIP layers. This includes inter-FA and Inter-RMA hand-offs within and between Nesting and Concatenating Regional Mobility Agents. This is necessary to support incremental, heterogeneous deployment that is required given that Nested MIP is deployable now whilst Concatenated MIP requires additional and significant standards and development work. A.W. O'Neill Expires Oct 2002 [Page 1] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 INDEX Abstract 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . . . . 4 3. Terminology used in this document . . . . . . . . . . . . . . . . . 4 4. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. MIP Registration Overview . . . . . . . . . . . . . . . . . . . . . 5 5.1 LA Signalling Summary . . . . . . . . . . . . . . . . . . . . . 7 5.2 RA Signalling Summary . . . . . . . . . . . . . . . . . . . . . 7 5.3 Combined LA/RA Signalling Summary . . . . . . . . . . . . . . . 8 5.4. LA / RA Visitor Lists. . . . . . . . . . . . . . . . . . . . . 9 5.5. Summary of LA and RA Forwarding Modes. . . . . . . . . . . . . 11 5.6. Distinguishing LA and RA MIP Messages. . . . . . . . . . . . . 17 5.7 Summary of MIP Signalling Additions . . . . . . . . . . . . . . 19 5.8 Backwards Compatibility Issues . . . . . . . . . . . . . . . . 21 5.9 Signalling and Forwarding Evolution . . . . . . . . . . . . . . 22 6. Registration Refresh and Hand-Off Processing. . . . . . . . . . . . 23 6.1 LA Refresh. . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.2 LA Hand-off (Inter-FA). . . . . . . . . . . . . . . . . . . . . 24 6.3 LA Hand-off (Inter-RMA, Inter-FA) . . . . . . . . . . . . . . . 25 6.4 Enhanced LA Hand-off (Inter-RMA, Inter-FA). . . . . . . . . . . 26 6.5 RA Layer Registration Update. . . . . . . . . . . . . . . . . . 27 6.6 RA Hand-off (inter-RMA, optionally inter-FA). . . . . . . . . . 29 6.7 Combined LA/RA Hand-off (for the oRMA). . . . . . . . . . . . . 30 6.8 Combined RA/LA Hand-off (for other global HAs). . . . . . . . . 32 7. Summary of Inter-FA Forwarding during Hand-off. . . . . . . . . . . 32 7.1 Transient forwarding for standard FA CoA switching. . . . . . . 33 7.2 Transient forwarding for Concat CoA switching . . . . . . . . . 33 8. Summary of Inter-Region Transient Forwarding. . . . . . . . . . . . 34 8.1 Transient forwarding from Nested oRMA to Nested nFA . . . . . . 34 8.2 Transient forwarding from Concat oRMA to Nested nFA . . . . . . 34 8.3 Transient forwarding from GFA oRMA to Nested nFA. . . . . . . . 35 9. Summary of Inter-RMA Transient Forwarding during Hand-off . . . . . 35 9.1 Nested to Nested using Nested inter-RMA transient forwarding. . 36 9.2 Nested to Concat using a Concat inter-RMA transient forwarding. 37 9.3 Concat to Concat using Concat inter-RMA transient forwarding. . 38 9.4 Concat to Nested using Nested inter-RMA transient forwarding. . 39 9.5 Nested to Nested using Concat inter-RMA transient forwarding. . 40 9.6 Nested to Concat using Nested inter-RMA transient forwarding. . 41 9.7 Concat to Nested using Concat inter-RMA transient forwarding. . 41 9.8 Concat to Concat using a Nested inter-RMA transient forwarding. 42 9.9 Nested <-> Concat Option Comparisons. . . . . . . . . . . . . . 42 9.10. Inter-RMA Transient Forwarding with GFA mode. . . . . . . . . 43 A.W. O'Neill Expires Oct 2002 [Page 2] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 10. Additional Modifications, Options and Extension Definitions. . . . 43 10.1 Hybrid Concat/GFA Modes. . . . . . . . . . . . . . . . . . . . 43 10.2 GFA and private HoAs . . . . . . . . . . . . . . . . . . . . . 43 10.3 Heterogeneous RA forwarding modes. . . . . . . . . . . . . . . 44 10.4 HA/HoA Specific Processing and Context Transfer. . . . . . . . 44 10.5 Previous Foreign Notification Extension (PFANE). . . . . . . . 46 10.6 Previous RMA Notification Extension (PRANE). . . . . . . . . . 46 10.7 Style Extension (Stylext). . . . . . . . . . . . . . . . . . . 47 10.8 HFAIPext . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 10.9 HFAext . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 10.10 HoAList . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 10.11 HoAResp . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 10.12 HoAErr. . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 10.13 FA-NAI regional structure . . . . . . . . . . . . . . . . . . 50 10.14 Unicast FAA for MN specific FA CoA assignment . . . . . . . . 50 10.15 When the LA layer is hidden from the RA Layer . . . . . . . . 50 10.16 When both the LA and RA layers are exposed to the FA. . . . . 50 10.17 When the RA/LA layers terminate on different elements . . . . 51 10.18 RoA Address Allocation. . . . . . . . . . . . . . . . . . . . 52 10.19 Proxied HA Update . . . . . . . . . . . . . . . . . . . . . . 54 11. IPv6 Considerations. . . . . . . . . . . . . . . . . . . . . . . . 56 12. Security and AAA Considerations. . . . . . . . . . . . . . . . . . 56 12.1 FA and RMA Auto-configuration. . . . . . . . . . . . . . . . . 57 12.2 AAA Key Material Distribution. . . . . . . . . . . . . . . . . 57 12.3 Inter-operator PRANE . . . . . . . . . . . . . . . . . . . . . 58 12.4 Forwarding Checks. . . . . . . . . . . . . . . . . . . . . . . 58 13. Notice Regarding Intellectual Property Rights. . . . . . . . . . . 58 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 59 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 A.W. O'Neill Expires Oct 2002 [Page 3] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 1. Introduction Nested MIP [NestMIP] and Concatenated MIP [ConcatMIP] provide means to support both localization and aggregation of MIP signalling. They achieve 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. The local access layer provides a regional address from a Regional Mobility Agent (RMA) (initially simply a local HA) that is then used as a CCoA for the remote access layer. Inter-FA movement and MIP signalling at the local access layer then automatically supports the hand-off of potentially multiple parallel remote access sessions. Nested MIP achieves this through encapsulation whilst Concatenated MIP achieves it though various forms of CoA switching. The signalling for Nested and Concatenated MIP is wholly based on existing MIP signalling capabilities re-using standard MIP Registration Requests and Replies, along with the extensions to those messages in support of regional elements. The additional signalling mechanisms are limited to new extensions and processing rules in support of the RMA, and in support of the additional hand-off requirements. This draft describes the localised and aggregated MIP signalling model for managing both the local access (LA) and remote access (RA) layers through a series of evolutionary steps starting from standard MIP. This includes inter- FA and Inter-RMA hand-offs within and between Nesting and Concatenating Regional Mobility Agents. This is necessary to support incremental, heterogeneous deployment that is inevitable given that Nested MIP is deployable now whilst Concatenated MIP requires additional and significant standards and development work. 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 Tunnelling [RegTun], MIP Reverse Tunnelling [RevTun] and MIP Route Optimisation [RoutOpt]. This draft introduces the following additional terminology. Local access service - Internet access using a topologically local address Remote access service - Internet access using a topologically remote address Regional Mobility Agent (RMA) - a regional node capable of at least HA mode Regional Address (RoA) - A HoA from the RMA HA function RMA Region - the set of FAs able to allocate that RMA to a MN LA/RA MIP - Local access MIP functionality between the MN and the RMA/HA HoA visitor list - the standard MIP visitor list for HoA/CoA binding A.W. O'Neill Expires Oct 2002 [Page 4] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 LA visitor list - the MIP visitor list for the RoA / FA CoA binding RA visitor list - the MIP visitor list for the HoA / CCoA=RoA binding SHCoA - Shared CoA for multiple MNs from the FA or RMA. MSCoA - Mobile Node specific CoA from the FA or RMA. LA/RA Hand-off - a hand-off effected using the LA/RA MIP layer LA/RA MIP Reg - An MIP Reg in the LA/RA layer direct to the present RMA/HA. Inter-FA Hand-off - a hand-off between two FAs that updates the FA CoA. Inter-RMA Hand-off - a MIP hand-off between two RMAs that changes MN RoA. HFAIPext - the HFA IP address extension (generalization of GFAIPext) PRANE - Previous Regional Agent Notification Extension HoAlist - HoA/HA list extension HoAResp - the matching HoA/HA response extension HoAErr - extension to communicate HA/HoA specific errors Style Extension (Stylext) - used to select LA/RA options 4. Motivation The motivation for this work is described fully in [NestMIP] and [ConcatMIP] but can be summarized here as extending MIP signalling (Registration and Hand-off) to support efficient local Internet access in conjunction with potentially multiple parallel remote access sessions. In the case of this draft, the MIP signalling is enhanced to enable the instantiation, maintenance and hand-off of local and remote access sessions. 5. MIP Registration Overview There is a single LA session for an unlimited number of dependent RA sessions. The existence of both a local access and remote access MIP layer results in the need to support two layers of Registrations and hand-off in the Nested/Concat MIP model. LA Registrations configure and refresh the LA layer whilst RA Registrations configure and refresh the RA layer. Both layers also support hand-off with the RA layer 'hand-off' updating the CCoA in the global HA to use a new RMA, whilst the LA updates the CoA in the RMA and also handles transient forwarding for the two types of LA hand-off. These are called inter-RMA hand-off and inter-FA hand-off. A region is defined as the set of FAs under a specific RMA such that an inter-FA hand-off is occasionally also an inter-region hand-off. These hand- offs are enabled by the LA MIP Registration Request / Reply, and by the RA MIP Registration Request / Reply, as described in the following sections, in support of three main forwarding modes; Nested [NestMIP], Concatenated [ConcatMIP] and GFA as in [RegTun]. A.W. O'Neill Expires Oct 2002 [Page 5] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 +--------+ | | Global HAs | HA | |HoA->CoA| +--------+ | \ ... ... ... ... ... | +--------+ +--------+ Regional RMAs | oRMA | | nRMA | inter-RMA h/o | oRoA | | nRoA | |CoA->CoA| |CoA->CoA| +--------+ +--------+ <-------region--------> <-------region--------> / \ / \ +--------+ +--------+ +--------+ +--------+ Local FAs | | | | | | | | inter-FA h/o | FA1 | | FA2 | | FA3 | | FA4 | | CoA | | CoA | | CoA | | CoA | +--------+ +--------+ +--------+ +--------+ | | | +--------+ +--------+ ... | | | | | MN | | MN | | | | | +--------+ +--------+ Figure 1 above illustrates the topology. The LA layer signalling specifies the type of requested/supported/assigned LA features which include; - the access service mode (local access only, remote access only, local and remote access), - the RMA RA forwarding mode (standard, nested, Concat, GFA) - the RoA (public or private address) - the FA CoA (shared or MN specific address). These need to be sufficient for all the active or planned RA sessions and commensurate with the operator policy and MN AAA profile. The default LA layer signalling and processing is both local and remote access service, using nested mode RA forwarding in the RMA for a public or private RoA to a shared FA CoA. This can be seen to be equivalent to standard MIP with the RMA acting simply as a local HA for the RoA address, with the addition that the RoA can also be used as an interface address for local access. The MN can then use standard MIP mechanisms to use the RoA as a MN CCoA for RA MIP Registration directly with a global HA. The routing entries for the RoA always point towards the RMA and the RMA uses MIP mechanisms to redirect the packets to the MN using that RoA. The MN uses LA MIP extensions to request changes to this default behaviour and these extensions can be checked and modified by the FA and the RMA. The FA can inform the MN of the facilities available at that FA and within that RMA region, and complementary information can also be communicated through successful and failed Registration Replies. The signalling exchanges to support the LA and RA layers through a series of evolutionary steps are defined next. A.W. O'Neill Expires Oct 2002 [Page 6] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 5.1 LA Signalling Summary There are four versions of LA MIP Registration Request/Reply. 5.1.1 LA Reg v1 (intra-RMA, intra-FA) This is sent via the old FA to an old RMA when refreshing a binding at that old RMA. The CoA, RMA and RoA are therefore already known when sending the LA Reg. This is possible using existing MIP standards. 5.1.2 LA Reg v2 (intra-RMA, inter-FA) This is sent to the old RMA via a new FA as part of an FA hand-off within the region of the old RMA or from a new FA outside of that region that has or can rapidly acquire an SA with the oRMA for authentication purposes. The RMA and RoA are once again already known when the LA Reg is sent by the MN. The need for inter-FA hand-off is detected before sending the LA Reg. The LA Reg can then include an inter-FA hand-off extension such as PFANE to trigger a BU back to the oFA. The BU facilitates transient forwarding from the oFA to the nFA during the RMA changeover. This is possible using existing MIP standards. 5.1.3 LA Reg v3 (inter-RMA, inter-FA) This is sent to the new RMA from the new FA when starting a new LA session or when recovering from a failed RMA. This therefore requires dynamic assignment of an RMA and an RoA from that RMA. If the MN detects the need for an inter- RMA hand-off then it can be sent with an inter-FA hand-off extension such as PFANE to trigger a BU back to the oFA. The BU facilitates transient forwarding from the oFA to the nFA during the RMA changeover. This is possible using existing MIP standards with the dynamic allocation using the equivalent mechanisms to that for dynamic HA/HoA assignment. 5.1.4 LA Reg v4 (inter-RMA, interFA) This is sent to the new RMA from the new FA along with an inter-FA hand-off extension such as PFANE, and a new inter-RMA hand-off extension called a Previous RMA Notification Extension or PRANE. Dynamic assignment of RMA and RoA are again required. The PFANE triggered BU facilitates transient forwarding from the oFA to the nFA during the RMA changeover. In addition, the PRANE is added to also trigger a BU back to the oRMA from the nFA and/or the nRMA depending on state in the new FA and in the PRANE itself. This BU is used to facilitate more efficient transient forwarding, of in-flight packets arriving at the old RMA, directly to the nFA and/or to the nFA via the nRMA. This avoids excessive use of expensive inter-FA transient forwarding especially in the case of singley-homed FAs, connected over expensive access circuits, that is typical in cellular networks. This type of registration is possible with existing MIP standards and simply requires a new extension to trigger the request for oRMA transient forwarding, and associated modifications to MN, FA and RMA (local HA). 5.2 RA Signalling Summary The RA MIP layer manages remote access sessions between a global HA/HoA and the MN. There are three versions of RA MIP Registration signalling. A.W. O'Neill Expires Oct 2002 [Page 7] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 5.2.1 RA Reg v1 This is sent directly between the MN and the global HA for the global HoA. This is unseen by the FA and the RMA and is possible with existing MIP standards if the MN has a CCoA. This draft extends the standard MIP Registration definition to enable the CCoA to be the RoA assigned from the LA MIP layer. 5.2.2 RA Reg v2 This is sent to the global HA via the FA and therefore requires the FA to be able to process both LA and RA MIP Registrations. Whilst the MIP standard Registration message can be sent via the FA, neither the standard MIP MN nor FA has the required intelligence to distinguish between and appropriately deal with LA and RA messages, and the associated packet forwarding. 5.2.3 RA Reg v3 This is sent to the global HA via the FA and the RMA from the LA layer. This therefore requires the FA and the RMA to be able to process both LA and RA MIP Registrations. Whilst the MIP standard Registration message can be sent via the FA, neither the standard MIP MN nor FA has the required intelligence to distinguish between and appropriately deal with LA and RA messages. The RMA in the LA layer is a local HA whilst in the RA layer it is a regional element on the way to a global HA. Again, neither existing HAs nor in fact regional elements such as GFAs have the required intelligence to distinguish between and appropriately deal with LA and RA MIP Registrations. Also, neither the MN, FA, HA nor GFA have the ability to deal with subsequent packet forwarding and the regional signalling extensions to enable registrations through a regional element are not yet completed. 5.3 Combined LA/RA Signalling Summary There are two forms of combined LA/RA signalling that have been designed for efficiency reasons. These are; 5.3.1 Combined LA/RA Reg v1 This is a combination of an LA Reg v3 and an RA Reg v3. It is sent to the oRMA for the oRoA, via the nFA and the nRMA. It carries an inter-FA hand-off extension to trigger a BU to the oFA from the nFA to facilitate inter-FA transient forwarding. In the FA, this registration triggers nRMA and FA CoA assignment, and in that nRMA it triggers nRoA assignment and the type of RA forwarding. In the oRMA, the nRoA is installed as the CoA for the oRoA (oRMA becomes a global HA) which facilitates persistent forwarding of traffic arriving on the oRoA address towards the nRMA. In the nRMA and nFA, forwarding is enabled both for traffic arriving on the oRoA and the nRoA. This enables inter-region hand-off with inter RMA forwarding and persistent use of the oRMA and oRoA by elevating them into the RA layer (global HA/HoA) whilst away from the region of that oRMA. A.W. O'Neill Expires Oct 2002 [Page 8] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 5.3.2 Combined LA/RA Reg v2 This is a combination of an LA Reg v4 and an RA Reg v3. This is therefore sent to the global HA for the HoA via the nRMA and the nFA. Inter-FA and inter-RMA hand-off extensions are included by the MN to trigger BUs to the oFA and the oRMA. These BUs facilitate transient forwarding between oFA and nFA, and between the oRMA and the nFA/nRMA. The RA session for the combined message can be selected by the MN either based on the remaining lifetime, order of importance or to minimise the effect of hand-off (latency/packet redirection etc) for that particular session. This version is used instead of the Combined LA/RA Reg v1 when the oRMA/oRoA are not required to transition into an RA session as a persistent global HA/HoA pair for the MN, and hence only transient forwarding is required. 5.4. LA / RA Visitor Lists LA MIP Registrations create and update the LA visitor list in the FA and the RMA. The LA visitor list contains forwarding entries for packets addressed to the RoA from any source in the Internet, including HAs, but can be constrained by the use of additional firewall entries. Firewall entries can be created to control various remote access techniques, as well as for controlling specific traffic sources, protocol types, port numbers etc... The RA visitor list can be considered to be a specific type of firewall entry maintained by MIP signalling. Logically you can imagine a packet first being matched against state in the RA visitor list (more specific checks that can cause a packet to be discarded, re-marked, accounted differently or to undergo alternative forwarding) and then being checked against the LA visitor list before undergoing default local access forwarding. Of course there are many options for the implementation of these two lists from two distinct layers through to a single integrated list. RA MIP Registrations create and update the RA visitor lists in the MIP nodes through which it is forwarded and processed. The RA visitor list specifically ensures that data packets addressed to the MN are only received from the correct previous MIP node as learnt during the RA Registration process. This is a generalisation of the forwarding rules in [RegTun] to deal with Nesting, Concat modes as well as CoA Switching. The RMA, the FA and the MN need to keep MN specific state in the visitor list to undertake this check if the RA Registration signalling traverses that node, and that node changes the packet source address for the downstream node. The RMA must check that the data packet came from the registered HA. The FA must check that the data packet came from the registered HA or RMA. The MN must check that the data packet came from the registered HA,RMA,FA. The MN specific state used for this source check in the FA should not include the HoA. Avoiding HoA specific state in the FA means that it does not need to be maintained through inter-FA hand-off using Context Transfer (because we want to avoid independent MIP hand-off signalling for each HoA). The problem with HoA specific state and aggregated signalling is covered in more detail in [ParallelMIP]. The appropriate level of RA checks in each element is a trade-off between the processing required to undertake those checks, against being able to efficiently eliminate incorrect packets as early as possible. A.W. O'Neill Expires Oct 2002 [Page 9] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 The level of checking is operator dependent. HoA specific processing features such as accounting and QoS are particularly an issue for the operator but in these cases are under the control of the AAA profile. Each foreign agent MUST be configured with a shared care-of address. In addition, for each pending or current LA registration the foreign agent MUST maintain an LA visitor list entry containing the following information obtained from the mobile node's LA Registration Request: - the link-layer source address of the mobile node - LA layer MN-NAI to identify the MN profile - the IP Source Address (the mobile node's Home Address = RoA). - the IP Destination Address (as specified in [MIPv4] 3.6.1.1) - the UDP Source Port - the Home Agent address = RMA - the Identification field - the requested registration Lifetime, and - the remaining Lifetime of the pending or current registration. In addition, for each pending or current RA registration the foreign agent MUST maintain an RA visitor list entry containing the following information obtained from the mobile node's RA Registration Request: - the link-layer source address of the mobile node - RA layer MN-NAI to identify any additional RA layer session profile - the IP Source Address (the mobile node's CCoA = RoA). - the IP Destination Address (as specified in [MIPv4] 3.6.1.1) - the UDP Source Port - the Home Agent address = global HA - the forwarding mode (standard, Nested, Concat or GFA) - the FA CoA (MSCoA for Concat mode) - the Identification field - the requested registration Lifetime, and - the remaining Lifetime of the pending or current registration. Both lists are then supplemented with additional information that is particular to the chosen RA layer forwarding mode. The LA forwarding mode is always to encapsulate towards the nFA CoA. The LA and RA visitor lists can be implemented for example as a single list of visitor entries containing both LA and RA state entries. The forwarding search should check the more restrictive RA entries (specific HAs) before checking the LA layer entries (any CN). The RMA needs to keep the same visitor list as an existing HA for its role in the LA layer related to the RoA address. In addition, it must be able to store RA visitor state if the registration is routed via the RMA. The FA knows either from configuration, from MIP Replies or from the RMA state returned from the AAA system whether or not the RMA supports RA registration. The HA visitor list is unchanged by this draft. A.W. O'Neill Expires Oct 2002 [Page 10] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 5.5. Summary of LA and RA Forwarding Modes 5.5.1 The LA Layer Forwarding The LA layer supports the forwarding of local access traffic. There is one type of forwarding at the LA layer and this is to 'Nest' the oRoA within a tunnel between the RMA (the local HA) and the FA as in normal MIP forwarding. This Nested forwarding is unaffected by the RMA RA layer features which can support Nested, GFA and Concatenated forwarding of packets from a global HA. Local traffic sent by a Correspondent Node (CN) to the RoA arrives at the RMA that owns that RoA, and is then encapsulated into the FA CoA registered for that RoA. It is then forwarded to the FA owning that CoA and through which the MN typically sent the LA layer MIP Reg. The FA decapsulates, inspects the RoA to identify the MN, and then forwards to that MN. The FA CoA is either a SHCoA or a MSCoA depending on the RA forwarding mode negotiated at the LA layer, for all RA sessions. Note that the FA must inspect the RoA within an MSCoA to ensure it agrees with the MN LA state and to prevent packet mis- delivery. CN HA oRMA nRMA oFA MN Forward LA CN----------------------------------------------------->oRoA oRMA=============>oFACoA Reverse LA CN<-----------------------------------------------------oRoA RevTun LA CN<-----------------------------------------------------oRoA (Direct) oRMA<=============oFACoA (Encaps) oRMA<=============oFACoA x <=====oRoA Figure 2. LA layer forwarding. Note that the RoA is just a HoA from the RMA and therefore reverse tunnelling features [RevTun] are unaffected, including the ability in 'Encapsulating style' to revtun some packets via the RMA and reverse some directly to the CN. Note also that the FA needs to undertake a source address check on the RoA to ensure that RoA is registered in that FA for that MN. A range of forwarding models for the RA layer are then possible depending on the evolution stage, the deployed RMA/FA operator capabilities, the MN AAA profile and the MN LA Registration contents. The LA layer is however responsible for preparing the RA layer forwarding mode, which should generally be the same for all RA access sessions through that RMA for that MN. This requires the discovery, negotiation and agreement at the LA layer of the required forwarding mode. This is necessary so that each LA hand-off can immediately acquire the correct type of FA CoA and then configure the RA mode via the nRMA before the RA sessions are refreshed. Before examining the RA forwarding options, a special mention needs to be made of Route Optimisation here [RouteOpt]. Initially, a MN will register through to a HA and packets will come through that HA to the MN, experiencing the RA layer forwarding to be discussed next. However, after subsequent signalling between MN and CN, the two nodes can tunnel directly to each other and bypass the HA. At this point these packets are from the CN to the RoA and from the RoA to the MN which are therefore forwarded as local access traffic. A.W. O'Neill Expires Oct 2002 [Page 11] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 If the RA visitor list inspects inner packet headers to identify them as remote access traffic, those packets can still be exposed to RA layer processing (that may even be HoA specific). The state required to undertake this check can be built from the route optimisation messages that are exchanged via the HA, although this creates CN specific state which is only practical to maintain in the RMA. One benefit though that the architecture brings to route optimisation is the fact that the RoA changes much less frequently and so binding update traffic is significantly reduced, with the reduction improving as the size of regions is increased at the cost of less optimal forwarding via the RMA. There are four types of forwarding possible at the RA layer between the global HA and the MN, three of which are defined in this draft. These are covered in the next sections. 5.5.2 Standard MIP remote access This is a direct tunnel from the global HA to the MN CCoA from the oFA subnet, with any optional reverse tunnel being between the MN CCoA and the HA. This tunnel is used whether or not the MN registers via the FA at the RA layer. CN HA oRMA nRMA oFA MN Forward RA CN------------------------------------------------------>HoA HA==========================================>oCCoA Reverse RA CN<------------------------------------------------------HoA RevTun RA HA<==========================================oCCoA Figure 3. Standard MIP RA. Note that the CCoA here is from the FA subnet and hence must be updated on every FA hand-off. 5.5.3 Nested MIP remote access RA Nested Forwarding is as for LA Nested forwarding in that the RMA encapsulates packets addressed to the RoA, in the FA SHCoA that was LA registered by the MN via the present FA. The FA then decapsulates and forwards to the MN that has been assigned that RoA. Nested MIP RA can be configured using any of RA Reg v1, v2 or v3 as described above because neither the RMA nor the FA need to receive any additional RA information to successfully forward the traffic towards the MN CCoA. This is because the HA is sending to the RoA, and the RMA and FA can forward this at the LA layer. A.W. O'Neill Expires Oct 2002 [Page 12] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 CN HA oRMA nRMA oFA MN Forward RA CN------------------------------------------------------->HoA HA===========================================>oRoA oRMA================>oSHCoA Reverse RA CN--------------------------------------------------------HoA (PCCoA only using RevTun LA) oRMA<================oRoA RevTun CN--------------------------------------------------------HoA RevTun RA HA<===========================================oRoA RevTun RA/LA oRMA<================oSHCoA Figure 4. Nested MIP RA There is a forward tunnel from the HA to the MN CCoA within a tunnel between the RMA and the FA. The RMA to FA tunnel is managed by the LA layer whilst the HA to MN CCoA is managed by the RA layer. Reverse tunnelled remote access traffic does not need to traverse the oRMA but is sent from the MN CCoA=RoA to the HA. LA reverse tunnelling can be used to ensure that the RMA is also traversed if that is necessary for policy/feature reasons. Forward and reverse traffic that is not tunnelled at the RA layer over the air interface is not generally supported with CCoAs in this model. However, proxy CCoAs [PCCoA] potentially offer a way to achieve this, and save encapsulation overhead or header compression load if the FA is visited by the registration signalling and end to end IPSEC is not employed. A PCCoA is a CCoA whose tunnel management is handled at the other end of the link in the FA. In the forward direction this causes the FA to also decapsulate from the RoA and forward to the MN with a HoA destination address. In the reverse direction, the packet now has a HoA source address and so some form of ingress filtering must be performed. This can be undertaken by the FA if it has HoA state supported using Context Transfer. Preferably though, the FA can simply process based on the incoming link-layer address (to identify the MN and hence the RoA entry) and then reverse tunnel the packet at the LA layer from the oRoA to the RMA where HoA state can practically undertake the source address check for that MN. PCCoA processing is clearly complex however and the cost benefits of this mode need to be determined. The major difference compared to standard MIP remote access mode is that the MN CCoA is the Regional Address (RoA) which comes from the RMA, rather than a CCoA from the FA subnet as in standard MIP specs. In the latter case, the FA hand-offs result in CCoA changes and a need to update the global HA, wheras with Nested MIP the RoA is valid across a number of FAs beneath a single RMA. The RA visitor list in the MN ensures that the correct HA sent the correct HoA in the correct RoA, and that the packet was received from the registered FA. If the RA Registration traverses the FA then an RA visitor list in the FA can ensure, after decapsulating from the FA CoA, that the packet came via the registered RMA for that RoA by checking the source address on the encapsulation towards the FA CoA. If the RA Registration traverses the RMA then the RA visitor list in the RMA checks that the source HA has been registered for that RoA. A.W. O'Neill Expires Oct 2002 [Page 13] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 Note that the FA and RMA may also undertake HoA specific processing which also requires the inner HoA to be interrogated. An optional RA visitor list in the RMA, based on the received RoA, may check that the HA address is correct for the encapsulated HoA and that the HoA is registered for that RoA and MN. The FA can check that the MN that owns that RoA also owns the HoA or it can simply rely on the fact that this check may be performed by the RMA and must be by the MN. 5.5.4 GFA CoA switching This is CoA switching from [RegTun] which uses a HoA specific RA visitor list in the RMA (acting like a GFA) and FA to route packets arriving on shared RMA and FA CoAs (SHCoAs). This mode is supported in this document for backwards compatibility and transition reasons if GFAs and GFA aware MNs have been deployed. CN HA oRMA nRMA oFA MN Forward RA CN------------------------------------------------------>HoA HA====>oRMA x oRMA===============>oSHCoA RevTun RA CN-------------------------------------------------------HoA HA<====oRMA x oRMA<===============oSHCoA Figure 5. GFA MIP RA The forward tunnel is from the HA to the RMA CoA, and then from the RMA to the FA CoA. The reverse tunnel is the exact reverse of the forward tunnel. Reverse traffic that is not tunnelled at the RA, and therefore has the HoA as the source address, can clearly be supported in this model because the FA has HoA specific state. In this case, the RoA is not needed by the RA layer and is used simply for the LA layer that is not shown. This mode of forwarding can only be supported with an RA MIP v3 Reg because specific state needs to be installed into the RMA and the FA for the switching. The GFA forwarding should only generally be supported for MNs that are limited to a single remote access session (a single HoA) and that are using a globally unique HoA, these being known limitations of GFA forwarding. The HoA specific RA visitor list state must be maintained at each new FA and RMA, for multiple RA sessions, using the HoA independent LA layer signalling. This can be accomplished, for a single RA session, by the LA MIP Reg including the HoA information, in a HFAext, to support inter-FA and inter-RMA hand-off. For multiple RA sessions (HoAs), the HFAext can be replaced with the HoAList extension and Context transfer mechanisms are then required between FAs and RMAs, triggered by the aggregated LA hand-off, which is discussed in more detail in section 10. The RA visitor list in the MN ensures that a correct HoA was used and that the packet was received from the registered FA. The RA visitor list in the RMA must check that the HA address is valid for the received HoA. After decapsulating from the FA CoA, the FA checks that the packet came via the registered RMA for that MN by checking the source address on the encapsulation towards the FA CoA. The FA and/or RMA must undertake HoA specific processing as part of the GFA model, which can be useful for other previously mentioned reasons, based on AAA profile or operator policy. A.W. O'Neill Expires Oct 2002 [Page 14] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 Note that if local access is also requested, then the RMA needs to be able to distinguish between encapsulated packets sent from a specific HA as part of RA GFA forwarding, and unencapsulated/encapsulated packets sent from CNs as part of the local access service. This is to avoid the RMA attempting to incorrectly strip the RoA. Therefore, to support LA as well as RA access, the GFA needs to inspect the incoming source address to match it against a known HA before undertaking CoA switching. Alternatively, because local access traffic arrives on the RoA whilst remote access traffic arrives to a SHCoA, then the SHCoA can trigger the forwarding to the GFA module where the HA source address can be checked. This is a change from the [RegTun] GFA mechanism which enables local access traffic to bypass the GFA module in the RMA (and equivalently in the FA for packets arriving to the RoA and the FA SHCoA). 5.5.5 Concatenated CoA Switching This is a new form of somewhat complex CoA switching to overcome the perceived limitations in the GFA model. This mode of forwarding can only be supported with an RA MIP v3 Reg or Combined Reg because specific state needs to be installed into the RMA and the FA for the switching. The concatenated processing, unlike GFA processing, can be supported for public and private HoA addresses and for multiple concurrent RA sessions. The concatenated request can be refused as a result of AAA state in the FA, which can then convert the request to either GFA or Nested MIP. CN HA oRMA nRMA oFA MN Forward RA CN------------------------------------------------------->HoA HA====>oRoA x oRMA===============>oMSCoA=====>oRoA ReverseRA CN---------------------------------------------------------HoA (PCCoA only) oRMA<===============oMSCoA CN---------------------------------------------------------HoA RevTun RA only HA<===========================================oRoA RevTun LA/RA HA<====oRoA x oRMA<===============oMSCoA<=====oRoA Figure 6. Concatenated MIP RA The forward tunnel is between the HA and the RMA which switches traffic into a second tunnel between the RMA and the FA. The RA layer reverse tunnel is similar to that for Nested though in that it can bypass the oRMA. Note that the RA traffic in Concat, as in Nested, requires a tunnel over the air interface, whilst it is not required for GFA. If either or both LA and RA reverse tunnelling is selected then the processing rules ensure that the source address is correct for the information in the destinations binding for the forward direction. Forward and reverse traffic that is not tunnelled at the RA layer over the air interface is not generally supported with CCoAs in this model. However, proxy CCoAs [PCCoA] potentially offer a way to achieve this, and save encapsulation overhead or header compression load if the FA is visited by the registration signalling and end to end IPSEC is not employed. The reverse forwarding is then as for Nested by reverse tunnelling to the RMA, but this time from the oMSCoA to match on the forward entry in the RMA. A.W. O'Neill Expires Oct 2002 [Page 15] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 The other modifications wrt [RegTun] are that the RMA CoA and FA CoA are MN specific (MSCoAs) so that neither the RMA nor the FA need to keep HoA specific state for forward or reverse RA tunnels. This enables a single LA MIP Reg to move all the RA sessions together and also ensures that Context Transfer of HoA specific state, for basic RA forwarding, can be avoided during FA hand-off. Note that Context Transfer might still be required to optionally support HoA specific processing in the FA and/or RMA, and is discussed in detail in section 10. If HoA specific state is added in the RMA and FA for such reasons then the MN specific CoA and RoA can also be used to assure that the concatenation of the MSCoA+HoA or RoA+HoA is always locally unique. An example of this HoA specific processing is the source address check in the RMA for reverse packets that are not tunnelled at the RA layer. The RA visitor list in the MN ensures that a correct HoA was used and that the packet was received from the registered FA. A mandatory RA visitor list in the RMA must check that the HA address is valid for the received RoA. An RA visitor list in the FA must keep MSCoA and RoA state to be able to correctly identify and forward to the receiving MN by switching from the MSCoA into the RoA destination address whilst generally ignoring the inner destination address (ie the HoA). Of course, if the inner destination address is the RoA (local access traffic) then the RoA re-encapsulation is not required. This complicates the FA visitor compared to the Nested Model where the RoA is always visible. After decapsulating from the FA CoA, the FA checks that the packet came via the registered RMA for that MN by checking the source address on the encapsulation towards the FA. The FA and/or RMA may also undertake HoA specific processing for other previously mentioned reasons, based on AAA profile or operator policy. The HoA is made locally- unique in the FA through the concatenation with the MSCoA, and in the RMA through concatenation with the RoA. Note that if local access is also requested, then the RMA needs to be able to distinguish between encapsulated packets sent from a specific HA as part of RA RMA forwarding, and unencapsulated/encapsulated packets sent from CNs as part of the local access service. This is to avoid the RMA attempting to incorrectly strip the RoA. In both cases, the packets are addressed to the RoA. Therefore, to support LA as well as RA access, the RMA Concat module must inspect the incoming source address to match it against a known HA before undertaking concatenated switching. Similarly, the FA needs to have an additional entry for the LA visitor list for the RoA, which is created as part of the LA MIP Layer signalling. The Concat module must therefore analyse all packets whilst the GFA module only inspects packets from registered HAs. However, when the GFA module needs to inspect and switch a packet, this processing is more intensive (source, dest, HoA check) than necessary for the Concat module which simply uses the incoming interface (source/dest check). This enables the Concat module to easily switch packets, encapsulated from a registered HA to a specific RoA (RA layer), whilst encapsulating packets from arbitrary CNs (whether encapsulated or not) to the same RoA (LA layer) in a single module. 5.5.6 RMA Availability A detailed comparison between the four modes, and specifically between the two new modes and the existing standard and GFA modes, is distributed throughout this document. A specific and very important issue covered here is the RMA availability and its impact on the system. A.W. O'Neill Expires Oct 2002 [Page 16] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 GFA mode here and in [RegTun] requires a highly stateful core node that is tied into both the MN and the HA through installed registration state. Such a core box, which can have a large number of installed flows needs to be high availability such that its failure is very rare, but even then still catastrophic. This is because recovery requires each MN to re-install bindings into the remote HAs as well as into the regional element. Hot standby can be used between regional nodes to quickly recover the MN to GFA state but this does not help with the remote access layer binding in the global HA and incures obvious complexity and cost. A major benefit of the design of Nested and Concat modes is that the CoA in the HA is the RoA. This means that multiple RMAs can advertise routes to prefixes covering the RoAs so that if one RMA is lost then traffic to the RoA from global HAs will automatically be redirected to the next best RMA according to routing, so enabling prefixes to be distributed across the remaining RMAs. Note also that the RMA protection mechanisms are almost exactly the same as the mechanisms used today for HAs, and given the RMAs role as a local HA it is clear that these protection mechanisms would already be required. In addition, the it is also clear that the RMA can also play the role of a global HA, allocating out regional and global home addresses from its subnet. Once again, the protection mechanisms envisaged for the RMA are constent with that which is required for its role as a HA. Replication between these boxes of the LA and RA state in the RMA can then enable the LA and RA to recover quickly without MN activity. The replication state for nested mode is significantly smaller than that required for Concat mode but Concat mode forwarding is less bandwidth expensive. Alternatively, each FA could use the routing entry failure for an RMA as indication that it should trigger any mobiles that use that failed RMA to re-register to an alternate RMA. This can be done simply by immediately sending the address of the standby RMA address in an FAA to make the MNs not using that standby RMA but were using the failed RMA (1+1 protection) to undertake an RMA hand-off. This will cause them to issue a new LA Reg to the standby RMA but because the region hasn't changed in the FAA will avoid them achieving that by issuing a Combined RA/LA Reg to the oRMA. They will instead simply issue an LA Reg v3 or v4. This is much less costly than replication but requires MN activity. It is also slower than replicating LA and RA state due to the time to detect the route failures to the RMA. 5.6. Distinguishing LA and RA MIP Messages LA MIP messages and RA MIP messages need to be distinguished from each other in the elements through which they are both forwarded. It may therefore be appropriate to use new MIP messages type fields, flags or extensions for these messages so that the required processing can be cleanly identified. The correct balance between backwards compatibility and forward feature enhancement needs to be determined. However, the following rules show how, without these changes, that an MIP node can distinguish between LA, RA and Combined LA/RA messaging when using standard MIP Registration messages and the regional extensions from [RegTunMods]. LA messages are sent from a zero source address to the FA, and then onto a dynamically allocated RMA. The RMA address may be advertised by the FA and inserted either by the MN into the HA field or by the FA into the HFAIPext. A.W. O'Neill Expires Oct 2002 [Page 17] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 LA messages are subsequently sent from the RoA address to the RMA address via each new FA. The CoA in the message is the FA CoA, which is either entered by the MN or the FA, and can be either shared or MN specific. If the FA adds the CoA then it is inserted into a HFAext and forwarded to the RMA. At each new RMA, the LA must revert to sending the first LA message with a zero source address until the new RoA is known. RA MIP messages are always sent by the MN from the RoA address to the HA with a CoA=RMA CoA which can be either a MN specific CoA (MSCoA=RoA) or an RMA shared CoA (SHCoA). The message is potentially routed via the FA and/or the RMA. The FA can therefore distinguish between LA and RA messages because an LA message will either be sent from a zero source address, or sent from the RoA address with a HA field set to a local RMA. In contrast, RA messages are never sent to the FA with a zero source address and when they are sent from the RoA address they never have a HA field=local RMA because that by definition is an LA MIP message. The RMA can distinguish between LA MIP messages and RA MIP messages by checking the HA (which might be zero) or the HFAIPext of the message. An LA message will have one of these set to the address of the RMA. Otherwise it is an RA message and the HA or HFAIPext will be set to a global HA. A HA is only visited by RA messages and the HA (which might be zero) or HFAIPext will then match the address of the HA. Combined LA/RA messages are only sent during inter-RMA hand-off via a new RMA. They are always sent with a zero source address with the HA field set to either the global HA or the oRMA. The FA can distinguish this from an LA Reg because the HA field is neither zero nor a local RMA at that FA. The FA can distinguish this from an RA Reg because of the zero source address. The nRMA can distinguish this from the LA Reg because the HA field is set and not equal to the nRMA address. The nRMA can distinguish this from a normal RA because the HFAIPext from the FA is included and contains the nRMA address The oRMA/HA can distinguish this from a normal RA or LA message because the HFAIPext and HFAext is included. It is for further study if these rules are sufficient for all scenarios or ideal from an inplementation perspective. Specifically, the RA layer is the standard MIP remote access layer and this should clearly not change MIP message types. A new type for LA layer MIP messages will make RA v LA message detection in the FA and RMA much more efficient with no backwards compatibility consequences because the LA does not presently exist. The RA layer can undertake MIP hand-offs and utilise regional signalling as presently proposed in MIP but only the LA layer will support aggregated regional hand-off, and the RMA discovery and state construction in support of this. A major area of development and standards work is to ensure through LA and RA stack communications and AS, AA message processing that the activities of the two layers are clean and coordinated. This is discussed in section 10. A.W. O'Neill Expires Oct 2002 [Page 18] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 5.7 Summary of MIP Signalling Additions The FAA, LA and RA messages can behave initially very much like existing standard MIP messages in Nested Mode but become more complex as features are added and specifically regional extensions (RA RREQ v3 etc) are supported. 5.7.1 Feature selection The LA layer elements all need to agree between options such as; Service mode Is LA service required ? RMA RA forwarding mode Standard, Nested, Concat, GFA for all RA sessions RoA address type Public or private address NAT Option Permitted or barred (for private RoA) FA CoA type MSCoA or SHCoA The LA layer needs to indicate if the MN is seeking local access service and if so whether a private or public RoA is requested. If the RoA is private then the MN can request to also access NAT features to be able to gain public Internet access. This has implications on the reverse tunnelling requirements which are discussed in section 10. The default RA forwarding mode needs to be agreed in advance at the LA layer for all RA sessions above that LA layer so that the correct type of FA CoA can be assigned. This default can be overruled though for a specific RA session at the RA layer potentially causing a change in the type of CoA for all RA sessions (MSCoA instead of SHCoA for example). The RA layer elements need to select and agree between options such as; Service Mode Is RA service required ? RMA RA forwarding mode Standard, Nested, Concat, GFA for one RA session HoA address type Public or private HoA NAT Traversal Option Permitted or Barred (for RA MIP RREQ/RREP) RMA CoA type MSCoA or SHCoA This time it is the RA service layer that is being configured and includes the type of HoA address and RMA CoA, for the specific RA session. If re-using the LA default values then these are merely repeated here. The NAT traversal option is to enable permission for the RA layer registration to traverse a NAT if the RoA is private. This enables the MN to request and the operator to restrict the scope of registration which might be intra or inter-domain. The style extension is used to communicate these various settings and is optionally carried in all Registration messages, as discussed in section 10. If it is absent then the default settings according to either operator policy as modified by the MN profile are applied. The LA layer can include both LA and RA layer stylexts so that the AAA requirements back to the AAAH can be determined in one RTT. In addition, both LA and RA layer stylext can be included in the RA layer for a Combined RA/LA MIP Reg. If the stylext was understood and correctly processed by the FA and RMA then the returned stylext will indicate the RMA/FA capabilities and installed features. The specific type of support at the RMA, is known to the FA, as it shares a close topological and configuration relationship with its RMA(s). The FA can therefore tailor the stylext settings to match the known/learned RMA capabilities before forwarding the LA MIP Reg to the RMA. A.W. O'Neill Expires Oct 2002 [Page 19] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 5.7.2 FAA Modifications The FAA needs to include the FA-NAI and the shared FA CoA for movement detection purposes. The FA-NAI must be structured to indicate the FA, the region of that FA and the domain of that FA. This is used for inter-region movement detection in the absence of the 'I' bit being set in the FAA. An FA- NAI with region information informs a MN that it is capable of at least Nested Mode. The FAA needs to additionally indicate through the 'R' bit if the MN should RA register through the FA for remote access sessions. The MN can then decide whether to send an RA Reg v1 or RA Reg v2. The FAA must indicate if regional signalling is supported via the 'I' bit. The 'I' bit is advertised in FAAs if the FA knows in advance that it has at least one RMA that supports regional registration. The 'I' bit also indicates that the FAA contains RMA address information for tracking regional movement. The 'I' bit is therefore rescoped from [RegTun] and used to indicate to the MN, in combination with an FA-NAI with region structure, that RA Reg v3, combined LA/RA Signalling, and GFA/Concatenated Mode are likely supported in the FA/RMA pair, as well as HFAext and HFAIPext extensions and associated authentication. A number of other FAA changes are then required depending on how the LA and RA layers are implementated. These are discussed in section 10. 5.7.3 Regional Signalling To support the full range of service and forwarding modes, the following changes to MIP signalling are required which are outlined in [RegTunMods]. The LA message needs to be able to be sent with a zero CoA so that the FA can dynamically allocate a MN specific CoA and insert it into the HFAext when Concat mode is added. This can be avoided if the FA is alternatively able to advertise a MN specific CoA to the MN in a unicast FAA when Concat mode is mandated. The FA must always return the HFAext to the MN in the RREP. The LA message needs to be sent with a zero HA address so that the FA can dynamically allocate the RMA, from a set of RMAs, rather than the MN always using the default RMA that is advertised in the FAA. The FA inserts the allocated RMA address into the HFAIPext and returns it to the MN in the RREP. The RA message needs to occasionally be sent with a zero CoA when using Reg v3 and Combined RA/LA signalling. This is specifically necessary in the case of Reg v3 for GFA mode. The RMA uses the HFAext to inform both the HA (RREQ) and the MN (RREP) of the RMA CoA. The GFA CoA can alternatively be generated in advance of the RA Reg, as a result of the LA layer Registration, with the RMA returning the GFA CoA to the MN in an HFAext. This is the GFA SHCoA that is required for GFA mode only. This is because the GFA CoA for Nested and Concat is the RoA which is already returned in the LA Reply. The GFA CoA should be suitable for the default RA forwarding mode identified in the LA Reg. The RA Reg can then generally avoid using a CoA=0 except when the GFA CoA is HA specific due to disparate addressing plans. For combined signalling, the GFA CoA is always zero through a new RMA because the GFA CoA is not known yet for any RA mode. A.W. O'Neill Expires Oct 2002 [Page 20] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 The HA needs to be able to receive and process HFAext and HFAIPext for combined LA/RA signalling. The PFANE and BU semantics for inter-FA hand-off need to be generalised to support other transient forwarding modes by being able to carry both MN specific and shared FA CoAs. The LA and RA layer needs to be able to carry the PRANE extension for inter- RMA and oRMA-nFA transient forwarding. The LA and RA layers need to be able to carry the Style extension (stylext). Specifically, the LA layer must be able to carry both LA and RA stylext so that a single AAA exchange from the FA can fetch the required state for both layers. In addition, the RA layer also needs to carry both LA and RA stylext so that combined signalling is possible at each new RMA. The LA layer needs to carry a MN-NAI and a MN-AAA auth ext so that the MN can obtain AAA state via the FA, from the home wireless operator via the local wireless operator. The RA layer also needs to be able to carry an NAI and AAA auth to be able to fetch RA session specific state from a third party service provider that is specifically not the home wireless operator. The discussion underpinning these requirements are detailed in [NestMIP]. Other changes are detailed in the text in this draft. 5.8 Backwards Compatibility Issues 5.8.1 General A legacy FA cannot support this draft without being able to advertise the FA- NAI and undertaking configuration changes to restructure the FA-NAI scheme. A compliant MN can detect the difference between a legacy and non-legacy FA by the FA-NAI structure whilst a legacy MN will either ignore the FA-NAI or process it and correctly miss the additional regional information in the NAI. A compliant FA must at least advertise a FA-NAI with the region information, and must undertake ingress filtering on the dynamically assigned RoA. With the 'R' bit set, the FA must be able to also support both LA and RA visitor lists as documented above. This simply means that a single MN must be able to have two active Registrations with two HAs (the RMA and the global HA). The FA must then update both LA and RA visitor lists when an LA hand-off occurs. A legacy MN will not interpret the FAA regional information and therefore will be unaware of the existence of regions or the ability to undertake two coordinated LA and RA MIP layers. This MN can undertake standard MIP and request either LA (local HA) or RA access (global HA) at the RA layer, which the AAA system may accept. It is likely that the RA layer request might be refused if the HA is not owned by specific operators, whose HA availability and performance is trusted, and will most likely be refused if another MIP session already exists due to issues identified in [ParallelMIP]. The RMA is a new element and in the basic Nested model with RA RREQ v1/v2 can be a standard HA that supports dynamic HA and HoA assignment with associated AAA and security mechanisms. A.W. O'Neill Expires Oct 2002 [Page 21] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 When the 'I' bit in the FAA is not set, a legacy global HA sees only a request to forward to a CCoA with the 'D' bit set, and therefore is fully supported because the HA/HoA/CoA fields will have been populated by the AAA system and by the LA layer. For the FA, RMA and the global HA, the following specific issues also occur when the 'I' bit is advertised to the MN in the FAA. 5.8.2 LA RREQ Zero CoA field (dynamic FA CoA assignment) The MN should only send a zero CoA in the MIP Reg if the 'I' bit is set which indicates that the RMA supports this feature. Dynamic FA CoA assignment requires the FA to send the CoA to the RMA in the HFAext. If the RMA does not support this (a configuration error condition given the FA-RMA relationship) then the RREQ will be refused and the HFAext will not be returned to the FA as confirmation. This will be detected by the FA, which then inserts the HFAext into the RREP so that the MN can set the FACoA in a second attempt. 5.8.3 RA RREQ zero CoA field (Dynamic RMA CoA Assignment) The MN should only send this if it believes that the HA supports this extension. The RMA assigns the CoA and forwards it to the global HA in the HFAext. If the HA does not support this extension then the HA will fail to return the HFAext which will be detected by the RMA. The RMA then inserts the HFAext so that the MN can set the CoA field itself in a second attempt. 5.8.4 LA RREQ zero HA field (dynamic RMA assignment) The MN can allow the FA to assign the RMA, potentially via the AAA system. If this is achieved by routing the request through the AAA system, then the RREP will include the RMA and RoA. If the 'I' bit is set then this can alternatively be achieved using the HFAIPext. The FA should then return the HFAIPext including the dynamically assigned RMA to the MN in the RREP if the RREQ was successful at the RMA. Any local HA (RMA) that supports dynamic assignment can therefore support LA signalling in some form. 5.9 Signalling and Forwarding Evolution From an evolutionary perspective, it can be seen that Nested MIP can be supported with very little changes to MIP standards, with these changes limited to the co-existance and cooperation between two MIP signalling layers in the MN, with the FA undertaking ingress filtering checks on the dynamically assigned RoA (local HoA), and the FA-NAI being structured to identify the FA as well as the region so that the MN can execute inter-region hand-offs as well as inter-FA hand-offs. These two MIP layers can next be exposed to the FA by enabling RA registration via that FA (setting the 'R' bit) and by adding the RA visitor list to the LA visitor list. The RA layer MIP stack needs to see FAAs to be able to detect the 'R' bit setting and such issues are discussed in more detail in section 10. In either case, inter- region hand-off is supported by using inter-FA transient forwarding and potentially by oRMA to nFA transient forwarding. Finally, the LA signalling can be enhanced to support inter-region forwarding from the oRMA to the nFA, and from the oRMA to the mRMA, using the Previous RMA Notification Extension (PRANE), and/or existing inter-regional SAs between the oRMA and nFA/nRMA. A.W. O'Neill Expires Oct 2002 [Page 22] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 Major modifications are however required to MNs, FAs and HAs to enable RA Registration v3 signalling and efficient combined LA/RA signalling, to enable the FA to advertise the default RMA address in an FAA, and to enable the FA to undertake dynamic RMA and FA CoA assignment. Almost all of these changes are however equivalent to those proposed for Regional Registration {RegTun] and a common signalling plan should be devised. Once RA Reg v3 is possible then the HA FA and MN can be extended to support all four types of forwarding (standard HA, Nested, GFA and Concat) using the Style Extension to indicate the requested mode. Modifications are then possible in MNs, FAs and HAs to support the new inter-RMA hand-off extensions to enable hand-off between the different forwarding models to facilitate incremental and heterogeneous deployment. Essentially therefore, this draft documents an evolution of backwards compatible capabilities as MIP standards are evolved, yielding a flexible platform where the forwarding and hand-off can be optimised on a per MN, per region or per operator basis. At all stages, the operator is able to decide how stateful an element the RMA becomes with the benefit being the improved bandwidth efficiencies through switching rather than encapsulated forwarding. The operator is also able to use simple LA and RA signalling with inter-FA transient forwarding or scale up the LA and/or RA signalling complexity to first enable oRMA to nFA transient forwarding and finally inter-RMA transient forwarding. The additional complexity of the signalling improves the efficiency of the transient forwarding and reduces the burstiness of the RA layer hand-offs by giving the MN more time to execute these hand-offs. Restated, the increasing period for RA hand-offs increases the number of RA sessions that a single MN can maintain. 6. Registration Refresh and Hand-Off Processing In summary, the LA layer messaging creates and moves the LA visitor list state between FAs and RMAs during hand-offs. This enables transient forwarding of the local access traffic on the oRoA. The LA hand-off also preserves RA layer traffic through transient forwarding by generally making the RA traffic look like LA traffic on the nRoA, that is valid in the updated LA visitor list. After transient forwarding ceases, the forwarding for the oRoA will be lost but the nRoA will then be in place and will be used for new local access sessions. This will in addition enable traffic to continue to be forwarded from the oRoA via that nRoA until the RA layer updates occur. The RA layer hand-off then bypasses the oRMA and can also optionally elevate the oRMA to global HA status so that any long term sessions on the oRoA can be maintained. 6.1 LA Refresh -- LAReg +---+ LAReg +----+ |MN| --------> |oFA| --------> |oRMA| -- +---+ +----+ Figure 7. LA Refresh This is based on a standard MIP Registration (LA Reg v1) from the MN through the FA to the assigned RMA (local HA). A.W. O'Neill Expires Oct 2002 [Page 23] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 This enables the RMA to continue to forward any local access packets arriving at that RMA, addressed to the RoA, to the stated FA CoA. The basic LA MIP Registration / Reply is the same for Nested, Concatenated and GFA forwarding modes. Major changes between the forwarding modes are only seen during inter-FA, and inter-RMA LA hand-offs, and of course in RA forwarding. 6.2 LA Hand-off (Inter-FA) -- +---+ :MN: |oFA| -- +---+ ^ : ª : MOVE ªBU (PFANE) V ª ª -- LAReg +---+ LAReg +----+ |MN| --------> |nFA| --------> |oRMA| -- +---+ +----+ Figure 8. LA Hand-off This uses an LA MIP Reg v2 to the present RMA, through the new FA, to update the FA CoA for the MN specific RoA. This will cause any local access and remote access traffic for the MN to be redirected to the new FA CoA. The hand-off can in addition use the mechanisms from [RoutOpt] and [LowLat] to enable in-flight LA and RA packets, that have been tunnelled towards the old FA CoA, to be forwarded to the new FA CoA. This exchange can also enable the MN-FA SA to be context transferred to the nFA. The Inter-FA LA Hand-off can always be undertaken from a new FA that is within the region of the present RMA (intra-RMA). It can also be undertaken from a new FA that is outside the region of the present RMA if that new FA meets a number of special inter-region hand-off constraints, including having access to a suitable SA with the present RMA to authenticate the hand-off, and having a suitable way to authenticate the Binding Updates such as the PFANE extension. This mechanism would typically only be used if the new FA did not have an available RMA or access to that RMA was in some way delayed or constrained. This may well be the case for inter-technology hand-off. 6.2.1 Nested Version (using PFANE) This LA Regv2 installs a persistent forwarding entry in the oRMA for the old RoA that points local and remote access packets for that MN to the new FA CoA. The LA Reg also installs a persistent entry in the newFA for the old RoA and the PFANE/BU reports the new FA CoA to the old FA for the existing oRoA to facilitate transient forwarding. Nested transient forwarding is based on the RoA and is towards the new FA SHCoA. This is the same as existing MIP specs with the exception that the RoA is being used for LA traffic and all RA layer sessions (with HoAs). A.W. O'Neill Expires Oct 2002 [Page 24] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 6.2.2 Concatenated Version (using PFANE for RA RREQ v3 only) This LA Regv2 installs a forwarding entry in the RMA for the RoA (local and remote access) that points local and remote access packets for that MN to the new FA MSCoA and away from the old FA MSCoA. The PFANE installs a persistent entry in the newFA for the new MSCoA (local and remote access) pointing to the MN interface from either the oRMA or the oFA. The PFANE triggered BU causes the old FA to switch local and remote access traffic from the old FA MSCoA to the new FA MSCoA and forwards to the new FA. This is different to existing MIP specs but re-uses the same signalling messages. 6.2.3 GFA Version (using PFANE for RA RREQ v3 only) This is as for Concatenated MIP except that the old and new CoA are FA SHCoAs and forwarding in the oRMA, oFA and nFA is for the RoA (local access) and the HoA (remote access). HoA and RoA state is therefore required and transient forwarding is as per existing MIP specs towards the new FA SHCoA. Note that the oRMA CoA is a SHCoA and not the oRoA. 6.3 LA Hand-off (Inter-RMA, Inter-FA) -- +---+ +----+ :MN: |oFA| |oRMA| -- +---+ +----+ ^ : ª : MOVE ªBU(PFANE) V ª ª -- LAReg +---+ LAReg +----+ |MN| --------> |nFA| --------> |nRMA| -- +---+ +----+ Figure 9. LA Hand-off with PFANE The inter-RMA, inter-FA LA hand-off is normally be undertaken by sending a LA MIP Reg v3 to the new RMA, via a new FA (and FA CoA), and in the process acquiring a new RoA. The hand-off can in addition use the mechanisms from [RoutOpt] and [LowLat] to enable in-flight packets towards the old FA to be forwarded to the new FA. Note that the state for the nRoA is not in place until the RREP returns to the MN. This is fine because no traffic will have been initiated from the MN to that new local address. In addition, no inter- RMA forwarding that uses that nRoA is being requested. The visitor lists must temporarily support both the old RoA and the new RoA for this to succeed. The host RA/LA stack sees this hand-off as the addition of a new interface with the new RoA and the subsequent loss of the old interface with the old RoA. The network driver sees the RMA, FA, FA CoA and RoA change, deals with relaying of packets sent via the oFA, and also handles the timing of the interface up and down signals. The nature of the inter-FA forwarding depends on the capabilities of the old and new FA, as well as the requested type of RMA forwarding from the newRMA. There are two permutations that are covered in detail in section 7. A.W. O'Neill Expires Oct 2002 [Page 25] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 There are nine types of old RMA / new RMA mode combinations with three simple examples given below but the full nine combinations are analysed in section 9 as part of inter-RMA forwarding. Note that five of these combinations can be avoided, if GFA deployment does not occur, and hence avoiding the backwards compatibility requirement. 6.3.1 Nested Version (Nested RMA to Nested RMA using PFANE) The LA Registration is directed to the new RMA rather than the old RMA. The new FA SHCoA is of course used to create the binding in the new RMA. The modified PFANE extension is used to trigger a BU in the newFA back to the oldFA. This installs a forwarding entry in the oFA that points local and remote access packets for that MN to the new FA SHCoA. The PFANE installs a temporary entry in the newFA for the old RoA as well as a new persistent entry for the new RoA that will be constructed by the LA Reg to the new RMA. 6.3.2 Concatenated Version (Concat RMA to Concat RMA using PFANE) The LA Reg is as previously described in section 6.2.1. but this time installs the new FA MSCoA from the new FA into the new RMA. The PFANE triggered BU installs a forwarding entry in the oFA for the previous oRoA (local access) and MSCoA (remote access) that points packets for that MN to the new FA MSCoA. The modified PFANE installs a temporary entry in the newFA for the old RoA from the oFA (local and remote access), as well as a persistent entry for the new RoA from CNs (local access) and for the new FA MSCoA from the nRMA (remote access). 6.3.3 GFA Version (GFA RMA to GFA RMA using PFANE) This is as for Concatenated MIP except that the old and new FA CoA are shared and forwarding is for the RoA (local access) and the HoA (remote access). 6.4 Enhanced LA Hand-off (Inter-RMA, Inter-FA) -- +---+ +----+ :MN: |oFA| |oRMA| -- +---+ +----+ ^ / ^ : ª / ª : MOVE ªBU(PF) / ªBU (PRANE) V ª /BU(PRANE)ª ª / ª -- LAReg +---+ LAReg +----+ |MN| --------> |nFA| --------> |nRMA| -- +---+ +----+ Figure 10. LA hand-off with PRANE The inter-RMA, inter-FA LA hand-off in 6.2 can be enhanced by the MN including a Previous RMA Notification Extension (PRANE) in the LA Reg along with the PFANE (PF) (creating an LA Reg v4). The nFA can send an authenticated BU to the oRMA to facilitate inter-region transient forwarding from the oRMA (to the nFA) instead of simply relying on the more expensive (latency, bandwidth) inter-FA forwarding. A.W. O'Neill Expires Oct 2002 [Page 26] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 The MN pre-calculates the BU authentication for the nFA in a similar manner to that used for PFANE in [RoutOpt]. This forwarding relies on the existing MN-oRMA SA and ensures that the oRMA can safely redirect the forwarding away from the oFA to the nFA. The constraints on this are covered in section 10, with the transient forwarding shown in section 8. If the nRMA shares an authenticating SA with the oRMA, then the PRANE can trigger the nRMA to issue a BU to the oRMA on behalf of the MN with the BUack again being returned to the MN. The SA is required to authenticate the dynamically allocated RMA CoA that must be added by the nRMA as it cannot be known in advance by the MN and hence authenticated. This SA also enables the oRMA to forward the MN-RMA SA and the oRMA-HA SAs to the nRMA as part of the hand-off. This inter region SA will be common within an operators domain and may be even be available across operator boundaries to ensure that inter-RMA traffic is exposed to inter-operator policy in the core of the network, and to minimise the need for extensive inter-FA inter-operator security configuration. In the latter case, the short period of inter-FA forwarding across operator boundaries could be enabled simply on the PFANE and in advance of the authentication check for the MN in the new operators domain. Note that the state for forwarding the nRoA is not fully in place until the RREP returns to the MN, because the nRoA was not in the RREQ. This is fine because no traffic will have been initiated from the MN to that new local address. In addition, any inter-RMA forwarding that uses that nRoA is being requested by a BU whilst the RMA returns the RREP to the MN. The nRMA does not therefore wait for the result of the BU as the MN will see the BUack itself and any failure will be compensated by the other forms of inter-region forwarding. There may be a requirement to slightly delay the forwarding by the oRMA towards the nRMA using the nRMA to ensure that the RREP has reached the MN. This dependence on the RREP being received is a specific week point in the design and is not generally applicable to GFA forwarding when it uses a known GFA CoA in the RREQ. Other strategies to overcome this can therefore include using a GFA SHCoA instead of the nRoA for transient forwarding of traffic on the oRoA, but this is not further detailed here as the cost/benefit of this needs further assessment. Another technique might be to modify the BUack so that in this case it contains the nRoA and not the oRoA, and hence can enable the MN to resend the RREQ for the nRMA, nRoA pair, if received before the RREP, to ensure the visitor list entries are in place. 6.5 RA Layer Registration Update The MN populates the CoA field with the RoA (Nested, Concat) that was assigned at the LA layer to create a CCoA and sets the 'D' bit. In the case of GFA mode, the RMA SHCoA (GFA) is instead used and the 'D' bit is not set. The message is directed to the HA for the HoA of the Remote Access session via a range of routes as discussed below. A.W. O'Neill Expires Oct 2002 [Page 27] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 6.5.1 RA RREQ v1 (Nested only) -- RAReg +----+ |MN| ------------------------------------------> | HA | -- +----+ Figure 11. RA Reg v1 This uses a standard MIP Registration with the MN populating the HA/HoA fields with its statically assigned address information from the home subnet, or using MIP to dynamically assign those elements. The MN then forwards the MIP Reg directly to the global HA with the 'D' bit set. Forwarding by the HA is into a tunnel with the RoA as a destination address, and the RMA adds an additional tunnel to forward to the present FA CoA. This is default Nested MIP forwarding. The Style Extension is optionally be used here to overrule the default RA forwarding mode that was agreed at the LA layer. The RA visitor list is maintained in the MN to ensure that packets for the HoA are only received from the registered HA. There is no RA visitor list in the FA because the FA is not visited by the Registration signalling. This means however that injected packets towards the HoA, from illegal 'HA' sources can only be detected at the MN and after consuming backhaul and air- link resources. The operator can however configure a firewall in the FA to snoop packets and to therefore indirectly control allowed packet flows. 6.5.2 RA RREQ v2 (Nested Only) -- RAReg +---+ RAReg +----+ |MN| --------> :oFA: -------------------------> | HA | -- +---+ +----+ Figure 12. RA Reg v2 This uses a standard MIP CCoA Registration via the FA. The FA forwarding option can be used by the MN when the FA indicates support for this by setting the 'R' bit in the FAA. The 'R' bit is not specific to Nested MIP and therefore a MN should not assume that the 'R' bit signifies support for the Nested MIP feature. This can only be discovered through the processing of the Style Extension at the LA layer. The stylext can be included at the RA layer to control RA service features. If the Stylext is missing or ignored, then the Registration looks like a standard remote access registration with a CCoA via an FA, and no Nested MIP specific additional features will be invoked. The RA visitor list is again maintained in the MN to ensure that packets for the HoA are only received in the MN from the correct HA, via the correct FA. The RA visitor list in the FA can check that the RoA flow arrived from the correct RMA source address. A.W. O'Neill Expires Oct 2002 [Page 28] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 The RA visitor list in the FA can optionally check to make sure that the HoA within the RoA flow was originally sent from the correct HA, and that the RoA and HoA are owned by the same MN. This enables some falsely injected packets, from unknown remote access gateways, to be removed before they consume air- link resources. However, this HoA specific state must then be maintained using Context Transfer, triggered by aggregated LA MIP Reg signalling, to survive inter-FA hand-off. 6.5.3 RA RREQ v3 (Nested, Concat or GFA) -- RAReg +---+ RAReg +----+ or RAReg +----+ |MN| --------> :oFA: --------> :oRMA: --------> | HA | -- +---+ +----+ +----+ Figure 13. RA Reg v3 This re-uses a similar model to the Home MIP Registration from [RegTun] as modified by [RegTunMods] and is available if the 'I' bit is set in the FAA. The MN forwards the MIP Reg to the FA as a result of the 'R' bit. The FA then makes an operator policy decision, based on the LA layer state, the RA Reg contents as well as operator and MN specific AAA state, whether to forward via the RMA (v3) or whether to send directly to the HA (v2). If the RREG is routed via the RMA then the full range of forwarding models are possible. The Style Extension is optionally used here simply for the MN to request a non default RA service features, as opposed to simply relying on the features in the MN AAA profile, and the forwarding mode agreed at the LA layer. The RA visitor list is maintained in the MN, and may be maintained in the FA and the RMA based on operator policy. These visitor lists act to ensure that packets for the HoA are only received in the MN from the correct HA. The checks in the FA and RMA minimize opportunities for falsely injected packets from consuming expensive backhaul and air-link resources. 6.6 RA Hand-off (inter-RMA, optionally inter-FA) -- +---+ +----+ :MN: |oFA| |oRMA| -- +---+ +----+ ^ : | : MOVE | RAReg V | | -- RAReg +---+ RAReg +----+ or RAReg +----+ |MN| --------> :nFA: --------> :nRMA: --------> | HA | -- +---+ +----+ +----+ Figure 14. RA Reg v3 Hand-off The LA MIP hand-off configures the new RMA/RoA and installs the inter-region forwarding (inter-FA, inter-RMA and/or RMA->FA) for the RA MIP updates. A.W. O'Neill Expires Oct 2002 [Page 29] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 The RA MIP Reg is then used, to each HA with which the MN has a remote access session, to update the CCoA (the RoA) of the HoA used for that session. In either the HA=oRMA or global HA cases, the CCoA (which was the old RoA from the old RMA), is replaced with the new RoA from the new RMA in the RA Reg. The updated visitor list in the HA causes remote access packets to now bypass the old RMA and instead be routed directly to the new RMA by using the nRoA. Here it will be handled by the RA visitor list installed by the RA hand-off message. If the RA hand-off is directed at the oRMA then it prepares the old RMA/RoA for continued use via remote access to the nRoA address. This is only possible if the oRMA-nRMA or the HA-nRMA share or can generate an authenticating SA to protect the extensions between these elements. These can be acquired from the AAA system based on the optional local and home AAA- NAIs, or the HA-RMA SA can be CTed from the oRMA at the LA layer if an RMA- RMA SA is in place, and the RMA-RMA SA can be manually or automatically configured in sympathy with the RMA LA hand-off neighbours. The RA MIP hand-off does not need to immediately follow the LA MIP hand-off for the following reasons. If the RA MIP hand-off was preceded by an LA MIP Reg v4 then inter-RMA forwarding will be valid for a significant number of inter-FA hand-offs in the new region. The MN can therefore distribute the RA MIP signalling load (across potentially multiple remote access sessions), and refresh them in order of the remaining lifetimes of the visitor list entries. Inter-FA forwarding in this case is only needed to forward the packets that are in- flight between the old RMA and the old FA, to the new FA. This is because in-flight packets between the HA and the old RMA will instead use inter- RMA forwarding. Note that if oRMA -> nFA forwarding is in place then the MN will preferably need to execute all of its RA MIP hand-offs before another two inter-FA hand-offs occur to avoid any inter-FA chaining. If the RA MIP hand-off was preceded by a LA MIP Regv3 then no inter-RMA forwarding will be in place but there will still be inter-FA forwarding. In this case the MN will preferably need to execute all of its RA MIP hand-offs before another inter-FA hand-off occurs to avoid any chaining. Methods for improving the speed of RA updates are discussed in section 10. 6.7 Combined LA/RA Hand-off (for the oRMA) -- +---+ +----+ :MN: |oFA| |oRMA| -- +---+ +----+ ^ ^ : ª ª : MOVE ªBU (PFANE) ªCReg V ª ª ª ª -- CReg +---+ CReg +----+ |MN| --------> |nFA| --------> |nRMA| -- +---+ +----+ Figure 15. Combined RA/LA v1 A.W. O'Neill Expires Oct 2002 [Page 30] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 Combined LA/RA Signalling is a basic feature of this draft when the 'I' bit is set in the FAA (for HFAIPext and HFAext support) and no additional flags or extension mechanisms are required to support it. New error codes may be appropriate though but this is for further study. The LA layer is typically used to dynamically acquire the RMA and the RoA at each RMA, to trigger the fetching of the MN AAA profile, to negotiate the RA forwarding mode and to agree the access mode. The RA layer can also undertake this LA processing automatically by the FA using the HFAIPext (that is used in GFA) to inform the MN of the assigned RMA, and the HFAext can be used to carry the RMA CoA to the HA and the MN. This particular Combined Registration is based on a combination of a LA MIP Reg v3 and an RA MIP Reg v3. This Registration is routed via the new FA and the new RMA to the old RMA. The CoA in the oRMA, for forwarding to the nRMA, is the nRoA if Nested or Concat mode is requested at the nRMA. In GFA mode, this CoA is generally a nRMA SHCoA. The Combined LA/RA MIP Reg is routed via the new RMA to enable dynamic allocation of the new RoA. It is then sent to the old RMA to transition the oRMA into the RA layer and thereby become a global HA/HoA pair for the oRoA local address. This also cancels the LA forwarding in the oRMA towards the oFA CoA. The Combined LA/RA Reg therefore initialises persistent forwarding of LA traffic on the oRoA to the nRMA. This forwarding is then subsequently maintained using RA MIP messages as with any RA session. The Combined LA/RA Reg also initializes transient forwarding towards the nRMA, for remote access traffic from other global HAs sent towards the oRMA. This transient forwarding continues for the lifetime of the temporary binding signalled by the Reg. The precise mechanism for this forwarding depends on the nature of the existing and new registrations (Nested, Concat or GFA) and is discussed in section 9. A stylext should be used for both the LA and RA layers to indicate the required features in each layer away from the default features of this draft. The message routing to the oRMA via the nRMA requires the two RMAs to share a preconfigured or dynamically allocated security association to authenticate the message exchanges. The nRMA only forwards the message to the oldRMA if it has such an association otherwise the Combined LA/RA Reg fails to update the oRMA but still returns the LA MIP Reg state from the nRMA in an LA MIP RREP, returning the identification field from the RREQ. Note that if the inter-RMA forwarding relies on the nRoA then it is correctly installed by the RREQ in the nRMA and oRMA, but will not yet have been installed in the nFA because this nRoA address was not in the RREQ until it reached the oRMA where the nRoA is assigned. The oRMA must not therefore start forwarding via the nRMA until sufficient time is given for the RREP to return to the nFA via the nRMA. It is therefore preferable for the nRMA LA layer to immediately send a RREP and then have the RA layer send a second RREP from the oRMA in response to the Combined RREQ (although Identification field issues have yet to be addressed here). A.W. O'Neill Expires Oct 2002 [Page 31] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 6.8 Combined RA/LA Hand-off (for other global HAs) -- +---+ +----+ :MN: |oFA| |oRMA| -- +---+ +----+ ^ ^ : ª ª : MOVE ªBU (PFANE) ªBU (PRANE) V ª ª ª ª -- CReg +---+ CReg +----+ CReg +----+ |MN| --------> |nFA| --------> |nRMA| --------> | HA | -- +---+ +----+ +----+ Figure 16. Combined RA/LA Reg v2 This is a combination of an LA Reg v4 and an RA Reg v3. It is used when only transient forwarding is required from the oRMA for local and remote access traffic. A stylext should be used for both the LA and RA layers to indicate the required features in each layer away from the default features of this draft. Note that there is a risk that forwarding to a distant HA like this could result in an extended delay for the return of the combined Reg reply and the associated LA parameters for the LA hand-off. However, during this time, inter-RMA and inter-FA forwarding will continue for the oRoA. The oRoA is lost once the transient forwarding has finished on the expiry of the BU lifetime that is known to the MN. The oRMA in this case does not transition to become a global HA and the oRoA does not become another HoA for the MN. The target HA for the Combined RA/LA Reg can be any HA whether or not it is presently an active RA session for the MN. The MN selects the target HA based on local preference. The security requirements are as for the component LA and RA messages although the fact that the messages are combined places greater emphasis on the need for a pre-configured RMA-RMA SA to be in place to avoid a AAA look- up delaying any hand-off. Once again, if the RA aspects of the Combined Reg fails then the LA Reg aspects should still complete if possible, leaving in place an LA v4 hand-off with transient forwarding. The converse is not applicable because if the LA fails to the new RMA then the RA layer can also not complete as defined. Once again, the FA visitor list state for the nRoA is not in place until the RREP returns with that address. The GFA SHCoA, BU ack and the RREP solutions from the nRMA can be again used here to assist in avoiding packets being forwarded towards a black-hole. 7. Summary of Inter-FA Forwarding during Hand-off The Inter-FA transient forwarding can be initiated using any mechanism associated with an MIP inter-FA hand-off from [LowLat] or [RoutOpt]. The below analysis assumes a PFANE triggered BU as in [RoutOpt] is used, being sent from the nFA to the oFA, pre-authenticated by the MN. This can be associated with an LA MIP RREQ v2,v3 or v4. A.W. O'Neill Expires Oct 2002 [Page 32] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 For LA MIP RREQ v2, which is never used for an inter-RMA hand-off, the RMA forwarding mode is unchanged and so the BU does not need to indicate the nRMA forwarding mode. For LA MIP RREQ v3 and v4, the BU also does not need to inform the old FA of the nFA forwarding model because the only change is that the nFA CoA is either a SHCoA or a MSCoA. 7.1 Transient forwarding for standard FA CoA switching CN HA oRMA oFA nFA MN Forward oLA CN----------------------------------------------------->oRoA oRMA===>oFACoA x oFA===>nSHCoA Forward RA CN------------------------------------------------------>HoA HA==========================================>oRoA oRMA===>oFACoA x oFA===>nSHCoA Figure 17. FA CoA switching The oFA decapsulates from the oFACoA inspects its binding cache for the oRoA(Nested), oRoA+HoA(GFA), or incoming oMSCoA. This identifies the nFA and so the oFA re-encapsulates into the nFA SHCoA. The nFA must then have visitor list state for the oRoA (Nested) or oRoA+HoA (GFA) so that the arriving packets can be forwarded to the correct MN. Note that when moving to or from an FA that does not support Nested or Concat MIP, nor even supports RMAs, the inter-FA forwarding is still installed towards the FA SHCoA due to the BU being unchanged by this draft. Forwarding is only changed at the nFA supporting Concat mode and only when moving to that nFA. 7.2 Transient forwarding for Concat CoA switching CN HA oRMA oFA nFA MN Forward oLA CN----------------------------------------------------->oRoA oRMA===>oFACoA x oFA===>nMSCoA Forward RA CN------------------------------------------------------>HoA HA============================================>oRoA oRMA===>oFACoA x oFA===>nMSCoA Figure 18. Concat CoA Switching The oFA decapsulates from the oFACoA inspects its binding cache for the oRoA(Nested), HoA(GFA), or incoming oMSCoA. This identifies the nFA and so the oFA re-encapsulates into the nFA MSCoA. The nFA must then have visitor list state for the nFA MSCoA so that the arriving packets can be forwarded to the correct MN. A.W. O'Neill Expires Oct 2002 [Page 33] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 8. Summary of Inter-Region Transient Forwarding (oRMA->nFA) When a MN is equipped with an LA MIP v4 (PRANE capability) then it can register with the nRMA and can in addition send a BU from the nFA to the oRMA to instigate inter-region forwarding. Inter-region forwarding from the oRMA to the nFA is more efficient (bandwidth, latency) which improves performance and reduces the load on expensive access circuits. The oRMA encapsulates LA packets sent to the oRoA into the nFA CoA. The oRMA also encapsulates RA packets into the nFA CoA, sent from the HA to either the oRoA (nested/concat) or the RMA SHCoA (GFA). The nFA does not yet know the agreed nRMA forwarding mode and so should request Nested mode which is supported by all RMAs and FAs. This also ensures that the MN can insert the FA SHCoA into the PFANE and calculate the authenticator for the BU which it could not do with a dynamically allocated FA MSCoA. The oRMA knows that such all BUs from nFAs are for Nested forwarding and knows its own forwarding mode. This means that once again the BU does not need to deal with signalling the nFA mode. 8.1 Transient forwarding from Nested oRMA to Nested nFA CN HA oRMA oFA nFA MN Forward oLA CN----------------------------------------------------->oRoA oRMA================>nSHCoA Forward RA CN------------------------------------------------------>HoA HA===========================================>oRoA oRMA================>nSHCoA Figure 19. Nested to Nested inter-region forwarding The oRMA receives the BU containing the nFA CoA and the oRoA and encapsulates traffic sent to the oRoA, into the nFA SHCoA based on the RoA state in the RA visitor list. Both LA and RA traffic arrives at the nFA and is forwarded based on the oRoA. 8.2 Transient forwarding from Concat oRMA to Nested nFA CN HA oRMA oFA nFA MN Forward oLA CN----------------------------------------------------->oRoA oRMA================>nSHCoA Forward RA CN------------------------------------------------------>HoA HA==>oRoA x oRMA==============================>nRoA oRMA================>nSHCoA Figure 20. Concat to Nested Inter-region forwarding A.W. O'Neill Expires Oct 2002 [Page 34] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 The oRMA receives the BU containing the nFA CoA and the oRoA and switches traffic from the HA to the oRoA, into a tunnel from oRMA to the oRoA, based on the RA visitor list state. The oRMA then encapsulates this into the nFA SHCoA based on the RoA state in the LA visitor list. 8.3 Transient forwarding from GFA oRMA to Nested nFA CN HA oRMA oFA nFA MN Forward oLA CN----------------------------------------------------->oRoA oRMA================>nSHCoA Forward RA CN------------------------------------------------------>HoA HA==>oRMA x oRMA==============================>oRoA oRMA================>nSHCoA Figure 21. Concat to Nested Inter-region forwarding This is as for Concat except that the traffic is received on the oRMA SH CoA, and the RA visitor list contains HoA state as well as RoA state. 9. Summary of Inter-RMA Transient Forwarding during Hand-off Inter-RMA transient forwarding is between two regional nodes rather than between two edge FA nodes or a combination of RMA and FA. This is useful because it is more scalable for neighboring regional nodes to share pre- configured SAs and policies to secure and control the inter-regional forwarding. It also enables early exposure to the policing, QoS and accounting controls in the newRMA. The use of inter-RMA forwarding is also useful during inter-domain handoffs where inter-operator service and accounting policies need to applied. Finally, the transient forwarding can be for a significant amount of time due to the much slower hand-off dynamics at that layer, during which the MN can issue multiple RA MIP hand-offs to multiple other global HAs to update them with the new RoA address. The Inter-RMA transient forwarding can be initiated using either a BU from the nRMA to the oRMA as part of an LA MIP RREQ v4, or by using an RA MIP RREQ v3 to the oRMA via the nRMA after an LA MIP RREQ v3. The following examples assume an LA MIP RREQ v4 and cover the combinations from and to Nested and Concat RA layer forwarding modes in the old and new RMA. The examples are without proxy CCoAs and therefore with encapsulation over the air interface and only the forward directions are shown in a futile attempt for brevity. A.W. O'Neill Expires Oct 2002 [Page 35] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 9.1 Nested to Nested using Nested inter-RMA transient forwarding CN HA oRMA nRMA FA MN a) Forward oLA CN----------------------------------------------------->oRoA oRMA================>oSHCoA Forward RA CN------------------------------------------------------>HoA HA===========================================>oRoA oRMA================>oSHCoA b) Forward oLA CN----------------------------------------------------->oRoA oRMA============================>nRoA nRMA===>nSHCoA Forward RA CN------------------------------------------------------>HoA HA===========================================>oRoA oRMA============================>nRoA nRMA===>nSHCoA c) Forward nLA CN----------------------------------------------------->nRoA nRMA===>nSHCoA Forward RA CN------------------------------------------------------>HoA HA===========================================>nRoA nRMA===>nSHCoA Figure 22. Forwarding for Nested to Nested via Nested a)Before LA Hand-off in the oFA/oRMA The local access traffic (CN:oRoA) is being encapsulated into the oFA SHCoA and then the oFA is decapsulating and forwarding to the MN using the oRoA. Any remote access (HA:oRMA[CN:HoA]) is being encapsulated into the oFA SHCoA and then the oFA is decapsulating and forwarding to the MN using the oRoA. Note that the FA could also be decapsulating the oRoA header to check for registered HA/HoAs if the FA optionally has HA/HoA specific processing. For LA Hand-off. The LA MIP Reg v4 sends the information to the nRMA, and a BU to the oRMA. The LA Reg (nest) prepares the nFA to decapsulate packets from the nFA SHCoA and forward nRoA and oRoA traffic to the MN (new state). The LA Reg (nest) prepares the nRMA to encapsulate packets sent to the nRoA (from CNs and oRMA) into the nFA SHCoA (new state, oRMA undertaking HA check). The inter-RMA BU (nest) prepares the oRMA to encaps packets sent to the oRoA (from CNs and registered HAs) into the nRoA and to cancel forwarding to the oFA SHCoA. All packets now go from the oRMA to the nRMA, to the nFA, to the MN as in (b). For RMA Hand-off MN now leisurely sends an RA Reg (Nest) for each HoA/HA pair via nFA/nRMA. The RA Reg (nest) prepares the nFA to decapsulate packets from the nFA SHCoA and forward any RoAs to the MN (note FA already doing this). The RA Reg (nest) prepares the nRMA to encapsulate packets from registered HAs to the nRoA, into the nFA SHCoA. (nRMA now doing HA check). The RA Reg (nest) prepares the HA to encapsulate packets to the HoA into the nRoA instead of into the oRoA (new state for oRMA bypass). A.W. O'Neill Expires Oct 2002 [Page 36] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 c) After RA Hand-off completion HoA packets are encapsulated into the nRoA in the HA. Packets to the nRoA are encapsulated into the nFA SHCoA in the nRMA. Packets to the nFA SHCoA are decapsulated in the nFA, the nRoA inspected and the packets sent to the MN. 9.2 Nested to Concat using a Concat inter-RMA transient forwarding CN HA oRMA nRMA FA MN a) Forward oLA CN----------------------------------------------------->oRoA oRMA================>oSHCoA Forward RA CN------------------------------------------------------>HoA HA==========================================>oRoA oRMA================>oSHCoA b) Forward oLA CN----------------------------------------------------->oRoA oRMA==>nRoA x nRMA==>nMSCoA Forward RA CN------------------------------------------------------>HoA HA==========================================>oRoA oRMA==>nRoA x nRMA==>nMSCoA c) Forward nLA CN----------------------------------------------------->nRoA nRMA==>nMSCoA Forward RA CN------------------------------------------------------>HoA HA=================>nRoA x nRMA==>nMSCoA====>nRoA Figure 23. Forwarding for Nested to Concat via Concat a)Before LA Hand-off in the oFA/oRMA The local access traffic (CN:oRoA) is being encapsulated into the oFA SHCoA and then the oFA is decapsulating and forwarding to the MN using the oRoA. Any remote access (HA:oRMA[CN:HoA]) is being encapsulated into the oFA SHCoA and then the oFA is decapsulating and forwarding to the MN using the oRoA. Note that the FA could also be decapsulating the oRoA header to check for registered HA/HoAs if the FA optionally has HA/HoA specific processing. For LA Hand-off The LA MIP Reg v4 (concat) sends the information to the nRMA, and a BU to the oRMA. The LA Reg (concat) prepares the nFA to decapsulate packets from the nFA MSCoA and forward oRoA, nRoA and HoA traffic to the MN that owns that MSCoA (new state). The LA Reg (concat) prepares the nRMA to encapsulate packets sent to the nRoA (from CNs) and to switch packets sent to the nRoA (from the oRMA), into the nFA MSCoA (new state, oRMA undertaking HA check). The inter-RMA BU (nest) prepares the oRMA to encaps packets sent to the oRoA (from CNs and registered HAs) into the nRoA and to cancel forwarding to the oFA SHCoA. All packets now go via the oRMA, nRMA, the nFA and the MN (b). For RMA Hand-off MN now leisurely sends an RA Reg (Concat) for each HoA/HA pair via nFA/nRMA. The RA Reg (concat) prepares the nFA to decapsulate packets from the nFA MSCoA and forward any oRoA, nRoA and HoAs to the MN that owns that MSCoA (note FA already doing this). A.W. O'Neill Expires Oct 2002 [Page 37] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 The RA Reg (concat) prepares the nRMA to encapsulate packets from registered HAs sent to the nRoA, into the nFA MSCoA (nRMA now doing HA check). The RA Reg (concat) prepares the HA to encapsulate packets to the HoA into the nRoA instead of into the oRoA (new state for oRMA bypass). c) After RA Hand-off completion HoA packets are encapsulated into the nRoA in the HA. In the nRMA, packets to the nRoA from registered HAs are then switched into the nFA MSCoA. Packets to the nRoA from CNs are encapsulated by the nRMA into the nFA MSCoA. Registering via the RMA is therefore beneficial to the operator because of the reduced encapsulation. The nFA decapsulates from the FA MSCoA, identifies the target MN that owns that MSCoA, and the packets are then sent to the MN. 9.3 Concat to Concat using Concat inter-RMA transient forwarding CN HA oRMA nRMA FA MN a) Forward oLA CN----------------------------------------------------->oRoA oRMA================>oMSCoA Forward RA CN------------------------------------------------------>HoA HA===>oRoA x oRMA================>oMSCoA===>oRoA b) Forward oLA CN----------------------------------------------------->oRoA oRMA==>nRoA x nRMA==>nMSCoA Forward RA CN------------------------------------------------------>HoA HA===>oRoA x oRMA==>nRoA x nRMA==>nMSCoA===>nRoA c) Forward nLA CN----------------------------------------------------->nRoA nRMA==>nSHCoA Forward RA CN------------------------------------------------------>HoA HA=================>nRoA x nRMA==>nMSCoA===>nRoA Figure 24. Forwarding for Concat to Concat via Concat a)Before LA Hand-off in the oFA/oRMA The local access traffic (CN:oRoA) is being encapsulated into the oFA MSCoA and then the oFA is decapsulating and forwarding to the MN using that oMSCoA/oRoA. Any remote access (HA:oRMA[CN:HoA]) is being encapsulated into the oFA MSCoA and then the oFA is decapsulating and forwarding to the MN using the oMSCoA. Note that the FA could also be decapsulating the oRoA header to check for registered HA/HoAs if the FA optionally has HA/HoA specific processing. For LA Hand-off The LA MIP Reg v4 (concat) sends the information to the nRMA, and a BU to the oRMA. The LA Reg (concat) prepares the nFA to decapsulate packets from the nFA MSCoA and forward oRoA, nRoA and HoA traffic to the MN that owns that MSCoA (new state). The LA Reg (concat) prepares the nRMA to encapsulate packets sent to the nRoA (from CNs) and to switch packets sent to the nRoA (from the oRMA), into the nFA MSCoA (new state, oRMA undertaking HA check). The inter-RMA BU (nest) prepares the oRMA to encaps packets sent to the oRoA (from CNs and registered HAs) into the nRoA and to cancel forwarding to the oFA MSCoA. All packets now go via the oRMA, nRMA, the nFA and the MN (b). A.W. O'Neill Expires Oct 2002 [Page 38] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 For RMA Hand-off MN now leisurely sends an RA Reg (Concat) for each HoA/HA pair via nFA/nRMA. The RA Reg (concat) prepares the nFA to decapsulate packets from the nFA MSCoA and forward any oRoA, nRoA and HoAs to the MN that owns that MSCoA (note FA already doing this). The RA Reg (concat) prepares the nRMA to encapsulate packets from registered HAs sent to the nRoA, into the nFA MSCoA (nRMA now doing HA check). The RA Reg (concat) prepares the HA to encapsulate packets to the HoA into the nRoA instead of into the oRoA (new state for oRMA bypass). c) After RA Hand-off completion HoA packets are encapsulated into the nRoA in the HA. In the nRMA, packets to the nRoA from registered HAs are then switched into the nFA MSCoA. Packets to the nRoA from CNs are encapsulated by the nRMA into the nFA MSCoA. Registering via the RMA is therefore beneficial to the operator because of the reduced encapsulation. The nFA decapsulates from the FA MSCoA, identifies the target MN that owns that MSCoA, and the packets are then sent to the MN. 9.4 Concat to Nested using Nested inter-RMA transient forwarding CN HA oRMA nRMA FA MN a) Forward oLA CN----------------------------------------------------->oRoA oRMA================>oMSCoA Forward RA CN------------------------------------------------------>HoA HA===>oRoA x oRMA================>oMSCoA===>oRoA b) Forward oLA CN----------------------------------------------------->oRoA oRMA===========================>nRoA nRMA===>nSHCoA Forward RA CN------------------------------------------------------>HoA HA===>oRoA x oRMA===========================>nRoA nRMA===>nSHCoA c) Forward nLA CN----------------------------------------------------->nRoA nRMA===>nSHCoA Forward RA CN------------------------------------------------------>HoA HA==========================================>nRoA nRMA===>nSHCoA Figure 25. Forwarding for Concat to Nested via Nested a)Before LA Hand-off in the oFA/oRMA The local access traffic (CN:oRoA) is being encapsulated into the oFA MSCoA and then the oFA is decapsulating and forwarding to the MN using that oMSCoA/oRoA. Any remote access (HA:oRMA[CN:HoA]) is being encapsulated into the oFA MSCoA and then the oFA is decapsulating and forwarding to the MN using the oMSCoA. Note that the FA could also be decapsulating the oRoA header to check for registered HA/HoAs if the FA optionally has HA/HoA specific processing. A.W. O'Neill Expires Oct 2002 [Page 39] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 For LA Hand-off. The LA MIP Reg v4 sends the information to the nRMA, and a BU to the oRMA. The LA Reg (nest) prepares the nFA to decapsulate packets from the nFA SHCoA and forward nRoA and oRoA traffic to the MN (new state). The LA Reg (nest) prepares the nRMA to encapsulate packets sent to the nRoA (from CNs and oRMA) into the nFA SHCoA (new state, oRMA undertaking HA check). The inter-RMA BU (nest) prepares the oRMA to encaps packets sent to the oRoA (from CNs and registered HAs) into the nRoA and to cancel forwarding to the oFA MSCoA. All packets now go from the oRMA to the nRMA to the nFA to the MN as shown in (b) For RMA Hand-off MN now leisurely sends an RA Reg (Nest) for each HoA/HA pair via nFA/nRMA. The RA Reg (nest) prepares the nFA to decapsulate packets from the nFA SHCoA and forward the oRoA and nRoA to the MN (note FA already doing this). The RA Reg (nest) prepares the nRMA to encapsulate packets from registered HAs to the nRoA, into the nFA SHCoA. (nRMA now doing HA check). The RA Reg (nest) prepares the HA to encapsulate packets to the HoA into the nRoA instead of into the oRoA (new state for oRMA bypass). c) After RA Hand-off completion HoA packets are encapsulated into the nRoA in the HA. Packets to the nRoA are encapsulated into the nFA SHCoA in the nRMA. Packets to the nFA SHCoA are decapsulated in the nFA, the nRoA inspected and the packets then sent to the MN that owns that nRoA. 9.5 Nested to Nested using Concat inter-RMA transient forwarding CN HA oRMA nRMA FA MN a) Forward oLA CN----------------------------------------------------->oRoA oRMA==================>oSHCoA Forward RA CN------------------------------------------------------>HoA HA==========================================>oRoA oRMA==================>oSHCoA b) Forward oLA CN----------------------------------------------------->oRoA oRMA===>nRoA x nRMA===>nMSCoA Forward RA CN------------------------------------------------------>HoA HA==========================================>oRoA oRMA===>nRoA x nRMA===>nMSCoA c) Forward nLA CN----------------------------------------------------->nRoA nRMA===>nSHCoA Forward RA CN------------------------------------------------------>HoA HA==========================================>nRoA nRMA===>nSHCoA Figure 26. Forwarding for Nested to Nested via Concat From Nested RN to Nested RN using concatenated LA MIP Reg is possible but neither preferred nor covered in detail here. A.W. O'Neill Expires Oct 2002 [Page 40] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 9.6 Nested to Concat using Nested inter-RMA transient forwarding CN HA oRMA nRMA FA MN a) Forward oLA CN----------------------------------------------------->oRoA oRMA=================>oSHCoA Forward RA CN------------------------------------------------------>HoA HA==========================================>oRoA oRMA=================>oSHCoA b) Forward oLA CN----------------------------------------------------->oRoA oRMA===========================>nRoA nRMA===>nSHCoA Forward RA CN------------------------------------------------------>HoA HA==========================================>oRoA oRMA===========================>nRoA nRMA===>nSHCoA c) Forward nLA CN----------------------------------------------------->nRoA nRMA===>nSHCoA Forward RA CN------------------------------------------------------>HoA HA=================>nRoA x nRMA===>nMSCoA===>nRoA Figure 27. Forwarding for Nested to Concat via Nested From Nested RN to Concatenated RN using nested LA MIP Reg is possible but neither preferred nor covered in detail here. 9.7 Concat to Nested using Concat inter-RMA transient forwarding CN HA oRMA nRMA FA MN a) Forward oLA CN----------------------------------------------------->oRoA oRMA================>oMSCoA Forward RA CN------------------------------------------------------>HoA HA===>oRoA x oRMA================>oMSCoA===>oRoA b) Forward oLA CN----------------------------------------------------->oRoA oRMA==>nRoA x nRMA==>nMSCoA Forward RA CN------------------------------------------------------>HoA HA===>oRoA x oRMA==>nRoA x nRMA==>nMSCoA===>nRoA c) Forward nLA CN----------------------------------------------------->nRoA nRMA==>nSHCoA Forward RA CN------------------------------------------------------>HoA HA=========================================>nRoA nRMA==>nSHCoA Figure 28. Forwarding for Concat to Nested via Concat A.W. O'Neill Expires Oct 2002 [Page 41] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 Concat to Nested via LA MIP Reg is possible but neither preferred nor covered in detail here. 9.8 Concat to Concat using a Nested inter-RMA transient forwarding CN HA oRMA nRMA FA MN a) Forward oLA CN----------------------------------------------------->oRoA oRMA================>oMSCoA Forward RA CN------------------------------------------------------>HoA HA===>oRoA x oRMA================>oMSCoA===>oRoA b) Forward oLA CN----------------------------------------------------->oRoA oRMA==========================>nRoA nRMA===>nSHCoA Forward RA CN------------------------------------------------------>HoA HA===>oRoA x oRMA==========================>nRoA nRMA===>nSHCoA c) Forward nLA CN----------------------------------------------------->nRoA nRMA===>nSHCoA Forward RA CN------------------------------------------------------>HoA HA================>nRoA x nRMA===>nMSCoA===>nRoA Figure 29. Forwarding for Concat to Concat via Nested Concat to Concat via a Nested LA MIP Reg is possible but neither preferred nor covered in detail here. 9.9 Nested <-> Concat Option Comparisons The following table summarises the various choices when moving between RMAs using Nested and Concat modes, using Nested or Concat transient forwarding as described above. From oRMA To nRMA Via LA RREQ Comments Nested Nested Nested Triple encapsulations, simple Nested Concatenated Concatenated Single FA CoA, consistent Concatenated Nested Nested Single FA CoA, consistent Concatenated Concatenated Concatenated Minimal Encaps, Nested Nested Concatenated MSCoA and SHCoA assigned Nested Concatenated Nested MSCoA and SHCoA assigned Concatenated Nested Concatenated MSCoA and SHCoA assigned Concatenated Concatenated Nested MSCoA and SHCoA assigned The summary is intended to indicate why the last four options are not presently preferred which is because they result in the nRMA mode changing between the LA hand-off and the RA hand-off. A.W. O'Neill Expires Oct 2002 [Page 42] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 This is against the basic LA hand-off model whereby the RA layer uses the default RA forwarding behaviour agreed at the LA layer. There may be good reasons why a specific RA session may need to overrule the LA layer decision in which case the non-preferred modes do need to be supported. In addition, avoiding the triple encapsulation may justify Nested to Nested via Concat for example. The other comparison is between the cost of the triple encapsulation when moving from Nested to Nested via Nested transient forwarding whilst Concat to Concat via Concat is more complex and requires MSCoAs. Given the different characteristics and deployment requirements there is a potential need for both, which therefore requires the Nested <-> Concat hand-offs. 9.10. Inter-RMA Transient Forwarding with GFA mode This is not covered in detail but is summarised briefly. When leaving a GFA oRMA, the oRMA look-up uses HoA state but is forwarded using a nRMA CoA that is commensurate with the nRMA mode. When moving to a nRMA that is using GFA mode, from an oRMA in Nested, Concat or GFA mode, the nRMA provides the oRMA with a SH CoA and Context Transfer is used to move the HA/HoA state to the nRMA to support RA layer GFA forwarding in advance of RA layer RREQ/RREP hand-off. 10. Additional Modifications, Options and Extension Definitions 10.1 Hybrid Concat/GFA Modes The RA MIP Reg v3 sends the RoA to the HA where it is used as the destination address for the HoA encapsulation. The RoA is also used as the LA layer address for local access service. If local access is not required, and the HoA is a public address, then the RMA can instead allocate a SHCoA for the HoA binding and then forward based on the inner HoA as in GFA mode. This saves RoA addresses when they are not needed but avoids the need for HoA specific state in the FA by still using an MSCoA in the FA. The MN cannot know this RMA SHCoA in advance and so must use a blank CoA field in the RA MIP Reg v3. The RMA then adds the SHCoA into the HFAext, sends it to the HA, and the RMA returns it in a HFAext to the MN. The MN can of course populate the CoA field in subsequent refreshes via the same RMA. Equally, in GFA mode, a RMA SHCoA is used but this can be avoided if the MN also has Local access and an RoA. The RoA can be inserted into the HA such that an RMA failure can be locally recovered in another RMA without having to update the HA. In addition, the RoA is known at the LA layer and so the backwards compatibility issue with a CoA=0 is avoided. 10.2 GFA and private HoAs Private HoAs cannot safely be supported in GFA or hybrid mode because forwarding is dependent on a potentially non-unique private HoA. This limits GFA mode, and the above hybrid mode to public HoAs. This restriction can be relaxed however if a FA MSCoA is used instead of a FA SHCoA because the concatenation of the MSCoA+HoA ensures uniqueness. This is not necessary in the RMA because the HoA can be made unique through the concatenation of the HA and the HoA, making an RMA SHCoA permissible. A.W. O'Neill Expires Oct 2002 [Page 43] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 10.3 Heterogeneous RA forwarding modes In section 5,it was explained how the LA MIP Reg identifies the capabilities of the RMA and installs a single mode of RA forwarding for all RA sessions from that MN. This is reasonable because the HA is not aware of the RMA forwarding mode and the HA changes are simply to be able to support [RegTunMods] home registration extensions to enable the use and transfer of dynamically assigned CoAs and RMA addresses. However, there may well be reasons why the MN (possible as a result of the home operator AAA profile) will have a preference over which mode is used by the MN to that HA. If such a preference does exist then this can be easily supported using the following rules. Firstly, the LA layer must include a request in the stylext for the default LA mode which should be the Nested mode as this places the lowest burden on CoA resources and matches the LA forwarding mode. Each RA MIP Reg can then overule this default by including a stylext that indicates either Concatenated or GFA forwarding. The use of combined signalling means therefore that the LA and RA styleext must be able to be distinguished using a flag bit. When multiple RA sessions are in progress then there is a danger that a MN could acquire both a MSCoA (for concat) and a SHCoA (for GFA/Nested) at the FA, as well as a SHCoA at the RMA (GFA with no local access). This can be avoided by the LA layer always using a MSCoA instead of a SHCoA at the LA layer for all RA sessions once a MSCoA has been assigned. This requires the FA and RMA to update the visitor lists accordingly for the MN. Secondly, during inter-FA hand-off, the LA MIP Reg must be able to support all the different dependent RA layer sessions at the new FA in advance of the RA visitor list being refreshed. The LA MIP Reg should therefore signal wildcard mode to the FA/RMA using a FA SHCoA, unless a FA MSCoA is required by one of the RA sessions. The FA then installs visitor list entries sufficient for any interpretation (superposition) of the information in the stylext of the LA Reg. Finally, the RMA uses the correct installed forwarding for the installed session specific RA state towards that FA. The FA removes unexercised visitor list entries when the MN leaves that FA. 10.4 HA/HoA Specific Processing and Context Transfer HA/HoA specific state can be installed by the RA layer into the FA and RMA. It can also be installed by the LA MIP layer in the case of GFA mode. This state may simply be the HoA, the HA, or both and is used to supplement the RA visitor list for the associated MN/RoA. This requires the relevant node to potential look into an encapsulation to discover the HoA and/or HA source address in a packet before forwarding that packet. HA/HoA specific state must be installed in GFA mode to satisfy basic forwarding rules of that mode. HA/HoA specific state can be optionally stored and inspected in Nested and Concat mode in both the FA and the RMA. It is required in the RMA for both Nested and Concat modes when the MN is allowed to avoid RA reverse tunnelling and hence to send with the HoA as a source address. In this case, the packet must be LA reverse tunneled to the RMA to undergo a source check and the HA/HoA state must be CTed between RMAs on hand-off. A.W. O'Neill Expires Oct 2002 [Page 44] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 HA/HoA state can also be inspected to distinguish between multiple ongoing RA sessions so that HA/HoA specific accounting, QoS and policy can be applied. HA/HoA Specific QoS processing is required to enable specific HA/HoA flows to get preferential forwarding services over the air or through the network. HA/HoA Specific Accounting processing is required so that accounting records can be built and delivery to the correct home operator and third party service providers. HA/HoA Specific Policy can be used to bar or allow specific HAs and HoA address ranges from being supported. For uplink traffic, discard is most efficient at the FA whilst for downlink it is at the RMA. During inter-FA LA hand-off, any RA layer HA/HoA state will be missing in the new FA and will not be immediately rebuilt at that FA due to the longer binding lifetimes used in the RA layer to avoid excessively loading global HAs. This state must therefore be Context Transfered between the FAs during the inter-FA hand-off. Similarly, during an inter-RMA hand-off, it is necessary to space out the RA layer updates via the nRMA to avoid a flood of such messages during the hand-off. Therefore, for a short while the HA/HoA specific state will be missing in the nRMA which could impact accounting, QoS or policing. The state is however still at the oRMA which is on the forwarding path until the RA layer update to the HA and so some functionality may not be lost. However, it may still be necessary for the HA/HoA specific state to be Context Transferred from the oRMA to the nRMA when either the BU or the Combined LA/RA Reg v1 is received at the oRMA. Again, the likely need for this is known at the oRMA by the type of HA/HoA specific processing. Therefore, in either FA or RMA cases, the need for CT is known at the oFA and/or old RMA and will be triggered by the BU from the newFA / new RMA. Note that the Context Transfer of HA/HoA state can be synchronized with the CT of other state such as the general AAA profile for the MN, the MN-FA SA between FAs, the MN-RMA SA between RMAs, along with the HoA specific profile information for those HoAs and for the base RoA. The Context Transfer ideally needs to be reliable because otherwise HA/HoA state will be lost. In the case of GFA mode, the loss of such state is catastrophic to that RA flow and is one reason that Concat mode is preferred. In Nested and Concat mode, CT is used simply to transfer state that is not needed for basic forwarding and hence late or lost state can be tolerated in general and then be rebuilt on the next RA refresh. The lost value added processing is that some packets will not be correctly accounted (undercount), flows may not receive preferential service for a while, and incorrect packets will progress further in the network than intended. Each of these situations have their own commercial consequences and the CT layer should therefore have suitable reliability mechanisms commensurate with those consequences however it should be restated that basic forwarding is still always ok ensuring graceful degradation. Note also that Context Transfer can be avoided by instead storing such state in a coordinated way in the local AAA servers. The nFA and nRMA can then fetch this state when the hand-off Registration is received which should contain the AAA-NAI for that state. A.W. O'Neill Expires Oct 2002 [Page 45] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 10.5 Previous Foreign Notification Extension (PFANE) The traditional PFANE extension is used to trigger a BU to the oFA to cause the oFA to switch packets addressed to the HoA towards the new FA CoA. During inter-RMA hand-off, the LA layer forwarding between these two elements may be required in support of nested, concat or GFA from the old FA to Nested, Concat or GFA mode at the new FA. The PFANE and the associated BU do not however need to be modified because the behaviour between all the various mode combinations only varies at the nFA by the type of FA CoA (shared or MN specific) that is assigned. The oFA simply forwards towards that FA CoA and does not need to be aware of the CoA type or the nFA subsequent processing. The only change therefore is that the FA CoA can be MN specific. Note however that the MN can only pre-calculate the BU authentication if the FA CoA is advertised to the MN in the FAA. Therefore, for Concat mode, this requires the MSCoA to be unicast in an FAA in advance of the MN sending the LA RREQ. The PRANE is formatted the same as the PFANE but includes the oRMA address and the nFA CoA rather than the oFA address and the nFA CoA. The MN calculates the authenticator as for PFANE but can only do so if the FA CoA is advertised to it in an FAA before sending the LA RREQ or combined LA/RA RREQ to the HA via the nFA and nRMA. When the PRANE is protected by the MN-FA auth extension then this tells the FA that it should initiate the BU to the oRMA to instigate oRMA to nFA forwarding. The BU is sent from the FA to the oRMA and contains the HoA=oRoA and the CoA=nFA SHCoA as Nested mode in the nFA is always supported because it is required for LA layer forwarding for local access traffic. The BU does not then need to be modified in any way to deal with the various types of RA forwarding at the nFA because of this default feature. This decision is in preference to enabling the PRANE and the BU to be sent with a stylext to identify the required forwarding mode from the oFA. The PRANE can instead be wrapped in the MN-HA or MN-nRMA auth extension to instead cause the nRMA to send the BU to the oRMA. The MN-HA SA is used if the MN-nRMA SA is not immediately available but means that the nRMA cannot authenticate the PRANE but instead leaves authentication to the oRMA of the BU. The MN-nRMA can be used immediately if it is the same as the MN-oRMA SA and will be CTed to the nRMA, or fetched by the nRMA from the AAA system. The PRANE to the nRMA includes the oRMA address and the nRMA address advertised in the FAA (as the RMA SH CoA). The MN calculates the authenticator based on the MN-oRMA SA. The BU is sent by the nRMA to the oRMA for the oRoA and if authenticated will cause traffic on or associated with the oRoA to be forwarded to the nRMA using either the oRoA or the RMA SHCoA. The nRMA knows which forwarding mode is to be provided at the nRMA and so the BU needs to include this information in the BU (the Stylext) so that the oRMA can undertake the correct forwarding as recommended in section 9. The BUack is sent to the MN again via the tunnel created by the BU from the oRMA to the nRMA. The use of the RMA SHCoA for the RMA address advertised in the FAA limits this technique to intra-domain, inter-region forwarding where the nRMA SHCoA = RMA address in the FAA. A.W. O'Neill Expires Oct 2002 [Page 46] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 On inter-operator boundaries, the nRMA CoA for the oRMA will likely not be the same as the nRMA address in the FAA from the MN and nFA perspective. With an oRMA/nRMA SA in place, which is most likely necessary and useful in the case of the inter-operator boundary, the MN would include the PRANE and leave the nRMA CoA field blank. The MN would pre-calculate the authenticator including the zero address. The nRMA would generate a BU from the PRANE in the LA MIP RREQ, using the MN authenticator and forward it to the oRMA, attaching a HFAext for the nRMA CoA chosen by the nRMA (nRoA or nRMA SH CoA) based on the forwarding mode and secured by the inter-operator SA. Once again the BU Ack is returned to the MN via the nRMA and nFA to confirm to the MN that inter-operator forwarding is in place. Note that the nRMA CoA=0 rather than nRMA CoA=nRMA in the FAA is only used to avoid operator addresses leaking out of the domain. For an intra-domain inter-RMA hand-off, the nRMA CoA in the PFANE should always be the nRMA address in the FAA. The nRMA can then inspect this address and decide if it wishes to add a HFAext = new nRMA CoA to override the value in the CoA field, secured by the inter-RMA SA. 10.7 Style Extension (Stylext) The LA layer needs to select the options for the following parameters; 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 'L' Layer flag set for RA, unset for LA (unset here) 'S' Access flag set to access service at that layer 'P' Address flag set if public, unset if private address (RoA) 'N' NAT flag set if NAT is requested for a private address RoA 'A' CoA flag set if FA MSCoA, unset if FA SHCoA 'G' GFA flag set if the common RA mode at LA layer is GFA 'C' Concat flag set of the common RA mode at LA layer is Concat The RA layer needs to select the options for the following parameters; 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 'L' Layer flag set for RA, unset for LA (set here) 'S' Access flag set to access service at that layer 'P' Address flag set if public, unset if private address (HoA) 'N' NAT flag set if NAT traversal is requested 'A' CoA flag set if RMA MSCoA, unset if RMA SHCoA 'G' GFA flag set if the session specific RA mode is GFA 'C' Concat flag set if the session specific RA mode concat A.W. O'Neill Expires Oct 2002 [Page 47] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 Nested MIP, being the LA default mode, does not need to be signalled but if it is signalled is represented by the G and C flags being unset. In the case of the RA layer, both the G and C flags being unset also indicates a request for RA session specific nested mode, whilst both being set indicates that the LA layer common RA mode setting should be used. Combined LA/RA Registrations can include an LA stylext, an RA stylext or both depending on the level of feature complexity. The MN does not dynamically and explicitly request, via the Stylext, HoA/HA specific processing in the RMA and FA, nor Context Transfer services in support of the maintenance of such state during hand-off. These are instead operator features that may be determined based on the AAA profile and operator policy. They may also be mandated by specific combinations of the Stylext flags, and the MIP Reg flags, as stated below. In Concat mode, if the RA layer reverse tunnelling bit is not set, then the LA layer reverse tunnelling bit must be set so that the RMA can undertake the source address check. The RMA RA state is copied from the RA Reg v3 RREQ/RREP. Context Transfer of this state between RMAs required to enable the nRMA to undertake these checks in advance of the RA Registrations via the nRMA. In GFA mode, the RA layer must be given a public HoA and HoA specific state must be installed into the FA and RMA by copying it from the RA Reg v3 RREQ/RREP. 10.8 HFAIPext This is a generalized form of the GFAIPext in RegTun with the addition of a sub-type to indicate the address sub-type and the associated required processing. This is used to inform an upstream or downstream node of the address of a dynamically assigned upstream node so that the downstream node can direct MIP messages and data to that upstream node. Examples include the RMA and HA addresses. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | sub-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HFA IP Address | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The HFAIPext must have sufficient flags to differentiate between a range of IP addresses that can be carried, which for this draft can include the dynamically assigned HA or RMA. 10.9 HFAext This is a generalized form of the HFAext in RegTun with the addition of a sub-type to indicate the address sub-type and the associated required processing. A.W. O'Neill Expires Oct 2002 [Page 48] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 This is used to inform an upstream node of the care of address assigned by a downstream node, to which that upstream node should forward and from which that upstream node should expect to receive reverse tunneled packets. It is also used to inform the MN of the dynamically assigned CoA that it should use in the Registration CoA field. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | sub-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HFA Care of Address | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The HFAext must have sufficient flags to differentiate between a range of IP addresses that can be carried which for this draft can include the FA SHCoA, FA MSCoA, RMA SHCoA and RMA MSCoA=RoA. The RoA can also be carried in the HFAext as part of dynamic addressing in Combined messages. 10.10 HoAList During inter RMA hand-off and especially during inter-operator hand-off it is likely that the MN will not want to enable transient forwarding (inter-FA or inter-region) for specific RA sessions and associated HoAs. The HoAlist extension is an include/exclude list to inform the previous FA or RMA which HoAs to forward for. This can be used to also constrain what HA/HoA specific state is context transferred to the nFA from the oFA, and to the nRMA from the oRMA. In the absence of the HoAlist, then provided an authentication extension exists between the nodes, no HoA specific state is CTed across. This therefore works with legacy nodes that do not support HoAList Extension and also ensures that only explicit request to include HoAs can do so during hand-off. The HoAList in include form can also be used by the MN to populate the local FA with HA/HoA state, and avoid CT, when the list is short and hence bandwidth efficient. The format of the message is to be determined. 10.11 HoAResp This extension is used to confirm reception of and action on the HoAlist. It can also be used to transfer the HA/HoA state to the nFA or nRMA from the oFA or oRMA. Its transport and format has yet to be determined and is not needed if the HA/HoA state is to be transferred as part of MN AAA state, or by the MN itself. 10.12 HoAErr This extension is required to enable a HoAResp to contain HoA specific MIP error information for the nFA and MN. A.W. O'Neill Expires Oct 2002 [Page 49] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 10.13 FA-NAI regional structure The FA-NAI is supported in legacy FAs and MNs and is required to support inter-region movement detection. The FA-NAI is required so that MNs seeking regional services can be suported along with legacy MNs that do not. This is achieved by structuring the username and domain parts of the NAI as 'FAnameRMAname@domain'. The '%' character is an obvious suggestion. A legacy MN will correctly interpret the domain part to detect inter-operator hand-off and will not see the substructure in the username part, but will correctly distinguish between FAs and hence support inter-FA hand-off. Only a regional aware MN can see the sub-structure and will use this to determine when inter-FA and inter-RMA hand-offs are required. 10.14 Unicast FAA for MN specific FA CoA assignment A MN specific FAA can be sent to the MN by determining the MN link-layer address from the LA visitor list and then sending the FAA just to that MN over a unicast link-layer connection to either the broadcast address or the address of the MN. The MN then uses this rather than any broadcasted FA CoA in its MIP registration. The MN can assume that such a FA CoA is MN specific and hence enables Concat mode to be requested without using the CoA=0 and HFAext= MSCoA as part of dynamic FA CoA assignment. 10.15 When the LA layer is hidden from the RA Layer A legacy MN RA layer MIP implementation will not know about this draft. The preferred option therefore is that the LA layer is hidden from the MN OS apart from driver calls through a standardised API. The LA layer therefore intercepts the FAA with its FA and RMA movement information, and presents RMA changes to the MN as interface address changes by assigning each new RoA. The legacy RA MIP layer in the MN will then report this new interface address to the HA with which it shares an RA session. In this model the MN RA MIP implementation is pretty dumb and the LA layer monitors, intercepts and controls all AS and AA activity. This model, whilst great for initial deployment and backwards compatibility, has the draw-back however that the RA layer is not able to track regional movement, elect to preserve RMA/RoAs as RA sessions, know when it can use Reg v2 and Reg v3 or use combined RA/LA signalling etc. This can be improved by enabling the LA layer to proxy the FAA through to the RA layer but modify and hide some of the fields in the case of a legacy MN RA MIP stack so that it is not confused. However, not even this is adequate for many of the features. 10.16 When both the LA and RA layers are exposed to the FA A more complete model therefore is instead to enable both the host RA layer MIP stack and the LA layer stack to send and receive AS/AA in a coordinated manner whilst giving the LA layer ultimate control over what is permitted to be sent over the air-interface to protect the local mobility management system. A.W. O'Neill Expires Oct 2002 [Page 50] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 This can be implemented through a sophisticated API with all MIP messages ultimately being generated in the LA layer under OS control. Alternatively, both the RA and lA layer can generate their own messages, but with Combined messages only being sent by the RA layer under LA layer control. The LA layer must in all cases have capabilities to protect the operators local mobility management layer from abuse such as message rate limiting, checks on message fields, firewalling and movement verification. 10.17 When the RA layer and LA layer terminate on different elements The model above where the LA layer sends all MIP messages does not support the case where the RA stack is separate from the device implementing the LA stack. This would happen with a hub or router having the LA layer on air- interface, and a LAN on the other supporting a number of nodes sharing the hub/router for local and remote access. This provides further motivation for the model whereby either RA or LA stacks can issue messages but with the LA stack having specific controls. The node with the LA stack acts as a private address allocator for the LAN. LAN MN members use their private addresses as source addresses for local and remote access. Directly reachable members are discovered via ARP as normal. The MNs can also use those private addresses for remote access with the LA stack node acting as a proxy FA. In this case, as the hub moves in the cellular infrastructure (in a car, on a train etc) then the LA stack acts as a proxy FA by relaying a modified FAA to the MNs. The FAA over the air-interface reports inter-FA and inter-RMA movement that causes the LA stack to acquire a new RoA at each new RMA. Each newRoA, RMA is reported to the LAN in the proxied FAA (and not the FA or FA CoA) so that the RA stacks can build fully populated RA Reg messages. The RA layer adds the MN-HA auth and he RA MIP registrations should then be routed via the proxy FA, learnt from the proxied FAA and have the 'D' bit set to indicate CCoA to the cellular infrastructure as required by Nested/Concat MIP. This enables the proxy FA to discover the HoA addresses so that the MNs do not have to encapsulate to the proxy FA but can be sent natively towards the RoA default gateway address. The RoA is then a form of proxy CCoA [PCCoA] with the tunnelling functions left to the proxy FA. The proxy FA adds the LA layer extensions and the MN-FA authenticating extension. The packets from the LAN, are then forwarded by the proxy FA, according to the registration state and forwarding mode to either the FA, RMA, HA or CN. For example, reverse tunnelling in Nested mode would require the packet to be re-encapsulated in the RoA as a source address and sent to the HA. In the downlink direction, packets are encapsulated to the RoA address owned by the proxy FA which strips away the HA source, RoA destination encapsulation. The proxy FA then forwards to the MN across the LAN based on the HoA. The Proxy FA needs to potentially also support encapsulation from the MN to the proxy FA using the private address/RoA pair when non-unique HoAs are evident on the LAN. This is discovered by the proxy FA during registration and will cause the proxy FA to instruct the MN to encapsulate remote access traffic to it (and expect encapsulated traffic in return) and to not set the 'D' bit but to let the proxy FA set that bit as it forwards the registration to cellular operator as normal. A.W. O'Neill Expires Oct 2002 [Page 51] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 As far as the rest of the cellular infrastructure is concerned, the LAN appears to be a single node with multiple remote and one local access session. Only the node running the proxy FA function can utilise the RoA as a source / destination address for local access but that node can add support for a NATP function to enable local access from the multiple private addresses to share that single RoA out to the cellular domain. This then provides a scalable way for multiple MNs from different home networks to share a single wireless connection for either remote, local or remote and local services. This is possible because of the aggregation properties of the layered model. 10.18 RoA Address Allocation MIP visitor list entries in the MN, FA, RMA and HA include state that enables encapsulated packets to be correctly forwarded. The state is installed by the MIP Registration between the MN and the RMA/HA, and then confirmed by the Reply in the reverse direction. This ensures that downstream nodes have visitor list state before upstream nodes so that when the visitor list is created in the RMA/HA, arriving packets in the forward direction, from the HA to the MN, will not hit MIP elements that lack visitor list state for that flow. Unfortunately, the RoA address is used by the MN but is obtained from the RMA in each new region. Therefore, the dynamically allocated RoA is not known in advance by the MN and therefore cannot be in the MIP Registration Request towards the new RMA via the FA. This provides an opportunity for the FA visitor list to be unpopulated when the MIP Request hits the RMA, which risks packets towards that RoA being dropped at the FA because the MIP Reply processing in the FA that creates the FA visitor list will be significantly slower that data packets reaching the FA (and being dropped). This mainly affects inter-RMA forwarding that is being redirected to the nRoA from the old RMA, using either a PRANE triggered BU or a Combined RA/LA Registration Request to the oRMA. It does not affect local access traffic because no incoming packets will be generated towards the nRoA until the MN starts to use that nRoA, which it will not do until it receives the MIP Reply (which will have installed the required FA state). The RoA can be assigned in a number of ways in the new region. a) The RoA can be allocated by the RMA using MIP dynamic address allocation in which case the RoA is returned in an MIP Reply message. b) The AAA system can allocate the RoA for the RMA in which cases the address is returned to the FA in an MIP Reply message embedded within a AAA message. c) The FA can act as a DHCP client and obtain the address from the RMA that acts as a DHCP server. The message is returned to the FA in a DHCP message and is then inserted into the MIP RREQ towards the RMA. d) The FA can be pre-assigned a pool of RoA addresses from each RMA in the region. The FA can then insert the RoA itself into any MIP RREQ from a MN that has a zero RoA field at the same time that it selects the RMA address. A.W. O'Neill Expires Oct 2002 [Page 52] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 Case (a) has the problem that the FA only gets to see the RoA when receiving the RREP, by which time packets will likely already be arriving towards the RoA (inter-RMA forwarding) and therefore would normally be dropped in MIP because no visitor list entry exists. The use of the RoA should therefore be delayed upstream by some safety timer to ensure that the RREP with the new RoA has reached the FA, but this still fails if the RREP is lost Case (b) has a similar problem but can use reliable transport of the RREP in the AAA message. The use of AAA routing though means that the safety timer could need to be quite large which increases the amount of expensive inter-FA forwarding required. Case (c) incurs additional delay at the new FA before the RREQ can be sent although this delay, as with the safety timer, may well be fine in the case of make before break hand-off because the old link is still available. Case (d) requires the configuration of address pools in the FAs, that are divided out of the RMA address blocks. This can lead to significant address inefficiencies given that a MN can start at any FA within the region. There is also the problem that the FA needs to know when the address is released but that release is only presently known at the RMA, because the RoA can continue to be used at any FA and is only released explicitly using an inter- RMA hand-off BU. Case (d) is the fastest approach and consistent with the FA also assigning the RMA itself. To proceed with this method will require the RMA to provide the FA with information of when the RoA is released. In addition, the FA needs to be able to dynamically acquire additional addresses that it can allocate out. This could be achieved by the FA acting as a DHCP client with the RMA server for address management purposes. Addresses are then requested by and handed out to FAs in advance of MN arrivals, as the FA address stores get depleted. The RMA DHCP server tells the FA when addresses have been returned by reporting them as revoked (ie returned to the RMA). The FA can then reclaim that or any other address in blocks. Case (d) needs work but looks the best option due to the speed, and avoidance of the RREP reliability issue. In the absence of that, the order of preference is probably c, b, a due to the RREP being a bigger issue than the delay issue. A potential solution to the RREP issue is that if a data flow arrives from an RMA towards an RoA that has no visitor list state, then the FA can temporarily build a visitor list from the arriving data; For Concat, inspect the outer address (MSCoA) which was installed by the RREQ in the FA, to identify the MN address, dynamically build the visitor list state from the data packet contents, and send the data towards that MN encapsulated in the oRoA which is also already known. For nested, decapsulate from the SHCoA, inspect the dest address to see the nRoA, inspect the inner destination address to see the oRoA and identify the MN (the FA knows the MN/oRoA set), build the visitor list state and forward encapsulated within the nRoA so that the MN also learns the nRoA address. For GFA mode, the nRoA is only used for local access traffic and will only arrive once used by the MN. oRoA packets arrive encapsulated in the SHCoA. A.W. O'Neill Expires Oct 2002 [Page 53] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 The MN on receiving packets then can optionally resend the RREQ containing the discovered nRoA to confirm the visitor list state...If the above is acceptable then the effect of the RREP is minimised and RoA assignment delay then becomes the critical issue. This results in a modified preference order of d, a, b, c. 10.19 Proxied HA Update The architecture as described still requires each MN to update each global HA itself with the new RoA on each inter-RMA hand-off. It does so by sending an MIP Registration to that global HA, via the RMA, with the nRoA as the CCoA for the HoA assigned in that HA to the MN. The architecture simply enables these RA layer updates, for multiple HA/HoA pairs, to be once per region rather than once per FA, and to be distributed in time, whilst the MN is in that region, rather than having to be sent immediately as part of the inter- RMA hand-off. This can be improved upon by enabling the oRMA to instead update the HA for the MN. This relies on the MN actively communicating with the oRMA as part of the inter-RMA hand-off. The MN sends either a PRANE to the nRMA which triggers the BU to the oRMA, or it sends a Combined RA/LA message to the oRMA via the nRMA. Both of these messages contain the nRoA that is required to be inserted into the global HAs with which the MN is having a remote access session. Either the BU or the Registration Request can trigger the transfer of the oRMA-MN SAs to the nRMA, protected by the oRMA-nRMA SA. Context Transfer is then used between the oRMA and the nRMA to rapidly move the Remote Access state for all the HA/HoA pairs being employed by the MN, from the oRMA to the nRMA. This includes the oRMA-HA SA that can be used for secure communications with the HA. Alternatively, this HA/HoA state could instead be stored in the local AAA system and fetched directly from there by the nRMA. Either way, the nRMA acquires the SA and the HA/HoA information. Either oRMA or the nRMA are therefore potentially in position to update the global HAs with the new RoA address. The alternative approaches are described below. 10.19.1 oRMA based Proxy HA Update The model is a hierarchical interpretation of Route Optimisation as described in [RouteOpt]. The global HA is sending to the RMA (local HA) and from the perspective of the RMA is a Correspondent Node at the LA layer. When the oRMA is informed of the nRoA then the RMA can send a BU to the HA (containing the HoA, nRoA information) using the existing oRMA-HA SA, requesting the HA to tunnel traffic for the HoA directly to the nRoA. This will cause the oRMA to be bypassed. The Binding Warning Registration extension is used to carry the Warning to the oRMA if the oRMA is the destination of the MIP RA layer RREQ. The oRMA then inspects the oRoA, determines the HoAs for the HAs from local state, and then issues the BUs secured by the oRMA-HA SA. The MN adds the Binding Warning and can therefore use this to decide which HAs get handed off immediately. A.W. O'Neill Expires Oct 2002 [Page 54] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 If the nRMA is instead going to be contacted via an LA layer BU from the nRMA or nFA, then the BU is an explicit indication of an inter-region hand-off which contains the nRoA and so this should cause the oRMA to again issue BUs for all HA/HoA pairs tied to the oRoA, which will be forwarded to the nRoA (or nRMA SHCoA) If in either case the oRMA does not have the HA/HoA state, or simply wishes to wait to see if the RA session is still active, the Binding Update to a specific HA can be triggered by an arriving packet from that HA, addressed to the HoA and encapsulated towards the oRoA. The oRMA can also then dynamically determine the HoA. Irrespective of how the BU is generated, the BUack is mandated following the authentication check and is returned to the oRMA. The global HA in MIP standards does not presently received Binding Updates nor respond to them by redirecting an MIP visitor list entry to the new CoA in the BU. The FA can however presently act like a HA and respond to the BU by forwarding to the reported CoA but this is only allowed because the MN has signed it. In this case, the MN is not directly affected whether or not the BU is processed because in either case the MN receives packets via the nRoA. This is therefore simply a regional optimisation. The HA can be assured that this is true because the message is authenticated by the oRMA-HA, this oRMA has already been trusted for a long while to forward for the HA, and the action of the message is to stop packets going through it, which is hardly the action of an attacker. If a node somehow masquerades as the oRMA then the BUack still goes to the valid oRMA and so the attack is detected and the attacker can give themselves away if they actually include a nRoA in an attempt to capture packets. Essentially, though the chain of trust should be sufficient here between the RMA and the HA. The BU Identification field should be set according to the multitude of ongoing BUs sent between those nodes and independent of any MN-HA identification field for that HoA/HA pair. This is for ordering purposes and replay protection. Now if the BU or BUack fails then the oRMA can resend. If the MN has cancelled the RA session with that HA then the BU will be ignored. If the Registration or BU to the oRMA is lost then they will be resent by the MN. If the HA fails to redirect to the nRMA then packets will continue to arrive at the oRMA which can again trigger resending the BU. 10.19.2 nRMA based Proxy HA update In this case the BU is sent from the nRMA once the Context Transfer of state has occurred from the oRMA. The BU is the same as before but at the HA this is a redirection to a node asking for that redirection which is clearly more dangerous, although it is still secured via a HA-nRMA SA (via CT or AAA). It is also much slower than the oRMA based approach and should therefore only be used if the oRMA has failed to update the HA at that stage. One advantage of the nRMA based approach is that the HA gets to know the nRMA address as well as the nRoA from the BU so that any redirection can be traced whilst the HA only knows the nRoA from the BU when sent by the oRMA. A.W. O'Neill Expires Oct 2002 [Page 55] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 10.19.3 RA session Group HA Hand-off Extension Ideally, either approach would be totally secure if some form of MN-HA SA was used to protect an extension that actually stated that an inter-RMA hand-off was requested by that MN, and the old and new, region names, RMA addresses or RoA addresses as identified in the FAA to the MN. One such approach would be to use a group key as is commonly used in multicast between a single sender and a multicast group. The MN would provide the asymmetric group key to each HA and update it in periodic RA registrations. Asymmetry is required so that a rogue HA cannot pretend to be the MN. On an inter-RMA hand-off, the MN would sign a Group HA Hand-Off extension containing the new and old regions, RMA addresses and RoAs and send it to the oRMA and nRMA in the Registration/BU. Each RMA would then include this extension in the BUs to the HAs which would verify that they are acting on behalf of the MN and would bound the risk depending on the information detailed in the Group HA HO extension. For example, if the extension includes oRoA and nRoA then there is essentially no risk although this can only be sent by the MN once the nRoA is returned to the MN in the RREP, ie after an LA Reg to the nRMA. Therefore first undertaking an LA Reg and subsequently undertaking a proxy HA update via the old or newRMA is preferred. If the extension includes the oRMA/nRMA address then BUs sent from those addresses are safe. If the extension only includes the new region name then the HA has at least had confirmed that an inter-RMA hand-off is required and has good information of where the MN thinks it is going, and can compare it to a region name included by the oRMA/nRMA in its BU, or to historical state in the HA regarding trusted regions. 11. IPv6 Considerations The Nested/Concat model is equally applicable to MIPv6 with the major change being that the MN in IPv6 is able to rapidly acquire a local interface address from each FA. This address can then be used as a MN CCoA for the LA MIP layer to the RMA. The RMA would still allocate the RoA to the MN and the MN would once again use this RoA as a MN CCoA for the RA layer HoA. The remote access layer is therefore unchanged conceptually from the MIPv4 model. The FA in MIPv6 is replaced by a Local Mobility Agent(LMA), and the LMA and RMA could once again cooperate to control and manage local and remote access services in sympathy with the MN privileges and the operator policies. 12. Security and AAA Considerations The security requirements and mechanisms behind all the features within this architecture need significant work and review. However, no major new security issues are raised, by the basic features in this draft, than are already considered in the design of MIPv4, regional tunnelling [RegTun], [RoutOpt] and reverse tunnelling [RevTun]. This is because at all times all information elements are authenticated to the same level as that demanded by existing MIP and AAA exchanges. Some of the new or assumed security mechanisms are highlighted below to help support this analysis. A.W. O'Neill Expires Oct 2002 [Page 56] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 12.1 FA and RMA Auto-configuration The FA can authenticate itself to the local AAA system based on a FA-AAA SA, and then have the AAA system return its regionname, default RMA address, set of associated RMA addresses in the region, the FA-NAI and the RMA-FA key material for those SAs. Similarly, each RMA has an RMA_AAA SA and can obtain its regionname, role (default or associated), the set of region RMAs, the set of region FAs, and the key material for the RMA-RMA and RMA-FA SAs. The RMA- NAI could be for example the 'regionnameandnumber@domain'. The FA and RMA must share a Security Association (SA) to protect FA-RMA extensions and specifically to enable the FA to dynamically assign the FA CoA and forward it to the RMA using the HFAext. This SA can be pre-configured, distributed and maintained through IKE/IPSEC (or other such system), or managed and distributed through MIP mechanisms from the RMAs in a region. 12.2 AAA Key Material Distribution The AAA system can be used for initiation of the MN-FA, MN-RMA, MN-HA, FA-RMA and RMA-HA SAs. These are used for the authentication extensions, to authenticate MIP messages and contained extensions between MIP nodes. Local AAA mechanisms already exist to configure MN-FA, FA-RMA and MN-RMA SAs for dynamic RMA assignment where the RMA is a local HA, and the AAA request is sent from the FA triggered by the LA RREQ. The FA-RMA can also be pre- configured as discussed in 13.1. Any RMA dynamically assigned by the FA must be communicated to the AAA system, for example using the equivalent of the HA-NAI, so that it can configure the RMA with the required key material for RMA-MN and RMA-FA (if not also preconfigured). For incremental deployment, this draft also considers an additional capability whereby the RMA key material can instead be delivered by the AAA system to the FA, and then forwarded to the RMA in an undefined extension protected by the pre-existing FA-RMA SA.The global AAA system is in many cases already able to dynamically assign a global HA and HoA and provide the required MN-HA and FA-HA. RegTun extends this to enable an intermediate GFA to be supported. The missing piece however is to enable the AAA system to first assign the LA elements from the LA Reg and then to assign the missing elements for the RA Reg. In addition, a Combined RA/LA Reg should be able to create all the required SAs together in a co-ordinated manner to enable efficient configuration in a single AAAH-AAAF round trip, and to also avoid duplication for key material by sharing MN-FA and FA-RMA between the two MIP layers. Additional RA layer signalling should then only trigger the AAA system via the FA, to provide the additional session specific HA/HoA parameters along with material to generate new MN-HA and RMA-HA SAs. The AAA system must in addition be able to deliver the MN-HA and RMA-HA generation material to the RMA and HA either through Diameter AAA routing or via additional RADIUS look-ups at the RMA and HA when incoming Registrations are received that demand such action as a result of a missing SA. These activities are improved through the use of HA-NAI and AAA-NAI as discussed in [AAA-NAI]. If the AAA system cannot support RMA-MN and MN-RMA key material distribution, then in the case of the FA and RMA sharing a pre-configured association it is possible that the FA can act as a security server and use a MN-FA SA obtained through MN authentication, and the FA-RMA SA to mutually configure the MN-RMA SAs. A.W. O'Neill Expires Oct 2002 [Page 57] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 12.3 Inter-operator PRANE There is a slight concern with the inter-RMA inter-operator BU, that is triggered by the PRANE and which has a zero nRMA CoA. This is because this is generally not known until the nRMA is traversed. The MN calculation of the authenticator is then still based on the oRMA-MN auth SA but does not authenticate the missing RMA CoA. The assigned nRMA CoA is instead protected by an inter-RMA SA and inserted in a HFAext to the oRMA. However, the MN is still specifically stating that it is undertaking an inter-operator hand-off in the BU, the oRMA can see that it was directed via a specific RMA and any vulnerability is only for the duration of the transient forwarding. 12.4 Forwarding Checks The GFA model seeks tight checks on the previous hop when packets are tunnelled from the HA to the GFA and onto the MN. This is to ensure packets are not falsely injected towards the HoA by a rogue element which either does not know the HA or GFA address, or cannot use them because of ingress filtering of source addresses. In the Nested Model and Concat models, significant effort is made to avoid HA/HoA specific state in the FA but this reduces the granularity of any check. In the Nested case, the MN still sees the originating HA and so can meet the requirements but only after the air- link has been traversed. It can also however rely on the RMA undertaking this check by keeping HA specific state or even HoA specific state. Concat mode again relies on a chain of trust with the FA having only MSCoA state and relying on the RMA to check the RoA destination address and to map the flow to the correct MSCoA. The MN cannot see the originating HA address and so the RMA HA state to match the HA and RoA to registrations appears more critical here although the fact that a registered RoA is used maybe sufficient and hence we can avoid HA specific state in the RMA for basic Concat forwarding. However, saying all that it is also apparent that a MN that also has local access is open to traffic from a range of CNs and so maybe the need for tight source checking is less pronounced if we can assume correct ingress filtering is in place. In the reverse tunnelling case, the source checking is required to avoid packets being injected into a private domain via the GFA and HA. This again requires a chain of trust but in both the Nested and Concat modes the RA reverse tunnel is from the RoA direct to the HA which significantly reduces any threats. If the LA reverse tunnel is also used then packets are routed first to the RMA where 13. 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). A.W. O'Neill Expires Oct 2002 [Page 58] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 14. Acknowledgements George Tsirtsis of Flarion Technologies undertook detailed reviews of this document. 15. 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," Internet-draft, draft-ietf-oneill-mip- nested-00.txt, April 2002. [PCCoA] A.W. O'Neill, ``Proxy CCoA Tunnelling for Mobile IP," Internet-draft, draft-oneill-mip-proxyCCoA-00.txt, May 2002. [MIPv4] C.E. Perkins, Ed., "IP Mobility Support for IPv4," RFC3220, Jan 2002. [RegTun] E. Gustafsson. Ed., " Mobile IPv4 Regional Registration, Internet-draft, draft-ietf-mobileip-reg-tunnel-06.txt, 1March 2002 [RegTunMods] A. O'Neill, "Modifications to Regional Tunnelling", Internet- draft, draft-oneill-mip-regtun-mods-00.txt, 9 April 2002. [RevTun] G. Montenegro, Ed., "Reverse Tunnelling for Mobile IP, revised," Internet RFC 3024, January 2001. [RevTunMods] A. O'Neill, "Hand-off Extensions for Reverse Tunnelling", Internet-draft, draft-oneill-mip-revtun-ho-00.txt, 22 Feb 2002. [NestMIP] A. O'Neill, "Nested MIP for IP Mobility Management", Internet Draft, draft-oneill-mip-nested-00.txt, May 2002. [ConcatMIP] A. O'Neill, "Concatenated MIP for IP Mobility Management", Internet Draft, draft-oneill-mip-concat-00.txt, May 2002. [RMAsig] A. O'Neill, "Regional Mobility Agent Signalling", Internet-draft, draft-oneill-mip-rmasig-00.txt, May. [MIPAAA] Charles E. Perkins, Pat R. Calhoun, "AAA Registration Keys for Mobile IP", draft-ietf-mobileip-aaa-key-09.txt, 26 February 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. [AAANAI] T. Johansson, F. Johansson, 'AAA NAI for Mobile IPv4 Extension', Internet Draft, draft-johansson-mip-aaa-nai-01.txt, 09-Apr-02. A.W. O'Neill Expires Oct 2002 [Page 59] INTERNET-DRAFT Regional Mobility Agent Signalling May 2002 Author's Addresses Alan O'Neill Flarion Technologies Phone: +1 908 947 7033 Email: oneill@flarion.com