idnits 2.17.1 draft-oneill-handoff-state-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 297 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 84 has weird spacing: '...loading the h...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2001) is 8471 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Personal A. O'Neill 2 G. Tsirtsis 3 BT 4 Internet Draft S. Corson 5 Document: draft-oneill-handoff-state-00.txt Ansible Systems 6 Category: Informational August 2000 8 Expires : February 2001 10 State transfer between Access Routes during Handoff 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This draft aims to document an issue raised in the Mobile IP working 35 group related to fast handoff between Access Routers. The fast 36 handoff work aims to rapidly enable IP service at the new access 37 router. In Mobile IP this implies that Binding Updates at the 38 network layer enable forwarding of packets to the new access router. 39 However, it may also imply other network layer activities because 40 the IP service given to the MN may depend on state which is 41 presently located in the old access router. This draft aims to 42 document the issue through examples so that the IETF can resolve how 43 to approach this issue. 45 INDEX 47 1. Introduction 48 2. State Examples 49 3. Conclusion 51 O'Neill, Corson, Tsirtsis 1 52 1. Introduction 54 This draft aims to document an issue raised in the Mobile IP working 55 group related to fast handoff between Access Routers. The fast 56 handoff work aims to rapidly enable IP service at the new access 57 router. In Mobile IP this implies that Binding Updates at the 58 network layer enable forwarding of packets to the new access router 59 (NAR). However, it may also imply other network layer activities 60 because the IP service given to the MN may depend on state which is 61 presently located in the old access router (OAR). This draft aims to 62 document the issue through examples so that the IETF can resolve how 63 to approach this issue. 65 In many cases it may be perfectly acceptable for a MN to simply 66 restart its sessions/protocols after handoff. However, a number of 67 specific protocols that directly affect application performance will 68 need to be maintained by immediately transferring the associated 69 state to the new AR (seamless handoff). There are then a number of 70 ways in which this could be achieved: 72 a) the transfer may be possible using the protocol responsible for 73 the state (eg RSVP updates the Int-serv state) 74 b) the state could be transferred by the handoff protocol such as 75 Mobile IP 76 c) the state could be initialised by the MN using a tunnel to the 77 NAR via the old link before handoff. 78 d) a specialised protocol(s) could be designed to transmit the 79 state. 81 In many cases the protocol responsible for the state may not be 82 suitable for a number of reasons (end-points, reliability, speed, 83 security models etc). Using the handoff protocol seems poor because 84 of the risk of loading the handoff protocol messages with 85 significant data, and the handoff protocol designers would unlikely 86 be experts in the protocol state to transfer. On the other hand it 87 is clear that the handoff messages need to act as a trigger for the 88 transfer so that it is timely. In addition, the handoff/mobility 89 protocol can assist in securing the transfer given the essential 90 security association that needs to be in place to secure the 91 handoff. Finally, there may well be state which is essential to the 92 correct and timely configuration of the new link which should 93 probably be included in the handoff messaging. 95 In the case of MN initiated handoff, the MN may have the opportunity 96 to tunnel to the NAR and have sufficient time to initialise the 97 required state at the NAR for the new link before handoff. The model 98 implies that the MN sends the handoff request via the old link and 99 receives a response over either link. The MN sends IGMP, RSVP etc 100 updates in advance of the move over the tunnel to install the state 101 in the NAR. This also enables the MN to investigate the service 102 capabilities at a NAR before finally moving and could be used to 104 O'Neill, Corson, Tsirtsis 2 105 select from multiple NAR options. The clear problem with this 106 approach though is that the timers associated with such protocols 107 may be too large for seamless handoff to be possible in specific 108 cellular systems for example. 110 Therefore, a special meeting of the handoff draft authors 111 recommended that the design and utilization of a specialised inter- 112 AR handoff data transfer protocol may therefore be required. The 113 timing of such transfers, should be triggered by the handoff 114 signalling and the requested protocol elements could be configured 115 by the MN, and constrained by the network, to meet their respective 116 needs. The benefits and consequences of these data transfers on user 117 performance is unclear as it will not be possible to instantaneously 118 install and synchronize this protocol state. 120 Prior negotiation of handoff-related capabilities between adjacent 121 handoff neighboring access routers can significantly reduce the 122 latency of such transfers (e.g. having pre-established security 123 associations between handoff peer ARs). This would require a second 124 protocol (occurring in the background) enabling inter-AR capability 125 exchange. 127 The next section provides a list of example protocol state that 128 might be transferred which is by no means exhaustive. 130 2.1 Compressor State 132 Header compression over the radio link necessarily implies 133 synchronised state in the MN and AR. Movement to a new AR would then 134 require a return to uncompressed headers to build the compressor 135 state at the NAR which may affect seamlessness. The alternative 136 would be to forward the compressor state from the OAR to the NAR 137 during handoff. 139 2.2 IGMP 141 IP multicast uses a group membership protocol which interacts with 142 multicast routing to maintain the multicast tree. The IGMP messaging 143 and associated multicast routing may not be sufficiently fast to 144 provide seamless handoff of multicast applications. One way to speed 145 this up would be to transfer IGMP and FIB state to the new AR and to 146 immediately trigger core multicast routing updates. Checks need to 147 be made on the multicast group scope and to deal with multi-homing 148 and diversity (bicasting etc) during handoff. 150 2.3 Diff-serv 152 Diff-serv aims to provide useful services to a MN through the 153 marking, and differentiated treatment of IP packets in routers. 154 Diff-serv places the onus on the network to police, account, and 155 potentially mark incoming and outgoing diff-serv packets according 156 to a diff-serv profile. This profile and the above data is typically 158 O'Neill, Corson, Tsirtsis 3 159 located in the Access Router at the border of the domain although 160 diff-serv marking can be undertaken by the MN. This profile will 161 typically be delivered by a QoS policy or signalling protocol such 162 as COPS, RAP or RSVP, or may in addition by delivered through the 163 AAA process. 165 Seamless handoff may require the policer and marker profile to be 166 transferred across to protect network resources, other users 167 traffic, and to correctly mark the traffic of this user. It may also 168 be required to transfer dynamic diff-serv state (policer/meter) to 169 avoid transients in the users QoS or network usage. 171 2.4 Int-serv 173 Integrated Services uses RSVP signalling to install specific per 174 user state (which can be aggregated in specific cases) on the routed 175 path from a traffic source towards that user. Each RSVP router has 176 parameters installed which enable it to recognise and treat the 177 packets of the user according to the requested service profile. The 178 OAR which is on the path for both the received and sourced user 179 traffic may therefore have Int-serv and RSVP data which needs to 180 transferred across to the NAR. The soft-state nature of RSVP enables 181 the host to instead potentially refresh the state at the NAR up to 182 the cross-over router which is on the path to both OAR and NAR and 183 would be required to be triggered by the handoff. Alternatively, the 184 RSVP state could be immediately transferred across and then simply 185 refreshed as normal by the MN RSVP state machine. In the case of 186 both RSVP and diff-serv it is also clear that the MN could use a 187 third model in which the MN includes the QoS profile in the handoff 188 request so that the network can constrain subsequent handoff hints 189 to NARs that can meet that QoS profile. 191 2.5 AAA 193 The AAA profile is typically returned to the AR following exhaustive 194 and secure AAA processes. These processes may be fully invoked on 195 session start-up but should be minimized during handoff. One way to 196 minimize is to transfer specific state between the OAR and NAR where 197 the two share a security association, and the AAA parameters are 198 agnostic to the specific AR. It would therefore be expected that 199 session keys, accounting profile and dynamic firewall configuration 200 should be transferred across. 202 2.6 IPSEC Gateway State 204 In the case of network based security, where the ISP locates an 205 IPSEC gateway at the AR, then the security state in the gateway must 206 move to the NAR so that packets can be correctly authenticated, 207 rejected and decrypted for the user. In addition, this movement is 208 also required to ensure that outgoing packets are correctly 209 processed. The timescales associated with renegotiation of security 210 parameters using IKE would be too large to achieve seamless handoff 211 and secure SA transfer may be possible. 213 O'Neill, Corson, Tsirtsis 4 214 2.7 Non Network layer State 216 It is assumed for the purposes of this draft that higher state would 217 not be located in the OAR and would not be required to be 218 transferred for seamless handoff. 220 3. Conclusion 222 There appears to be additional work required at the network layer 223 for seamless handoff that is probably out of scope of the Mobile IP 224 working group. The chairs have requested input on this issue from 225 the working group and the consensus view of the handoff team is that 226 this may be a suitable task for another working group, with the 227 support of the working groups responsible for the specific protocol 228 state which is deemed to be important for seamless handoff. 230 The implications of this issue may well be that specific state needs 231 to migrate to to the MN instead of existing in stateful access 232 routers. This implies adoption of the SIM model from the cellular 233 world, where mobile internet devices have secure and 234 hardware/software into which user specific network state can be 235 delivered and maintained during handoff. 237 Author's Addresses 239 Alan O'Neill 240 BT 241 (+44) 1473-646459 242 alan.w.oneill@bt.com 244 M. Scott Corson 245 University of Maryland 246 Ansible Systems 247 (+1) 301-405-6630 248 corson@isr.umd.edu 250 George Tsirtsis 251 BT 252 (+44) 020 88260073 253 george.tsirtsis@bt.com 254 gtsirt@hotmail.com 256 Copyright Notice 258 Placeholder for ISOC copyright. 260 O'Neill, Corson, Tsirtsis 5