idnits 2.17.00 (12 Aug 2021) /tmp/idnits61693/draft-berzin-malis-mpls-mobility-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2243. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 30, 2007) is 5317 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Berzin 3 Internet-Draft A. Malis 4 Expires: May 2, 2008 Verizon Communications 5 October 30, 2007 7 Mobility Support Using MPLS and MP-BGP Signaling 8 draft-berzin-malis-mpls-mobility-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 2, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes a new approach to handling user mobility at 42 the network layer in the context of Multiprotocol Label Switched 43 Networks (MPLS). This approach does not rely on the existing IP 44 mobility management protocols such as Mobile IP, and is instead based 45 on the combination of Multiprotocol BGP (MP-BGP) and MPLS. This 46 document proposes to introduce new protocol elements to MP-BGP to 47 achieve Mobility Label distribution at the network control plane and 48 the optimal packet delivery to the mobile node by the network 49 forwarding plane using MPLS. 51 Table of Contents 53 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1. Architecture Requirements . . . . . . . . . . . . . . . . 6 56 2.2. Existing Solutions . . . . . . . . . . . . . . . . . . . . 6 57 2.2.1. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 6 58 2.2.2. Mobile IPv6/HMIP/NEMO . . . . . . . . . . . . . . . . 7 59 2.2.3. MPLS Micro-Mobility . . . . . . . . . . . . . . . . . 7 60 2.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 61 2.4. Architecture Overview . . . . . . . . . . . . . . . . . . 8 62 2.4.1. Node Roles . . . . . . . . . . . . . . . . . . . . . . 9 63 2.4.2. Attachment Options . . . . . . . . . . . . . . . . . . 10 64 2.4.3. Network Hierarchy . . . . . . . . . . . . . . . . . . 13 65 2.4.4. Interface to Other Networks . . . . . . . . . . . . . 13 66 3. Mobility Support Function . . . . . . . . . . . . . . . . . . 15 67 3.1. Mobile Node Discovery, Registration and Status . . . . . . 15 68 3.1.1. Discovery Process - IPv4 . . . . . . . . . . . . . . . 15 69 3.1.1.1. MSF Discovery by Mobile Hosts - IPv4 . . . . . . . 17 70 3.1.1.2. MSF Discovery by Mobile Routers - IPv4 . . . . . . 18 71 3.1.1.3. MSF Advertisement - IPv4 . . . . . . . . . . . . . 18 72 3.1.2. Discovery Process - IPv6 . . . . . . . . . . . . . . . 20 73 3.1.2.1. MSF Discovery by Mobile Hosts - IPv6 . . . . . . . 22 74 3.1.2.2. MSF Discovery by Mobile Routers - IPv6 . . . . . . 22 75 3.1.2.3. MSF Advertisement - IPv6 . . . . . . . . . . . . . 22 76 3.1.3. Registration and Status - IPv4 . . . . . . . . . . . . 22 77 3.1.3.1. Mobile Host Registration - IPv4 . . . . . . . . . 22 78 3.1.3.1.1. Lightweight Registration - IPv4 . . . . . . . 22 79 3.1.3.1.2. Full Registration - IPv4 . . . . . . . . . . . 23 80 3.1.3.1.3. Group Registration - IPv4 . . . . . . . . . . 25 81 3.1.3.2. Mobile Router Registration - IPv4 . . . . . . . . 29 82 3.1.3.2.1. Routing Adjacency Establishment . . . . . . . 29 83 3.1.4. Registration and Status - IPv6 . . . . . . . . . . . . 30 84 3.2. Integration with MP-BGP . . . . . . . . . . . . . . . . . 30 85 3.2.1. Mobility Address Family . . . . . . . . . . . . . . . 30 86 3.2.2. Mobility Bindings . . . . . . . . . . . . . . . . . . 32 87 3.2.3. Group Registration Management with MP-BGP . . . . . . 34 88 3.2.4. BGP Capability Advertisement . . . . . . . . . . . . . 37 89 3.3. Mobile Application Priority Indication and Recognition . . 37 90 3.4. Application Service Type Indication . . . . . . . . . . . 38 91 4. Network Update and Hand-off Processing . . . . . . . . . . . . 39 92 4.1. Network Update Modes . . . . . . . . . . . . . . . . . . . 39 93 4.1.1. Unsolicited Downstream Push . . . . . . . . . . . . . 39 94 4.1.2. Selective Downstream Push . . . . . . . . . . . . . . 39 95 4.1.3. Predictive Downstream Push . . . . . . . . . . . . . . 39 96 4.1.4. Hierarchical On-Demand Distribution . . . . . . . . . 40 97 4.1.4.1. On-Demand Requests for Mobility Binding 98 Information . . . . . . . . . . . . . . . . . . . 40 99 4.1.5. Network Hierarchy Considerations . . . . . . . . . . . 43 100 4.1.6. Regionalization and Scalability . . . . . . . . . . . 43 101 4.1.6.1. Mobility Information Location System (MILS) . . . 44 102 4.2. Hand-off Processing . . . . . . . . . . . . . . . . . . . 46 103 4.3. Micro-Mobility Handling . . . . . . . . . . . . . . . . . 47 104 4.3.1. Local Micro-Mobility . . . . . . . . . . . . . . . . . 47 105 4.3.2. Group Micro-Mobility . . . . . . . . . . . . . . . . . 47 106 5. Datagram Delivery . . . . . . . . . . . . . . . . . . . . . . 49 107 6. Security Considerations . . . . . . . . . . . . . . . . . . . 50 108 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 109 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 110 9. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 53 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 112 10.1. Normative References . . . . . . . . . . . . . . . . . . . 54 113 10.2. Informative References . . . . . . . . . . . . . . . . . . 54 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 115 Intellectual Property and Copyright Statements . . . . . . . . . . 57 117 1. Requirements notation 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. Introduction 125 The requirements to support user mobility range from the physical 126 aspects of wireless access networks to the logical aspects of the 127 network control and forwarding plane operation. In the context of 128 this work the main requirement for the mobility support architecture 129 is to decouple the network layer addressing and the associated 130 logical network topology from the ability of the network to optimally 131 deliver the packets to the mobile user. The optimal traffic delivery 132 is interpreted as the delivery of packets to the new node location 133 following the best (often the shortest in terms of the routing 134 protocol metrics) path between the mobile node and the correspondent 135 node. 137 The issue is that this optimal path cannot be used by the network to 138 communicate with the mobile user based on the IP address and routing 139 protocols. This is due to the inability of a conventional IP network 140 to react to the mobile user movements by adjusting the routing and 141 forwarding information in the network nodes (routers) to reflect the 142 new location of the mobile user with respect to the IP topology. 144 Thus a method is required to identify the logical location of the 145 user in the network topology in such a manner that the traffic 146 delivery to the user at a new location follows the optimal path in 147 the context of the routing protocol used in the network. A natural 148 fit to provide this method is the MPLS architecture. MPLS does not 149 perform the forwarding of IP traffic based on the IP addresses and 150 uses labels instead. The important point, however, is that MPLS by 151 itself cannot solve the mobility problem as ultimately the traffic 152 must originate from the source IP address and terminate at the 153 destination IP address (which would still be the old home address). 154 In order to use MPLS to forward the traffic to the new user location 155 along the optimal path the labels must be assigned specifically to 156 the mobile node at the new location and distributed to the network 157 nodes. These special labels are referred to as Mobility Labels and 158 are associated (bound) to the mobile node IP address. 160 This document proposes to use the Mobility Label as a second label in 161 the MPLS label stack. The first label in the stack is the one that 162 identifies the LSP (Label Switched Path) between the two Label Edge 163 Routers and the second label in the stack can be used to identify the 164 IP address of the mobile node and deliver the traffic to it. The 165 assignment and the distribution of the first label in the stack is 166 handled by the conventional MPLS architecture elements and protocols 167 such as LDP (Label Distribution Protocol [RFC5036]). It is proposed 168 that the assignment and distribution of the second label - the 169 Mobility Label - be based on the existing framework of MP-BGP 170 (Multiprotocol Border Gateway Protocol [RFC4760]). The mobility 171 management scheme based on MP-BGP at the control plane level and MPLS 172 at the forwarding plane level represents a system in which both the 173 control and forwarding processes are integrated to ensure the optimal 174 traffic delivery that is not fully achieved in the existing network 175 layer mobility management approaches. 177 2.1. Architecture Requirements 179 Integrated control and forwarding plane - the network update process 180 by the Control Plane must result in the optimal traffic delivery by 181 the Forwarding Plane. 183 Robust and flexible protocol framework - the Mobility Management 184 Control Plane Protocol and the associated functions must be placed at 185 the intelligent network edges and allow to avoid the need to involve 186 all nodes in the network (including the core nodes) in the network 187 update process. 189 The Mobility Management Control Plane Protocol must allow for 190 flexible and seamless introduction of new features and for support 191 for Mobile Hosts and Mobile Routers. 193 Evolutionary architecture and implementation approach - the Mobility 194 Management scheme should be based as much as possible on the existing 195 network architectures and protocol framework. Only minimal changes 196 to the operation of mobile nodes should be expected. 198 Efficient network responsiveness - the impact on the mobile 199 application due to the service disruption caused by the mobile node's 200 movements and the associated network update and delivery processes 201 should be reasonably minimal. 203 Acceptable network scalability and performance - the new requirements 204 for Mobility Management functions should not result in decreased 205 network scalability and performance. 207 2.2. Existing Solutions 209 2.2.1. Mobile IP 211 Mobile IP [RFC3344] was developed to provide macro mobility 212 management for the mobile hosts using IP version 4 (IPv4). It was 213 subsequently extended to support IPv6. Due to its complete reliance 214 on the logical network topology determined by the distribution of the 215 IP subnets Mobile IP solves the mobility problem by using the 216 following two major techniques: mobile node registration and traffic 217 tunneling. The main entities in Mobile IP are the Mobile Node (MN) 218 itself, the Correspondent Node (CN) - the host that is communicating 219 with the MN, the Home Agent (HA) - this is the router that owns the 220 original home subnet to which the MN is assigned, the Foreign Agent 221 (FA) - this is the router that owns the subnet to which the MN has 222 moved (the foreign subnet), and finally the Care-of-Address (CoA) - 223 the IP address that belongs to the FA and that is used to represent 224 the MN while it is located in the foreign subnet. The basic mobility 225 handling by Mobile IP results in a sub-optimal forwarding path in the 226 direction of traffic from the CN to the new location of the MN. This 227 is because the traffic is first sent to the HA and then tunneled to 228 the FA/MN. Although the route optimization scheme exists where the 229 mobility bindings are sent by the HA directly to the CN with the CoA 230 of the MN for direct traffic forwarding, it requires the CN to i) 231 implement the binding processing and ii) use IP tunneling to send 232 packets to the MN. 234 2.2.2. Mobile IPv6/HMIP/NEMO 236 Mobile IPv6 [RFC3775] provides macro-mobility support for IPv6. It 237 improves Mobile IPv4 by eliminating the need for the FA, use of the 238 IPv6 neighbor discovery instead of ARP, use of the IPv6 Link Local 239 (LLOC) address instead of CoA. It also provides basic support for 240 mobile routers via NEMO (Network Mobility) [RFC3963] and enables 241 hierarchical mobility management (HMIP). However MIPv6 does not 242 provide for the integration of the control and forwarding planes and 243 still requires the use of the HA which results in sub-optimal traffic 244 routing. The routing optimization based on the direct binding 245 exchange between the CN and the MN resolves the sub-optimal routing 246 but introduces the requirement for the return routability procedure 247 and the use of a special IPv6 routing header (similar in function to 248 IPv4 tunneling) directly on the CN and MN. In addition, Hierarchical 249 MIPv6 requires registrations to multiple entities (MAP - Mobility 250 Anchor Point, HA) and supports IPv6 only. 252 2.2.3. MPLS Micro-Mobility 254 MPLS Micro-Mobility [MM-MPLS] integrates MIP and MPLS traffic 255 forwarding to provide a solution in which MIP is used for macro 256 mobility management and MPLS is used to support micro-mobility. 257 Micro-mobility reflects the mobile host movements that can be handled 258 without the re-registration with the MIP HA. To achieve this, the MN 259 registers with a hierarchical set of Label Edge Mobility Agents 260 (LEMA). The LEMA at the top of the hierarchical set is registered 261 with the MIP HA as the FA for the MN. The MIP HA tunnels all packets 262 from the CN to the MN to the top level LEMA as in regular MIP. The 263 LEMA then sends packets on the MPLS LSP to the network location of 264 the MN using MPLS labels. As the MN moves to new locations, the 265 hand-off procedures are invoked that start with the MN requesting the 266 hand-off and the LEMA(s) performing the set of signaling steps 267 resulting in the redirection of the MPLS LSP from the old serving 268 LEMA to the new serving LEMA. If the MN movement results in a 269 condition in which the old top level LEMA can no longer serve the MN, 270 the MN re-registers with the new hierarchical set of LEMA(s) and the 271 top level LEMA is registered as the FA with the Mobile IP HA. 272 Although MPLS Micro-Mobility makes use of the MPLS traffic forwarding 273 it still is an extension of Mobile IP and therefore does not result 274 in the elimination of triangular routing. 276 2.3. Protocol Overview 278 MP-BGP and its ability to carry the overlay MPLS label information 279 [RFC3107] is proposed for the mobility management. Namely when the 280 mobile hosts or routers change their network locations they can 281 register with the edge nodes of the MPLS network (LER) and at that 282 time assigned Mobility Labels. The Mobility Labels in turn are 283 associated with the IP addresses of mobile hosts or routers thus 284 forming the Mobility Bindings. These Mobility Bindings are then 285 encoded in the Multiprotocol BGP Address Family messaging structure 286 and are distributed among the rest of the MPLS network LER nodes 287 using the MP-BGP protocol. The Mobility Binding provides an explicit 288 association between the overlay MPLS label and a single or multiple 289 individual IP addresses of mobile hosts or IP address ranges 290 (prefixes) that are served by mobile routers. The MP-BGP NEXT_HOP 291 attribute associated with the BGP UPDATE message [RFC4271] used to 292 carry the Mobility Binding provides an implicit association between 293 the overlay Mobility Label and the infrastructure MPLS label that is 294 in turn associated with the LSP to reach the LER that sourced the 295 Mobility Binding. The MPLS LER capability to provide mobility 296 support can be referred to as the Mobility Support Function (MSF) 297 (see Section 3). The MSF includes: a) Mobile Host/Router Discovery, 298 Registration and Status Procedures, b) Mobility Label Association and 299 de-Association Procedures, c) Integration with MP- BGP and d) Mobile 300 Application Priority Indication and Recognition. 302 2.4. Architecture Overview 304 This mobility architecture is proposed in the context of MPLS 305 networks. As such it is a requirement of this architecture that all 306 nodes in the network support MPLS control and forwarding plane 307 procedures and in particular it is a further requirement that the 308 edge nodes of the MPLS network implement the Mobility Support 309 Function described in Section 3. This architecture does not rely on 310 Mobile IP for macro-mobility support. In other words there is no 311 concept of a home network that the mobile node belongs to and 312 therefore there is no requirement to register with the Home Agent. 313 It is the assumption of this architecture that a mobile host or 314 router is always identified as being in the foreign network thus 315 always requiring mobility support. In addition, there is no 316 requirement for the CoA. 318 The simplest way to implement this assumption is to administratively 319 allocate a range of IP addresses for all mobile hosts and routers of 320 an organization and to implement in the MSF the configurable ability 321 to recognize the pre-allocated mobility address ranges. As such, a 322 service provider would assign IP addresses to all of their mobile 323 subscribers from a pre-allocated address range. This range does not 324 have to be flat and can be in turn subnetted. The IPv4 or IPv6 325 mobility address pre-allocation scheme allows utilization of this 326 mobility management architecture as a separate overlay MPLS service. 327 The only requirement related to the LER MSF pre-configuration is the 328 static identification of the overall mobility address range in the 329 scope of the LER-wide MSF. 331 Regardless of the static identification of the overall address range 332 allocated to the mobile devices, the individual mobile nodes identify 333 themselves dynamically to the MSF. This capability is especially 334 useful when this architecture is applied to provide mobility support 335 to both mobile hosts and routers. Specifically, during the 336 registration procedure a mobile node could identify itself as either 337 a mobile host or a mobile router. If it is a mobile router the MSF 338 is expected to establish a routing protocol adjacency with the mobile 339 router as well as to utilize an extended Mobility Binding structure 340 in which multiple IP prefixes served by the mobile router may be sent 341 in a single Mobility Binding optionally associated with a single 342 Mobility Label. 344 The mobile node must always register with the serving MSF and thus be 345 associated with the Mobility Label. This requirement will support 346 the ability to implement specific mobility features such as the 347 application sensitivity recognition via the processing prioritization 348 scheme. 350 2.4.1. Node Roles 352 From the network architecture perspective the proposed mobility 353 solution follows the classical MPLS network architecture with two 354 major node classes: LSR and LER also known as P and PE respectively. 355 The LER (PE) nodes reside at the edges of the network and perform the 356 corresponding edge functions such as the customer interface 357 management, label stack imposition/deposition and label information 358 distribution for both the infrastructure MPLS transport and the 359 overlay MPLS services. In addition to these edge functions we 360 introduce the Mobility Support Function that integrates directly with 361 the LER control plane responsible for the overlay MPLS services. The 362 role of the LSR (P) nodes remains exactly the same as in the 363 classical MPLS architecture - participate in the infrastructure label 364 distribution process and switch traffic based on the MPLS labels 365 (outer labels) between the LER nodes. The LSR (P) nodes need not 366 implement the MSF. Other aspects of the architecture include the 367 access interface, the interface to other networks and the network 368 hierarchy. 370 2.4.2. Attachment Options 372 The two major access interface options considered here are: Direct 373 Attachment of the LER node to the Radio Access Network and Indirect 374 Attachment of the LER node to the Radio Access Network. The terms 375 direct and indirect are not used to indicate that the LER node has or 376 does not have the integrated wireless radio interface. The term 377 direct is used to reflect that a direct layer 2 path exists between 378 the mobile node and the MSF enabled LER either via the integrated 379 radio interface or via the wireline grooming network to the wireline 380 side of the Radio Access Network Base Stations. The term Indirect is 381 used to reflect that there is no direct layer 2 path between the 382 Radio Access Network and the MSF enabled LER node. The Indirect 383 Attachment means that there is another layer 3 device (such as the 384 Customer Edge - CE router in the MPLS Architecture terminology) 385 between the MSF enabled LER and the Radio Access Network. The CE 386 router in turn connects to the Radio Network via Direct Attachment 387 (in the sense of the term defined here) by using the integrated 388 wireless interface or by using the wireline grooming network. The 389 reason for establishing these two access options relates to the type 390 of service environments that the proposed architecture will most 391 likely be applicable to. 393 The Direct Attachment option is most suitable for the use case where 394 mobility is offered as an overlay service in a service provider's 395 mobility enabled MPLS network. In this case the Mobility Support 396 Function may be viewed as one of the functions in the MPLS for Mobile 397 Networks Architecture. An example of such a use case is the Wireless 398 Telephone service with data or multimedia capabilities (such as 399 EV-DO) in which mobility management is handled by the MSF enabled 400 MPLS network. The mobile nodes may be the wireless telephone sets 401 with IPv4 or IPv6 stacks and the corresponding mobility addresses 402 assigned by the service provider, communicating via the Radio Access 403 Network Base Stations to the MSF enabled LER nodes. A simple 404 registration procedure triggers the assignment of the overlay 405 Mobility Labels and the subsequent mobility management by MP-BGP. 407 The Indirect Attachment option is most suitable when the mobility 408 service is integrated with other overlay MPLS services such as Layer 409 3 VPN [RFC4364]. This use case is applicable for the enterprise 410 networking where the mobile nodes can be the wireless workstations or 411 wireless IP telephones, and the enterprise sites connecting to the 412 service provider's mobility enabled MPLS network via the CE routers. 413 The simplest way to accommodate the presence of the CE routers is to 414 implement the MSF function on the CE router and use the MP-BGP and 415 Mobility Labels between the CE router and the LER (PE) router in the 416 context of the customer specific MPLS VPN. This also implies the use 417 of MPLS and MP-BGP between the CE and PE routers for the delivery of 418 traffic to the mobile nodes behind the CE router, but since there 419 will be no LSR (P) routers between the MSF enabled CE and the PE 420 router there is actually no need for the outer stack MPLS labels and 421 therefore no need to integrate the CE routers with the service 422 provider's MPLS infrastructure. The MPLS LER (PE) router will need 423 to accept the Mobility Binding information via the use of MP-BGP from 424 the CE router within the MPLS VPN and then propagate that information 425 into the MPLS network using the L3 VPN MPLS overlay service also 426 based on MP-BGP. 428 The direct attachment option is shown in Fig.1, where a MSF enabled 429 LER node interfaces with multiple Radio Cells or Cell Clusters via 430 the L2 network such as Ethernet. Each Radio Cell Cluster is assigned 431 into a L2 Virtual LAN and associated with a L3 subnet that is 432 terminated at a logical interface of the LER node. The logical 433 interfaces are controlled by the MSF and the associated set of Radio 434 Cells or Clusters forms a Mobility Region. 436 In Fig. 2 a similar arrangement is illustrated but in this case there 437 is no direct L2 path between the Radio Access Network and the MPLS 438 edge. A CE router provides the MSF and communicates the Mobility 439 Binding information by means of MP-BGP to the MPLS LER (PE) router. 441 +-----+ 442 |MSF ++-----------+ +------------+ 443 Radio Cell +----++ | | | 444 ,-----. | LER ........MPLS Network 445 / \ | | | | 446 / ((++)) \ +--+-+-++-+-++ +------------+ 447 ( || ) L3 Logical Interfaces 448 ,----+. +`-._/ / / / / / / 449 / \ /`-. +--+-+-+-+-+-++ 450 / ((++))`+----' `+._ / / /| /| .-----, 451 ( || ,-----. ___|___ / / / `-. / \ 452 \ ++--''''''''' | / | `-. |`. / ((++)) \ 453 \ // ((++)) \ |.-' `. `-. `-. || ) 454 `----(' || .-'+--------+----+`-.\ `-.+ .+----, 455 \ +_.-'/ L2 Network `+. / \ 456 \ / \ ``-.-+'((++)) \ 457 `-----' `. .----`-. || ) 458 Base Station \ / \\`-.+ / 459 `. ((++)) \\ / 460 ( \ || `)----' 461 \ `.++ / 462 \ / 463 `-----' 464 Base Station 466 Direct Attachment Option 468 Figure 1 470 +-----+ 471 |MSF ++-----------+ +-----------+ 472 Radio Cell +----++ | MP-BGP+| | 473 ,-----. | CE .......... MPLS LER | 474 / \ | |Mobility| | 475 / ((++)) \ +--+-+-++-+-++ +-----------+ 476 ( || ) L3 Logical Interfaces 477 ,----+. +`-._/ / / / / / / 478 / \ /`-. +--+-+-+-+-+-++ 479 / ((++))`+----' `+._ / / /| /| .-----, 480 ( || ,-----. ___|___ / / / `-. / \ 481 \ ++--''''''''' | / | `-. |`. / ((++)) \ 482 \ // ((++)) \ |.-' `. `-. `-. || ) 483 `----(' || .-'+--------+----+`-.\ `-.+ .+----, 484 \ +_.-'/ L2 Network `+. / \ 485 \ / \ ``-.-+'((++)) \ 486 `-----' `. .----`-. || ) 487 Base Station \ / \\`-.+ / 488 `. ((++)) \\ / 489 ( \ || `)----' 490 \ `.++ / 491 \ / 492 `-----' 493 Base Station 495 Indirect Attachment Option 497 Figure 2 499 2.4.3. Network Hierarchy 501 The distribution of the Mobility Binding information using MP-BGP may 502 be achieved by constructing a flat or hierarchical MP-BGP peering 503 topology among the participating LER nodes. The flat peering logical 504 structure requires a full mesh of MP-BGP sessions and the 505 hierarchical peering structure can make use of the BGP Route 506 Reflectors in which some LER nodes are designated as the Route 507 Reflectors and establish peering sessions between themselves and all 508 other LER supporting MSF (Route-Reflector-Clients). The BGP Route 509 Reflectors capable of supporting MPLS Mobility are referred to as 510 Mobility Route Reflectors. It is important to note that the Mobility 511 Route Reflectors need not support the MSF but must be able to 512 interpret and relay the MSF related MP-BGP messaging. 514 2.4.4. Interface to Other Networks 516 The interface to other networks depends on how the mobility is to be 517 managed between the interconnecting networks. If all mobility 518 functions are to be managed by a service provider's network (given 519 that the network has sufficient coverage) then the interface to other 520 networks can be as simple as the peering gateway node that connects 521 the service provider's MPLS network to the rest of the world. In 522 this case there is no need to extend the MPLS processing over this 523 interface, and since by construction all mobility IP addresses belong 524 to the IP address space of the service provider, the general peering 525 arrangement to other networks where the IP address range of the 526 service provider is advertised out to the Internet will enable the 527 communication between the mobile nodes and the outside destinations. 528 In case of the mobile node roaming, this may be supported between the 529 service provider networks that both implement the customer facing 530 Mobility Support Function and the Network-to-Network Interface (NNI) 531 that employs the use of MPLS label exchange (including the Mobility 532 Labels). 534 3. Mobility Support Function 536 This section describes the proposed set of functional elements of the 537 MPLS LER node capable of providing mobility management services. 538 This document refers to these functional elements as a Mobility 539 Support Function (MSF). 541 3.1. Mobile Node Discovery, Registration and Status 543 3.1.1. Discovery Process - IPv4 545 As in [RFC3344] the discovery of the MSF by the mobile nodes is based 546 on the ICMP Router Discovery [RFC1256] with specific extensions for 547 Mobility Label Based Network (MLBN). The format of the extensions 548 used in this proposal also follows the [RFC3344] section 1.9. 550 The discovery process should be initiated by a mobile host or router 551 by sending the ICMP Router Solicitation message with MLBN MSF 552 Discovery Extension and the TTL set to 1. This ICMP message along 553 with the MLBN Extension is referred to as the MSF Discovery message. 554 The MSF Discovery message should carry the information about the type 555 of the mobile node: Mobile Host or Mobile Router. 557 Upon receipt of the MSF Discovery message the MSF LER must respond 558 with the ICMP Router Advertisement including the MLBN specific 559 Extension. This message is referred to as the MSF Advertisement. 560 The MSF Advertisement will carry different information depending on 561 the type of the mobile node and the registration mode. 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Type | Code | Checksum | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Reserved | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | MSF Discovery Extension TLV (variable) | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 ICMP Router Solicitation with MSF Discovery Extension 575 Figure 3 577 Link Layer Fields: Destination Address - This should be the 578 multicast or broadcast Link Layer Address. 580 IP Fields: Source Address - IP Address of the Mobile Host or IP 581 address of the interface of the Mobile Router from which this 582 message is sent. 584 Destination Address - This is the all-routers multicast address 585 224.0.0.2 or the limited broadcast address 255.255.255.255. 587 TTL - TTL should be set to 1. 589 ICMP Fields: Type = 10 Router Solicitation. 591 Code = 1 MLBN MSF Discovery Extension included. 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Type | Code | Checksum | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Num Addrs |Addr Entry Size| Lifetime | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Router Address | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Preference Level | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | MSF Advertisement Extension (variable) | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 ICMP Router Advertisement with MSF Advertisement Extension 609 Figure 4 611 Link Layer Fields: Destination Address - This should be the source 612 address used to deliver the MSF Discovery message from the mobile 613 node. 615 IP Fields: Source Address - IP Address of the MSF. 617 Destination Address - This is the unicast IP address used in the 618 IP header of the MSF Discovery message from the mobile node. 620 TTL - TTL should be set to 1. 622 ICMP Fields: Type = 9 Router Advertisement. 624 Code = 1 MLBN MSF Advertisement Extension included. 626 Please refer to [RFC1256] for the specification of the remaining 627 fields in both of the above messages. 629 3.1.1.1. MSF Discovery by Mobile Hosts - IPv4 631 Mobile hosts should initiate the MSF Discovery process by sending the 632 MSF Discovery message. The MSF Discovery Extension format for Mobile 633 Hosts is shown below. 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Type | Length |H|Pri. |L|ASTI | Region_ID | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Mobile Host IPv4 Source Address | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Correlation ID | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 Mobile Host MSF Discovery Extension for IPv4 647 Figure 5 649 Type - 0 = MSF Discovery 651 Length - Length of the message in octets. 653 H - Mobile Node Type Indication. 0 = Mobile Host. 655 Pri. - A 3-bit Priority Code (0-7). 657 L - Lightweight Registration Requested (1). 659 ASTI - Application Service Type Indication. This 3-bit field may 660 be used to indicate to the MSF what type of service is to be used 661 by the mobile host. For example, "Internet Access Only" or Full 662 Mobile-to-Mobile Routing". This indication can then be mapped to 663 the Network Update Mode Code used in the Mobility Binding 664 structure. 666 Region_ID - An Identifier (1-255) associated with the Regional 667 Mobility Route Reflector. Region_ID=0 must be used for initial 668 registrations by mobile nodes. 670 Correlation ID - a number used to keep track of the Lightweight 671 Registration message pairs - MSF Discovery/MSF Advertisement. 673 3.1.1.2. MSF Discovery by Mobile Routers - IPv4 675 Mobile routers should initiate the MSF Discovery process by sending 676 the MSF Discovery message. The MSF Discovery Extension format for 677 Mobile Routers is shown below. 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Type | Length |R|Pri. |L|Res. | Region_ID | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Mobile IPv4 Router-ID | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 Mobile Router MSF Discovery Extension 689 Figure 6 691 Type - 0 = MSF Discovery 693 Length - Length of the message in octets. 695 R - Mobile Node Type Indication. 1 = Mobile Router. 697 Pri. - A 3-bit Priority Code (0-7). 699 L - Always set to 0 in the MSF Discovery sent by a mobile router. 701 Res. - Reserved. 703 Region_ID - An Identifier (1-255) associated with the Regional 704 Mobility Route Reflector. Region_ID=0 must be used for initial 705 registrations by mobile nodes. 707 3.1.1.3. MSF Advertisement - IPv4 709 After receiving the MSF Discovery message from a mobile host or 710 router the MSF should reply with the MSF Advertisement message using 711 extension format shown below. 713 0 1 2 3 714 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 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Type | Length | Sequence Number | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Registration Lifetime |L|R|G|Reserved | Group ID | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | MSF IP Address | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | MSF Virtual Link Layer Address (first 32 bits) | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 |Last 16 bits | Reserved | Region_ID | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Correlation ID | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 MSF Advertisement Extension 731 Figure 7 733 Type - 1 = MSF Advertisement 735 Length - Length of the message in octets. 737 Sequence Number - The sequence number of the MSF Advertisement 738 message sent since the MSF is operational. 740 Registration Lifetime - the time in seconds until the registration 741 entry in the MSF database expires. 743 L - Lightweight Registration Confirmed (1). 745 R - Full Registration Required (1). 747 G - Group Registration Supported (1). 749 Group ID - Unique Registration Group Number. Should be zero if G 750 = 0 752 MSF IP Address - Virtual IP Address of the MSF (may be different 753 from any particular MSF LER interface IP address 755 MSF Virtual Link Layer Address - a MAC address shared and 756 recognized by all MPLS LER interfaces participating in the MSF. 757 This address may specifically be used to support Local Micro- 758 Mobility (see Section 4.3.1). 760 Region_ID - An Identifier (1-255) associated with the Regional 761 Mobility Route Reflector. Region_ID=0 must be used for initial 762 registrations by mobile nodes. 764 Correlation ID - a number used to keep track of the registration 765 requests and the corresponding reply message pairs. 767 The MSF Advertisement should be sent to the unicast link layer 768 address and the unicast IP address of the mobile host or router that 769 were used in the MSF Discovery link layer header and the MSF 770 Discovery Extension payload respectively. 772 Upon receipt of the MSF Advertisement mobile hosts should continue to 773 send the MSF Discovery messages with the interval of 1/3 of the 774 specified Registration Lifetime. The MSF should send the MSF 775 Advertisements in response to the periodic MSF Discovery messages 776 from the mobile hosts using the corresponding Correlation IDs. If a 777 mobile host does not get responses to three MSF Discovery messages 778 (serving as the keepalives) the mobile host should initiate a new MSF 779 Discovery process using a new Correlation ID. 781 If the L flag in the MSF Advertisement is set, and the R flag is not, 782 indicating the Lightweight Registration mode (see Section 3.1.3.1), 783 the mobile hosts may start sending datagrams to their IP destinations 784 using the link layer address of the MSF. The L and R flags are 785 mutually exclusive and cannot be set at the same time. 787 If the R flag is set in the MSF Advertisement, indicating that 788 explicit registration is required, mobile hosts should transition to 789 the Full Registration mode (see Section 3.1.3.1.2). 791 The R flag must always be set in the MSF Advertisement if it is in 792 reply to the MSF Discovery sent by a mobile router. Upon receipt of 793 the MSF Advertisement a mobile router must transition to the Routing 794 Adjacency Establishment mode (see Section 3.1.3.2). 796 3.1.2. Discovery Process - IPv6 798 The MSF discovery process for IPv6 is identical to the discovery 799 process for IPv4 with the exception of the use of IPv6 specific 800 Router Solicitation and Advertisement messages based on ICMPv6 801 [RFC4443]. These messages are specified in [RFC4861]. As in the 802 IPv4 case the Router Solicitation and Advertisement messages carry 803 the MLBN extensions and are termed the MSF Discovery and the MSF 804 Advertisement respectively. 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Type | Code | Checksum | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Reserved | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | MSF Discovery Extension TLV (variable) | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 IPv6 Router Solicitation with MSF Discovery Extension 818 Figure 8 820 Link Layer Fields: Destination Address - This should be the 821 multicast or broadcast Link Layer Address. 823 IP Fields: Source Address - IP Address of the Mobile Host or IP 824 address of the interface of the Mobile Router from which this 825 message is sent. 827 Destination Address - This is the all-routers multicast address 828 FF02::2 830 ICMP Fields: Type = 133 Router Solicitation. 832 Code = 1 MLBN MSF Discovery Extension included. 834 0 1 2 3 835 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 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Type | Code | Checksum | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Reachable Time | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Retrans Timer | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | MSF Discovery Extension TLV (variable) | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 IPv6 Router Advertisement with MSF Advertisement Extension 850 Figure 9 852 Link Layer Fields: Destination Address - This should be the source 853 address used to deliver the MSF Discovery message from the mobile 854 node. 856 IP Fields: Source Address - IP Address of the MSF. 858 Destination Address - This is the unicast IP address used in the 859 IP header of the MSF Discovery message from the mobile node. 861 ICMP Fields: Type = 134 Router Advertisement. 863 Code = 1 MLBN MSF Advertisement Extension included. 865 Please refer to [RFC4861] for the specification of the remaining 866 fields in both of the above messages. 868 3.1.2.1. MSF Discovery by Mobile Hosts - IPv6 870 The MSF Discovery message format for IPv6 mobile hosts is identical 871 to the IPv4 message with the IPv6 Source Address used instead of the 872 IPv4 (see Section 3.1.1.1). 874 3.1.2.2. MSF Discovery by Mobile Routers - IPv6 876 The MSF Discovery message format for IPv6 mobile routers is identical 877 to the IPv4 message with the IPv6 Router ID used instead of the IPv4 878 (see Section 3.1.1.2). 880 3.1.2.3. MSF Advertisement - IPv6 882 The MSF Advertisement message format for IPv6 is identical to the 883 IPv4 message format (see Section 3.1.1.3). 885 3.1.3. Registration and Status - IPv4 887 3.1.3.1. Mobile Host Registration - IPv4 889 3.1.3.1.1. Lightweight Registration - IPv4 891 MLBN eliminates the need for the registrations with the Home Agent 892 and Care-of-Addresses. This makes it possible to implement a 893 Lightweight Registration procedure which is simply the completion of 894 the MSF Discovery process (Section 3.1.1). The Lightweight 895 Registration is indicated by the presence of the L flag in the MSF 896 Advertisement message. With the Lightweight Registration the MSF 897 should allocate the local Mobility Label and create the Mobility 898 Binding structure (Section 3.2.2) immediately following the receipt 899 of the MSF Discovery message from a mobile host. The MSF should also 900 initiate the network update process (see Section 4) based on the 901 selected update mode and the indicated mobile application priority. 903 The network update mode selection may be based on the Application 904 Service Type Indication (ASTI) from the MSF discovery message sent by 905 the mobile host. ASTI is a 3-bit field that may be used to indicate 906 to the MSF what type of service is to be used by the mobile host. 907 For example, "Internet Access Only" or "Full Mobile-to-Mobile 908 Routing". This indication can then be mapped to the Network Update 909 Mode Code used in the Mobility Binding structure. 911 3.1.3.1.2. Full Registration - IPv4 913 Full Registration is a registration mode which allows to perform 914 additional functions as part of the registration process. An example 915 of such function is the Mobile Host Authentication. Full 916 registration mode is indicated in the MSF Advertisement by setting 917 the R flag. 919 Full Registration messaging makes use of the UDP port RRR and may 920 provide a mechanism for various functional extensions. Full 921 Registration uses two message types: 923 Registration Request - Type 1 925 Registration Reply - Type 2 927 The Registration Message formats are shown below. 929 0 1 2 3 930 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 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Type | Length |H| Rri.|ASTI | Region_ID | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Mobile Host IPv4 Source Address | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | MSF Address | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Correlation ID | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Extensions 941 +-+-+-+-+-+-+.... 943 Full Registration Request 945 Figure 10 947 Type - 1 = Full Registration Request 949 Length - Length of the message in octets. 951 H - Mobile Node Type Indication. 0 = Mobile Host 953 Pri. - A 3-bit priority code (0-7). 955 ASTI - Application Service Type Indication. This 3-bit field may 956 be used to indicate to the MSF what type of service is to be used 957 by the mobile host. For example, "Internet Access Only" or Full 958 Mobile-to-Mobile Routing". This indication can then be mapped to 959 the Network Update Mode Code used in the Mobility Binding 960 structure. 962 Region_ID - An Identifier (1-255) associated with the Regional 963 Mobility Route Reflector. Region_ID=0 must be used for initial 964 registrations by mobile nodes. 966 Correlation ID - a number used to keep track of the registration 967 requests and the corresponding reply message pairs. 969 0 1 2 3 970 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 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Type | Length | Flags | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Registration Lifetime | Reserved | Region_ID | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Mobile Host IPv4 Source Address | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | MSF IP Address | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | MSF Virtual Link Layer Address (first 32 bits) | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 |Last 16 bits | Reserved | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Correlation ID | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Extensions 987 +-+-+-+-+-+-+.... 989 Full Registration Reply 991 Figure 11 993 Type - 2 = Full Registration Reply 995 Length - Length of the message in octets. 997 Flags - To be defined 999 Registration Lifetime - the time in seconds until the registration 1000 entry in the MSF database expires. 1002 Region_ID - An Identifier (1-255) associated with the Regional 1003 Mobility Route Reflector. Region_ID=0 must be used for initial 1004 registrations by mobile nodes. 1006 MSF IP Address - Virtual IP Address of the MSF (may be different 1007 from any particular MSF LER interface IP address 1009 MSF Virtual Link Layer Address - a MAC address shared and 1010 recognized by all MPLS LER interfaces participating in the MSF. 1011 This address may specifically be used to support Local Micro- 1012 Mobility (see Section 4.3.1). 1014 Correlation ID - a number used to keep track of the registration 1015 requests and the corresponding reply message pairs. 1017 3.1.3.1.3. Group Registration - IPv4 1019 Clearly the discovery and registration procedure has a great effect 1020 on the network responsiveness especially when a mobile host moves 1021 from one serving MSF to another. The following enhanced registration 1022 scheme can be implemented to simplify the registrations resulting 1023 from the MSF-to-MSF handoff and therefore improve the network 1024 responsiveness. We refer to it as the Group Registration. 1026 The entire MPLS edge network may be divided in groups or regions 1027 containing the geographically close MSF enabled LER nodes. Each 1028 group should be assigned a unique Group ID (1-255). The mobile host 1029 will register with a LER node within a group using a Group 1030 Registration procedure. The LER node will distribute the 1031 registration information to the rest of the group members using the 1032 established MP-BGP peering sessions. These messages may be coded as 1033 another type of the NLRI in the Address Family structure. The size 1034 of the region should be large enough to ensure a high probability 1035 that the range of movements of a mobile host will be covered by the 1036 service area of the group but at the same time not too large to avoid 1037 a large registration table size shared among the group members. The 1038 group members can be identified administratively and preconfigured in 1039 the MSF serving LER nodes. 1041 During the initial registration process and as part of the 1042 registration acknowledgement the serving LER may indicate to the 1043 mobile host that it is registered to a group and from now on should 1044 use a group virtual link layer address and a group virtual IP address 1045 for further communications (the addresses may be communicated in the 1046 acknowledgement payload). 1048 The group registration allows to implement the implicit logic by 1049 which no further registrations are required from the mobile node due 1050 to its movements once the initial group registration has been 1051 established. The group members may also pre-allocate the Mobility 1052 Labels and have them ready in case the mobile node moves into the 1053 member's serving area. Once the mobile node has moved into the 1054 serving area of the new MSF group member it continues to send packets 1055 to the group virtual link layer address and the virtual IP address. 1056 As soon as the packet from the mobile node is received by the group 1057 member it will forward the packet to its destination and distribute 1058 the new Mobility Binding to the network. A mobile host should 1059 continue to send the MSF Discovery messages destined to the group 1060 link layer address in order to keep the group registration active. 1062 The group member that is servicing the mobile host can periodically 1063 send the registration update messages to the group members in order 1064 to keep the Mobility Bindings in the standby status. If a group 1065 member has not received any keepalives or packets from the mobile 1066 host in a specified period of time it should silently deactivate its 1067 local registration entry and release the Mobility Label. If the 1068 mobile host happens to be serviced by another group member, this 1069 member will be sending the registration update messages to the group 1070 keeping the registration active. If no group member hears from the 1071 mobile node, the registration must be removed from the group database 1072 after a specified time and the associated Mobility Binding may be 1073 withdrawn from the network by means of the MP-BGP update. 1075 Group Registration message formats are very similar to the Full 1076 Registration message formats. The Group Registrations starts with 1077 the mobile host sending the MSF Discovery message and the MSF 1078 replying with the MSF Advertisement having the G flag set, indicating 1079 that the Group Registration is supported. After this the mobile host 1080 must transition to the Group Registration protocol using the same UDP 1081 port RRR as for the Full Registration. 1083 Group Registration uses two message types: 1085 Group Registration Request - Type 3 1086 Group Registration Reply - Type 4 1088 The Group Registration Message formats are shown below. 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Type | Length |H| Rri.|ASTI |G| Group ID | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Mobile Host IPv4 Source Address | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | MSF Address | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Correlation ID | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Region_ID | Extensions 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+.... 1104 Group Registration Request 1106 Figure 12 1108 Type - 3 = Group Registration Request 1110 Length - Length of the message in octets. 1112 H - Mobile Node Type Indication. 0 = Mobile Host 1114 Pri. - A 3-bit priority code (0-7). 1116 ASTI - Application Service Type Indication. This 3-bit field may 1117 be used to indicate to the MSF what type of service is to be used 1118 by the mobile host. For example, "Internet Access Only" or Full 1119 Mobile-to-Mobile Routing". This indication can then be mapped to 1120 the Network Update Mode Code used in the Mobility Binding 1121 structure. 1123 G - Group Registration Requested (1) 1125 Group ID - Unique Registration Group Number. Should be zero if G 1126 = 0 1128 Correlation ID - a number used to keep track of the registration 1129 requests and the corresponding reply message pairs. 1131 Region_ID - An Identifier (1-255) associated with the Regional 1132 Mobility Route Reflector. Region_ID=0 must be used for initial 1133 registrations by mobile nodes. 1135 0 1 2 3 1136 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 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Type | Length | Flags | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Registration Lifetime |G| Reserved | Group ID | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Mobile Host IPv4 Source Address | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Group Virtual IP Address | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Group Virtual Link Layer Address (first 32 bits) | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 |Last 16 bits | Reserved | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Correlation ID | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | Region_ID | Extensions 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.... 1155 Group Registration Reply 1157 Figure 13 1159 Type - 4 = Group Registration Reply 1161 Length - Length of the message in octets. 1163 Flags - To be defined 1165 Registration Lifetime - the time in seconds until the registration 1166 entry in the MSF database expires. 1168 G - Group Registration Supported (1). 1170 Group ID - Unique Registration Group Number. Should be zero if G 1171 = 0 1173 Group Virtual IP Address - Virtual IP Address that is supported by 1174 all MSF's that belong to the Registration Group identified by the 1175 Group ID. This address may specifically be used to support Group 1176 Micro-Mobility (see Section 4.3.2). 1178 Group Virtual Link Layer Address - a MAC address shared and 1179 recognized by all MPLS LER interfaces of all MSF's that belong to 1180 the Registration Group identified by the Group ID. This address 1181 may specifically be used to support Group Micro-Mobility (see 1182 Section 4.3.2). 1184 Correlation ID - a number used to keep track of the registration 1185 requests and the corresponding reply message pairs. 1187 Region_ID - An Identifier (1-255) associated with the Regional 1188 Mobility Route Reflector. Region_ID=0 must be used for initial 1189 registrations by mobile nodes. 1191 As in the Full Registration case the Group Registration allows to 1192 perform additional functions as part of the registration process by 1193 means of using the functional extensions. An example of such a 1194 function is the Mobile Host Authentication. 1196 After the completion of the Group Registration with the initial MSF 1197 that is part of the Registration Group, the mobile host must send the 1198 MSF Discovery messages destined to the Group Virtual Link Layer 1199 Address listing the Group ID and the Group Virtual IP Address. The 1200 registration information is communicated among the group members 1201 using MP-BGP signaling with the specific SAFI value assigned for this 1202 purpose (see Section 3.2.3). Any group member receiving the MSF 1203 Discovery messages from a mobile host for which the group 1204 registration is active must reply with the MSF Advertisement messages 1205 to the mobile host. When a mobile host moves from one group member 1206 to another it should continue to send packets to its IP destination 1207 using the Group Virtual Link Layer Address. 1209 3.1.3.2. Mobile Router Registration - IPv4 1211 Mobile routers should initiate the registration procedure by sending 1212 the registration message with the mobile router identification flag 1213 set and its Router ID (an IP address that belongs to the router) 1214 specified (see Section 3.1.1.2). 1216 Upon receipt of this registration information the MSF should initiate 1217 the establishment of the dynamic routing protocol adjacency with the 1218 mobile router using protocols such as BGPv4 [RFC4271]. The mobile 1219 router should advertise to the MSF the IP prefixes it serves using 1220 the established routing adjacency. 1222 3.1.3.2.1. Routing Adjacency Establishment 1224 The MSF should receive the routing protocol update from the mobile 1225 router and allocate a single Mobility Label to represent all of the 1226 served prefixes. This label should then be used in the Mobility 1227 Binding structure exported to the network by MP-BGP (see Figure 18). 1228 Optionally, each served IP prefix advertised by the mobile router can 1229 be associated with a separate Mobility Label. This can be used to 1230 provide different mobility processing priority to different IP 1231 prefixes. 1233 The mobile router status detection can be based on the state of the 1234 dynamic routing protocol adjacency maintained by the periodic 1235 keepalive messaging common to the routing protocols. 1237 3.1.4. Registration and Status - IPv6 1239 The registration procedures described for IPv4 in Section 3.1.3 are 1240 fully extended to IPv6 using the same message formats and the UDP 1241 port number. In all messages the IPv4 addresses are replaced with 1242 their IPv6 equivalents (with the corresponding increase in the 1243 required field length). 1245 Thus, for mobile hosts the Lightweight, Full and Group Registration 1246 modes are supported (see Section 3.1.3.1.1, Section 3.1.3.1.2, 1247 Section 3.1.3.1.3), and for mobile routers the same IPv4 procedure 1248 described in Section 3.1.3.2 and modified to include the IPv6 1249 messages should be supported. 1251 In addition to the use of the MSF Discovery/Advertisement message as 1252 keepalives for determining the status of the reachability of the 1253 serving MSF function, mobile nodes may utilize IPv6 Neighbor 1254 Unreachability Detection procedures specified in [RFC4861] section 1255 7.3. 1257 3.2. Integration with MP-BGP 1259 In order to integrate the MSF on the LER with the MP-BGP processing, 1260 a new Address Family must be created. This Address Family must be 1261 assigned a new and unique AFI following the Address Family structure 1262 of MP-BGP. This Address Family may be referred to as the Mobility 1263 Address Family. In fact a number of Mobility Address Families may be 1264 created to support IPv4/IPv6 unicast/multicast protocols. In all 1265 cases the Address Families must use the structure that allows them to 1266 carry the overlay MPLS label information (a specially designated 1267 value of SAFI). 1269 3.2.1. Mobility Address Family 1271 In order to carry the Mobility Binding information the BGP UPDATE 1272 message with the MP_REACH_NLRI and MP_UNREACH_NLRI optional non- 1273 transitive attributes is used as specified in [RFC4760]. 1275 For the mobility management purposes a set of new Address Family 1276 Identifiers (AFI) and Subsequent Address Family Identifiers (SAFI) 1277 are defined. Specifically the following new AFI values are defined: 1279 Mobility IPv4 Unicast - AFI X1 SAFI Y1 1281 Mobility IPv6 Unicast - AFI X2 SAFI Y1 1283 The MP_REACH_NLRI attribute is used to update the LER nodes with new 1284 Mobility Binding information. The structure of the attribute is 1285 shown below. 1287 +---------------------------------------------------------+ 1288 | Address Family Identifier (2 octets) | 1289 +---------------------------------------------------------+ 1290 | Subsequent Address Family Identifier (1 octet) | 1291 +---------------------------------------------------------+ 1292 | Length of Next Hop Network Address (1 octet) | 1293 +---------------------------------------------------------+ 1294 | Network Address of Next Hop (variable) | 1295 +---------------------------------------------------------+ 1296 | Reserved (1 octet) | 1297 +---------------------------------------------------------+ 1298 | Mobility Binding (NLRI) Information (variable) | 1299 +---------------------------------------------------------+ 1301 MP_REACH_NLRI with Mobility Binding 1303 Figure 14 1305 The MP_UNREACH_NLRI attribute is used to withdraw the Mobility 1306 Binding information. The structure of the attribute is shown below. 1308 +---------------------------------------------------------+ 1309 | Address Family Identifier (2 octets) | 1310 +---------------------------------------------------------+ 1311 | Subsequent Address Family Identifier (1 octet) | 1312 +---------------------------------------------------------+ 1313 | Mobility Binding (Withdrawn Routes) (variable) | 1314 +---------------------------------------------------------+ 1316 MP_UNREACH_NLRI with Mobility Binding 1318 Figure 15 1320 The Mobility Binding itself is encoded in the NLRI format shown 1321 below. 1323 +---------------------------+ 1324 | Length (1 octet) | 1325 +---------------------------+ 1326 |Mobility Binding (variable)| 1327 +---------------------------+ 1329 NLRI Encoding for Mobility Bindings 1331 Figure 16 1333 For the definitions of the fields in the above figures (with the 1334 exception of the Mobility Binding related information) please see 1335 [RFC4760]. 1337 3.2.2. Mobility Bindings 1339 Two types of Mobility Binding formats are proposed: Host Mobility 1340 Binding and Router Mobility Binding. 1342 0 1 2 3 1343 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 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Origin MP-BGP NEXT_HOP | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | Target MP-BGP NEXT_HOP | 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | Mobile Host Address | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 |H| UT |Res. | Mobility Label |Pri. |S| 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 NLRI Encoding for the Host Mobility Binding 1356 Figure 17 1358 Origin MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the 1359 Mobility Binding. This address may be carried in the IPv4 or IPv6 1360 format depending on the {AFI, SAFI} pair used. 1362 Target MP-BGP NEXT_HOP - Router ID of the MPLS LER to receive the 1363 Mobility Binding using Selective Downstream Push. For the 1364 Unsolicited Downstream Push this field should be set to 0. This 1365 address may be carried in the IPv4 or IPv6 format depending on the 1366 {AFI, SAFI} pair used. 1368 Mobile Host Address - IPv4 or IPv6 Address of the mobile host. 1369 This address may be carried in the IPv4 or IPv6 format depending 1370 on the {AFI, SAFI} pair used. 1372 H - Mobile Node Type Indication. 0 = Mobile Host 1374 UT - Update Type. This 3-bit code is mapped to the ASTI code in 1375 the MSF Discovery and Registration Request messages to indicate 1376 the Network Update Mode selection (see Section 4). 1378 Res. - Reserved. 1380 Mobility Label - Overlay MPLS Label (20 bits) associated with the 1381 IP address of the mobile host in the MSF database. 1383 Pri. - A 3-bit priority code (0-7). 1385 S - Bottom of Stack. 1387 0 1 2 3 1388 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 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Origin MP-BGP NEXT_HOP | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Target MP-BGP NEXT_HOP | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | Mobile Router ID | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 |R| UT | Res. |No of Prefixes | IP Prefix 1 | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | IP Prefix 1 | Prefix 1 Len. | Variable No. | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | of Prefixes/Len | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Mobility Label |Pri. |S| 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 NLRI Encoding for the Router Mobility Binding 1407 Figure 18 1409 Origin MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the 1410 Mobility Binding. This address may be carried in the IPv4 or IPv6 1411 format depending on the {AFI, SAFI} pair used. 1413 Target MP-BGP NEXT_HOP - Router ID of the MPLS LER to receive the 1414 Mobility Binding using Selective Downstream Push. For the 1415 Unsolicited Downstream Push this field should be set to 0. This 1416 address may be carried in the IPv4 or IPv6 format depending on the 1417 {AFI, SAFI} pair used. 1419 Mobile Router ID - IP Address of the mobile router. This address 1420 may be carried in the IPv4 or IPv6 format depending on the {AFI, 1421 SAFI} pair used. 1423 R - Mobile Node Type Indication. 1 = Mobile Router 1425 UT - Update Type. This 3-bit code is mapped to the ASTI code in 1426 the MSF Discovery and Registration Request messages to indicate 1427 the Network Update Mode selection (see Section 4). 1429 Res. - Reserved. 1431 No. of Prefixes - Number of IP Prefixes carried in this Mobility 1432 Binding. 1434 IP Prefix 1 - First IP Prefix (32 bits for IPv4, 128 bits for 1435 IPv6) 1437 Prefix 1 Len. - Length (in number of bits) of the network part of 1438 IP Prefix 1 1440 Mobility Label - Overlay MPLS Label (20 bits) associated with each 1441 of the IP Prefixes served by the mobile router in the MSF database 1442 of the originating LER. 1444 S - Bottom of Stack. 1446 The receiving MSF must read the R flag in the Mobility Binding and 1447 associate the provided Mobility Label with each of the IP prefixes 1448 found in the body of the Mobility Binding. The derived associations 1449 must be installed in the MPLS forwarding table of the MPLS LER and in 1450 turn associated with the infrastructure label assigned to the "Origin 1451 MP-BGP NEXT_HOP" address indicated in the received Mobility Binding 1453 3.2.3. Group Registration Management with MP-BGP 1455 The Group Registration (Section 3.1.3.1.3) information obtained via 1456 the registration messaging with a mobile host is shared among the 1457 group members using existing MP-BGP peering sessions. To achieve 1458 this, the MSF should allow for a configuration capability to identify 1459 the group membership by assigning a Group ID to the MP-BGP peers that 1460 belong to the same group. The same capability should be provided 1461 within the Mobility Route Reflectors in order to be able to 1462 successfully update the group members with the mobile node 1463 registration information. 1465 The mobile host registration information includes the IP address of 1466 the mobile host, the Group ID, the priority and the ASTI codes as 1467 well as the MAC address of the mobile host. This information is 1468 encoded in the Address Family structure using the AFI values 1469 specified in Section 3.2.1 but with a specifically designated value 1470 of SAFI. The encoded information is then carried in the 1471 MP_REACH_NLRI or MP_UNREACH_NLRI. 1473 Specifically the following new SAFI value is defined: 1475 Mobility IPv4 Unicast - AFI X1 SAFI Y2 1477 Mobility IPv6 Unicast - AFI X2 SAFI Y2 1479 The NLRI encoding is shown below: 1481 0 1 2 3 1482 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 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | MP-BGP NEXT_HOP | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | Reserved |H| Rri.|ASTI |G| Group ID | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 | Mobile Host IP Address | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | Group Virtual IP Address | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Mobile Host MAC Address (first 32 bits) | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Last 16 bits | Reserved | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | Correlation ID | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 Group Registration NLRI Encoding 1501 Figure 19 1503 MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the Group 1504 Registration Update. This address may be carried in the IPv4 or 1505 IPv6 format depending on the {AFI, SAFI} pair used. 1507 H - Mobile Node Type Indication. 0 = Mobile Host 1509 Pri. - A 3-bit priority code (0-7). 1511 ASTI - Application Service Type Indication. This 3-bit field may 1512 be used to indicate to the MSF what type of service is to be used 1513 by the mobile host. For example, "Internet Access Only" or Full 1514 Mobile-to-Mobile Routing". This indication can then be mapped to 1515 the Network Update Mode Code used in the Mobility Binding 1516 structure. 1518 G - Group Registration Requested (1) 1520 Group ID - Unique Registration Group Number. Should be zero if G 1521 = 0 1523 Mobile Host IP Address - IPv4 or IPv6 Address of the mobile host. 1524 This address may be carried in the IPv4 or IPv6 format depending 1525 on the {AFI, SAFI} pair used. 1527 Group Virtual IP Address - IPv4 or IPv6 address assigned for the 1528 group and joined by all LER interfaces participating in the MSF. 1529 For IPv6 this may be the Anycast IP address. 1531 Mobile Host MAC Address - MAC address of the mobile host. 1533 Correlation ID - a number used to keep track of the registration 1534 requests and the corresponding reply message pairs. 1536 The group registration information updates may be sent periodically 1537 by the group members. The registration information for multiple 1538 mobile hosts may be aggregated in a single MP-BGP UPDATE message. 1539 The mobile host registration information may be explicitly withdrawn 1540 by the group member that was the last to "hear" from the mobile host. 1542 If a group member receives the MP-BGP registration information update 1543 listing a mobile host that has an active local registration entry, 1544 the local registration information must be silently discarded and the 1545 corresponding local Mobility Binding deleted. The local Mobility 1546 Label should be returned to the local available label pool. 1548 If a local registration entry for a mobile host has expired, and if a 1549 mobile host registration information is not found in the incoming 1550 periodic MP-BGP registration information updates from any of the 1551 group members, the group member should send the MP-BGP registration 1552 information update carrying the host's registration information in 1553 the MP_UNREACH_NLRI attribute. In addition the group member should 1554 initiate a network update using the MP_UNREACH_NLRI with the encoded 1555 Mobility Binding for the host in order to withdraw the Mobility 1556 Binding from the MSF databases of the MPLS LER nodes. 1558 3.2.4. BGP Capability Advertisement 1560 The {AFI, SAFI} pairs defined in this document for mobility 1561 management must be supported by all BGP speakers participating in 1562 mobility management. A BGP Capability Advertisement as specified in 1563 [RFC4760] must be used by the BGP speakers to ensure compatibility. 1565 3.3. Mobile Application Priority Indication and Recognition 1567 Given the sensitivity of applications to the network service 1568 disruption the MSF function should include a mechanism by which an 1569 application may indicate the level of tolerance to the disruption due 1570 to the network handling of the handoff process. This indication may 1571 be encoded in the registration messaging payload and then 1572 incorporated into the Mobility Binding protocol structure. The 1573 application sensitivity prioritization scheme may be used to control 1574 the Mobility Binding processing priority during the distribution 1575 process. For example a mobile host running a real time interactive 1576 application may be given a higher processing priority over the mobile 1577 host running an elastic data transfer application. The 1578 prioritization of processing leads to a differential treatment of the 1579 mobile application at various processing points of the mobile network 1580 such as the ingress MSF, the intermediate hierarchical route 1581 processing by MP-BGP Route Reflectors and the egress MSF. 1583 In addition to the processing priority, the priority indication 1584 mechanism may be used to implement the network update grouping and 1585 timing policies in a manner that could decrease the frequency of the 1586 updates and thus increase the scalability of the network. 1587 Specifically, the indicated application priorities may be mapped into 1588 the network update classes where the top priority may get an 1589 immediate network update and the lower priorities may be organized 1590 into classes. For each class the network update process may be 1591 delayed for a time period that is not expected to result in the 1592 unreasonable disruption to an application of a given priority level. 1593 The network updates for any new registration events of the same 1594 priority level that have occurred during the corresponding delay 1595 period may be grouped in a single MP-BGP update message. If a single 1596 update message cannot carry all of the newly arrived registrations an 1597 additional update should be created and sent. The update mode may be 1598 determined from the Application Service Type Indication communicated 1599 during the registration. 1601 3.4. Application Service Type Indication 1603 Application Service Type Indication (ASTI) is a 3-bit field that may 1604 be used to indicate to the MSF what type of service is to be used by 1605 the mobile host. For example, "Internet Access Only" or "Full 1606 Mobile-to-Mobile Routing". This indication may then be mapped to the 1607 Network Update Type Code used in the Mobility Binding structure. For 1608 example, if ASTI code 001 (binary) is used to indicate the "Internet 1609 Access Only" service, the local MSF may use the Selective Downstream 1610 Push (see Section 4.1.2) Network Update mode. In addition the MSF 1611 may include the corresponding Update Type code in the Mobility 1612 Binding structure in order to indicate to the Mobility Route 1613 Reflectors that the Selective Downstream Push is to be used. 1615 4. Network Update and Hand-off Processing 1617 4.1. Network Update Modes 1619 The following four modes for the Mobility Binding Distribution or 1620 Withdrawal are proposed: i) unsolicited downstream push, ii) 1621 selective downstream push, iii) predictive downstream push, and iv) 1622 hierarchical on-demand distribution. 1624 4.1.1. Unsolicited Downstream Push 1626 In this mode the originating LER node updates all other MSF enabled 1627 LER nodes that are directly peered with it. In case of a 1628 hierarchical topology the originating LER node sends a MP-BGP update 1629 with the Mobility Binding information to a Route Reflector which in 1630 turn updates all of the participating MSF enabled LER Route Reflector 1631 clients. Thus the network wide update can only considered to be 1632 complete if and only if all of the MSF LER nodes are updated. 1633 Clearly this distribution mode has scalability limitations and may be 1634 applicable for a relatively small number of the MSF enabled LER 1635 nodes. The Update Type Code for this mode is binary 000. 1637 4.1.2. Selective Downstream Push 1639 In this mode the Mobility Binding updates are only sent to a select 1640 set of the MSF enabled LER nodes. The underlying idea for this mode 1641 is that it is very likely that the most used destinations from the 1642 mobile host when it communicates with the Internet are the 1643 destinations reachable via a finite set of the service provider's 1644 Internet gateway nodes which are in turn reachable via a finite set 1645 of the MSF enabled LER nodes. As such, when a mobile host registers 1646 with the serving MSF, instead of using the Unsolicited Downstream 1647 Push to all LER nodes, the Mobility Binding update for this mobile 1648 host would be sent to a finite set of the LER nodes connected to the 1649 service provider Internet gateways. This mode can be used for the 1650 initial update process and the Unsolicited Downstream Push can be 1651 used at a later point in time. The Update Type Code for this mode is 1652 binary 001. 1654 4.1.3. Predictive Downstream Push 1656 In this mode the Mobility Binding updates are sent to those MSF 1657 enabled LER nodes which are identified as a NEXT_HOP for the FEC (and 1658 the corresponding LSP) leading to the destination of the packet 1659 originated by a mobile node. This mode is based on the fact that if 1660 the destination FEC exists in the serving MSF LER's routing table, 1661 and the mobile node sends a packet to the FEC, the LER will perform 1662 the label imposition (for the infrastructure label) by selecting the 1663 label corresponding to the FEC NEXT_HOP. This NEXT_HOP in turn 1664 identifies the destination MSF enabled LER node to which the Mobility 1665 Binding update needs to be sent. The predictive feature of this mode 1666 comes from the fact that the Mobility Binding update destination is 1667 predicted as the result of the originating LER's lookup of the 1668 destination FEC and its NEXT_HOP. Clearly it is likely that the LER 1669 node to which the predictive Mobility Binding update is sent may 1670 receive the reply packet from the mobile node's destination before 1671 the Mobility Binding for the originating host is received. In this 1672 case the LER that is being updated may buffer the reply packet for a 1673 reasonable period of time to wait for the mobility update. The 1674 Update Type Code for this mode is binary 010. 1676 4.1.4. Hierarchical On-Demand Distribution 1678 The Mobility Binding update is first sent by a serving MSF LER to a 1679 set of Mobility Route Reflectors using the Selective Downstream Push. 1680 Once the Mobility Route Reflectors have been updated, all other LER 1681 nodes must explicitly request Mobility Labels from the Mobility Route 1682 Reflectors for packets destined to a mobile node. The Update Type 1683 Code for this mode is binary 011. 1685 4.1.4.1. On-Demand Requests for Mobility Binding Information 1687 To support the Hierarchical On-Demand Distribution Network Update 1688 Mode the following explicit Mobility Binding information request 1689 procedure based on MP-BGP may be used. When a MPLS LER supporting 1690 MPLS Mobility receives an IP packet, it first should check if the 1691 Destination Address listed in the IP header belongs to the overall IP 1692 address range assigned to the mobility functions and the 1693 corresponding mobile device fleet. If the Destination Address falls 1694 within this range and the matching Mobility Binding is present in the 1695 LER MSF database, the packet should be encapsulated using the 1696 appropriate MPLS label stack and forwarded on the LSP toward the LER 1697 that is listed as the "Origin MP-BGP NEXT_HOP" in the Mobility 1698 Binding. If the IP address is outside of the mobility fleet range 1699 the packet must be treated in accordance with the conventional rules 1700 based on either the IP or MPLS forwarding tables. 1702 If the packet falls into the mobility fleet range and no matching 1703 Mobility Binding entry exists in the MSF database, the LER should 1704 send an on-demand request for Mobility Binding Information to the 1705 designated Mobility Route Reflector. This request is encoded as a 1706 special type of the MP_REACH_NLRI attribute using a specific SAFI 1707 value and one of the AFI values defined earlier. The Mobility Route 1708 Reflector should process the request and return the Mobility Binding 1709 update to the requesting LER using the NLRI encoding shown in 1710 Section 3.2.2. 1712 Specifically the following new SAFI value is defined for the On- 1713 Demand Mobility Binding Information Request: 1715 Mobility IPv4 Unicast - AFI X1 SAFI Y3 1717 Mobility IPv6 Unicast - AFI X2 SAFI Y3 1719 The NLRI encoding is shown below: 1721 0 1 2 3 1722 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 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | MP-BGP NEXT_HOP | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 |Request Type | Region_ID | Number of Addresses | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | IP Destination Address | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | IP Destination Address 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1733 NLRI Encoding for On-Demand Mobility Binding Request 1735 Figure 20 1737 MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the On- 1738 Demand Mobility Binding Information Request. This address may be 1739 carried in the IPv4 or IPv6 format depending on the {AFI, SAFI} 1740 pair used. 1742 Request Type - To be defined (may be "Specific, Partial, ALL or 1743 LRL"). 1745 Region_ID - An Identifier (1-255) associated with the Regional 1746 Mobility Route Reflector. Region_ID=0 must be used for initial 1747 registrations by mobile nodes. 1749 Number of Addresses - Number of IP Destination Addresses listed in 1750 the On-Demand Request for which the Mobility Binding Information 1751 is requested 1753 IP Destination Address - The IPv4 or IPv6 address of a mobile host 1754 for which the Mobility Binding Information is requested. 1756 If the Request Type is not equal to LRL - Last Requestor List, the 1757 Mobility Route Reflector (mRR) should reply with a regular Mobility 1758 Binding Update. If the request type is equal to LRL, then the 1759 following reply format should be used: 1761 0 1 2 3 1762 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 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | MP-BGP NEXT_HOP | 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 |Request Type | Reserved | Number of Addresses | 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | LRL Length | IP Destination + | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | Address | Last Requestor + | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 | Router_ID |L.R. Region_ID | Last + | 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 | Requestor Router_ID |L.R. Region_ID | LRL + | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 | Length | IP Destination + | 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | Address | Last Requestor + | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | Router_ID |L.R. Region_ID | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1783 NLRI Encoding for On-Demand LRL Reply 1785 Figure 21 1787 MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the On- 1788 Demand LRL Reply. This address may be carried in the IPv4 or IPv6 1789 format depending on the {AFI, SAFI} pair used. 1791 Request Type - LRL Reply. 1793 Number of Addresses - LRL's in the reply 1795 IP Destination Address - The IPv4 or IPv6 address of a mobile host 1796 for which the LRL Information is requested. 1798 Last Requestor Router_ID - IP Address of the LER from which the 1799 On-Demand Mobility Binding Information Request for the mobile node 1800 in question was last received (may be more than one). 1802 L.R. Region_ID - ID of the Regional mRR serving the LER from which 1803 the On-Demand Mobility Binding Information Request for the mobile 1804 node in question was last received (may be more than one). 1806 4.1.5. Network Hierarchy Considerations 1808 The first three update modes are directly applicable for the flat MSF 1809 LER peering topology and the fourth to the hierarchical peering 1810 environment. In the hierarchical peering environment only 1811 Unsolicited Downstream Push does not require any modifications to the 1812 Route Reflector operation. The Selective and Predictive modes 1813 require that the Route Reflectors perform selective MP-BGP updates 1814 for the Mobility Bindings distribution. This can be achieved by a 1815 modification of the Route Reflector update process where destinations 1816 of the selective updates indicated by the Update Type Code can be 1817 derived from the "Target NEXT_HOP" parameter in the Mobility Binding 1818 structure. The Hierarchical On-Demand mode requires the Route 1819 Reflectors to store the Mobility Bindings and respond to the on- 1820 demand Mobility Binding requests initiated by the client MSF LER 1821 nodes or other Mobility Route Reflectors. 1823 4.1.6. Regionalization and Scalability 1825 To improve the scalability of the network update process the entire 1826 serving network may be divided into the Registration Regions. Each 1827 registration region is served by a Regional Mobility Route Reflector 1828 (mRR) with the individual MSF LER nodes falling within the region 1829 serving as the Route Reflector Clients. Each MSF LER node in turn 1830 may serve a specific geographic area called a Mobility Region that is 1831 covered by a given set of Radio Access Networks using Direct or In- 1832 direct Attachment options. This type of the regionalized mobility 1833 signaling infrastructure is referred to as the Mobility Information 1834 Location System (MILS) and is shown in the figure below. 1836 mRR1 mRR3 1837 +----+ +----+ 1838 | +------------------+ `. 1839 .++-+-+ mRR2 +--+-\ `. 1840 .'//| | +----+ | |`. \ 1841 .' /| | +--------+ +---------+ |\ \ `. 1842 Registration Region 1 ++++-\ Registration region 4 1843 .' / / | /\ \ `. | \ \ `. 1844 .' / | | Registration region 2 | \ `. `. 1845 +-.' / +-/ | / | \ \ | | \ \ 1846 +-+ +-/ +-+ +-\ | \ \ \ \-+ \ `.-+`. 1847 LER11 +-+ LER13+-+ +-/ | \-+ `. +-+ \-+ +-+ +`. 1848 . LER12 . LER14 +-+ +-\ +-+ +-\ LER31 +-+ LER33+-+ 1849 / \ . / \ . LER21 +-+ LER23+-+ . LER32 . LER34 1850 ; : / \ ; : / \ . LER22 . LER24 / \ . / \ . 1851 |11 | ;12 :|13 |;14 : / \ . / \ . ; : / \ ; : / \ 1852 | | | || || | ;21 : / \ ; : / \ |31 |;32 :|33 |;34 : 1853 |++ | | || || | | | ;22 :|23 |;24 : | || || || | 1854 :++MN | |: ;| | | | | || || | | || || || | 1855 \ / : ; \ / : ; | | | || || | : ;| |: ;|++ | 1856 ' \ / ' \ / : ; | |: ;| | \ / : ; \ / :++CN 1857 ' ' \ / : ; \ / : ; ' \ / ' \ / 1858 ' \ / ' \ / ' ' 1859 ' ' 1860 Mobility Regions 1862 Regionalized Mobility Information Location System 1864 Figure 22 1866 4.1.6.1. Mobility Information Location System (MILS) 1868 The operation of MILS is based on the Hierarchical On-Demand Network 1869 Update mode and requires the individual MSF LER nodes to only 1870 directly update their respective Regional Mobility Route Reflectors 1871 (using the Selective Update). After the Regional mRR's have been 1872 updated with the Mobility Binding information, these bindings may be 1873 explicitly requested by the MSF LER's in the same Registration Region 1874 or the LER's in other regions via their mRR's. To facilitate the 1875 hand-off process a Last Requestor List (LRL) is introduced and 1876 associated with each Mobility Binding at the Regional mRR level. The 1877 LRL is a list of 2-tuples where each 2-tuple consists of the 1878 Router_ID and Region_ID of the MSF LER nodes that have requested 1879 Mobility Binding information for a particular mobile node. The 1880 logical operation of MILS is described below based on Figure 22. 1882 1. Assume that a previously unknown MN initiated a Discovery and 1883 Registration process in the Mobility Region 11. Upon successful 1884 registration MN communicates its IP address to the MSF in LER11 and 1885 receives the related MSF information including the Region_ID=1. 1886 (During the registration the newly initialized MN should use 1887 Region_ID=0). 1889 2. LER11 creates a local Mobility Binding for the MN and updates 1890 mRR1 using the Selective Mode specifying the MN's IP address, It's 1891 own Router_ID, the Mobility Label and the initial Region_ID=0. LER11 1892 stores the received Mobility Binding and associates an empty LRL with 1893 it. 1895 3. Assume that a Correspondent Node (CN) in the Mobility Region 34 1896 sends a packet to the MN in the Mobility Region 11. The packet 1897 reaches LER34. 1899 4. LER34 identifies that the packet falls into the mobility address 1900 range and requests Mobility Binding information from its Regional 1901 mRR3 using On-Demand Mobility Binding Request (see Figure 20). LER34 1902 uses the value of the Region_ID=3 in the request. 1904 5. Since mRR3 does not have the Mobility Binding for the MN it 1905 forwards the requests to both mRR1 and mRR2. mRR1 replies with the 1906 Mobility Binding and mRR3 forwards the reply to LER34. Both mRR1 and 1907 mRR3 associate an LRL with the Mobility Binding listing the LER34 1908 Router_ID and the Region_ID=3. 1910 6. LER34 forwards the packet to the MN using the LSP between LER11 1911 and LER34 and a stacked Mobility Label extracted from the received 1912 Mobility Binding. 1914 7. Assume that MN now moves into the Mobility Region 22. It 1915 initiates a new Discovery and Registration procedure and registers 1916 with the MSF at LER22 specifying its IP address and the Last 1917 Region_ID=1. 1919 8. LER22 creates a local Mobility Binding for the MN and updates its 1920 regional mRR2 using Selective Mode and sending the Region_ID=1 along 1921 with the Mobility Binding. 1923 9. mRR2 receives the new Mobility Binding and examines the associated 1924 value of Region_ID. If it is not equal to 0 then the LRL for this 1925 binding must be requested from the mRR identified by the Region_ID. 1926 In this case mRR2 sends the On-Demand request to mRR1 asking for the 1927 associated LRL created in step 5. 1929 10. mRR2 receives the LRL={Router_ID=LER34, Region_ID=3} from mRR1 1930 (see Figure 21) and sends a Mobility Binding update to mRR3 using the 1931 Selective Downstream Push Mode with the "Target MP-BGP NEXT_HOP" set 1932 to the LER34 Router_ID. 1934 11. mRR3 receives the updated Mobility Binding and looks up the 1935 "Target MP-BGP NEXT_HOP". In this case it is equal to the LER34 1936 Router_ID. mRR3 updates LER34 with the new Mobility Binding using 1937 Selective Downstream Push. LER34 starts to forward packets to the MN 1938 using the LSP between LER34 and LER22 (listed as the "Origin MP-BGP 1939 NEXT_HOP" in the updated Mobility Binding) and the new overlay 1940 Mobility Label. 1942 4.2. Hand-off Processing 1944 The use of the Multi-Protocol BGP for mobility management allows a 1945 simple basic hand-off processing scheme to be implemented. In 1946 particular, when a mobile node detects that it can no longer receive 1947 the keepalive acknowledgements from the serving MSF it initiates the 1948 new discovery and registration procedure. After the successful 1949 registration the new serving MSF will assign and distribute a new 1950 Mobility Binding to the rest of the participating LER nodes thus 1951 replacing the corresponding old Mobility Binding entries in their MSF 1952 databases. Once the entries have been replaced by the new Mobility 1953 Binding the LER nodes will automatically forward the packets destined 1954 for the mobile node onto the new LSPs connecting to the mobile node's 1955 new serving MSF and the corresponding new Radio Access Network. 1957 The described hand-off procedure provides a basic hand-off handling 1958 in that it requires a new mobile node registration to trigger the 1959 Mobility Binding update to the network. The service disruption due 1960 to the time required to detect the loss of communication and to 1961 discover the new MSF and register with it can be minimized by 1962 selecting the fast keepalive timers but this in turn will result in 1963 the increased processing overhead and a possible impact on 1964 scalability. At the same time the frequency of the hand-offs between 1965 the MSF LER nodes can reasonably be expected to be much lower then 1966 the frequency of the Layer 2 hand-offs because the MSF enabled LER is 1967 expected to serve a large area potentially covered by multiple Radio 1968 Access Networks. Therefore a reasonable configuration of the 1969 keepalive timers and the low frequency of the MSF-to-MSF hand-offs 1970 may result in an acceptable network responsiveness especially for 1971 disruption tolerant applications. 1973 In cases where the application sensitivity requires a better network 1974 responsiveness a number of more sophisticated hand-off methods can be 1975 implemented. One of the methods may make use of the Group 1976 Registration as described above. In this case no discovery or 1977 registration is required from the mobile node when it moves into the 1978 new service area - it simply must continue to send packets to the 1979 group address and whichever group member happens to be serving the 1980 mobile node will distribute the pre-assigned Mobility Label to update 1981 the network. Thus the hand-off latency becomes only a function of 1982 the MP-BGP update processing as opposed to being a function of a 1983 combination of a potentially lengthy discovery and registration as 1984 well as the MP-BGP update procedures. Again, this scheme requires a 1985 trade-off analysis between the gain in the network responsiveness and 1986 the cost in signaling and processing required to maintain the shared 1987 registration table. 1989 4.3. Micro-Mobility Handling 1991 In the context of Mobile IP Micro-Mobility can be defined as a range 1992 of the mobile node movements that do not require re-registrations 1993 with the Mobile IP HA. A number of proposals exist that are targeted 1994 to extend the range of micro-mobility by utilizing the hierarchical 1995 mobility management schemes. 1997 In the context of this document micro-mobility is defined as the 1998 range of the mobile node's movements that do not result in the 1999 registration with a new MSF or the network update by MP-BGP, or both. 2000 As such the following two micro-mobility scenarios are considered by 2001 this proposal. 2003 4.3.1. Local Micro-Mobility 2005 Local micro-mobility is defined as the range of movements of the 2006 mobile node that is contained within the serving area of a given MSF 2007 enabled LER node. Referring to Figure 1 this moving pattern would 2008 correspond to the mobile node transitioning between the radio cells 2009 associated with the L3 logical interfaces local to the serving LER 2010 node. Clearly such a movement pattern should not result in either 2011 the re-registration with the MSF or the network update by MP-BGP. 2013 In order to support Local Micro-Mobility the MSF should have the 2014 capability of "tracking" the mobile node association with the LER L3 2015 logical interfaces. This "tracking" may simply be based on the 2016 reception of the datagrams from the mobile node. If the packets from 2017 the same L2 address and L3 source addresses started arriving on a new 2018 L3 logical interface of the LER and the MSF registration for the 2019 mobile node in question is active the MSF should associate the new L3 2020 logical interface with the existing registration entry and the 2021 corresponding local Mobility Binding. 2023 4.3.2. Group Micro-Mobility 2025 Group Micro-Mobility makes direct use of the Group Registration 2026 described in Section 3.1.3. In this case the Group Micro-Mobility is 2027 defined as the range of the mobile node's movements that do not 2028 result in the MSF re-registration process. Group Micro-Mobility 2029 still requires the network update by MP-BGP. 2031 5. Datagram Delivery 2033 The delivery of packets from the MSF registered mobile node to other 2034 network destinations uses the same processing as in the other MPLS 2035 services. Namely, when a packet is received from the mobile node the 2036 LER looks up the MPLS forwarding database to find a FEC to which the 2037 destination IP address belongs. Once the FEC is identified the 2038 corresponding MPLS label (or label stack) is used to send the packet 2039 on the LSP toward the destination. 2041 For the packets destined to the mobile node, when the packet is 2042 received by the LER the MSF performs a lookup in the overlay MPLS 2043 forwarding table to find the Mobility Binding matching the 2044 destination address of the mobile node (this binding entry was 2045 populated as the result of the Mobility Binding Distribution 2046 process). Once the match is found the inner MPLS label is pushed 2047 onto the MPLS label stack. Then the LER performs an additional 2048 lookup to find a FEC and the corresponding label matching the "Origin 2049 MP-BGP NEXT_HOP" LER IP address associated with this Mobility 2050 Binding. This outer label is then pushed onto the MPLS label stack 2051 and the packet is forwarded on the LSP. 2053 At the receiving MSF enabled LER the packet is processed and the 2054 inner MPLS label is examined to find the reverse Mobility Binding 2055 match in order to identify the IP address of the mobile node. Once 2056 the IP address is identified the corresponding Layer 2 address is 2057 found in the MSF registration database. The packet payload is then 2058 encapsulated into the Layer 2 protocol and delivered to the mobile 2059 node. 2061 In the case when the mobility service is provided to the mobile 2062 router, the forwarding of packets follows the same procedure for the 2063 service provider MPLS network segment. The packet forwarding between 2064 the mobile router and the serving MSF enabled LER does not have to 2065 use MPLS and can be based on IPv4 or IPv6 and the corresponding radio 2066 attachment layer 2 protocol. 2068 6. Security Considerations 2070 The Lightweight Registration procedure (see Section 3.1.3.1.1) and 2071 the associated Network Update and traffic processing provides the 2072 capability to bypass the Full Registration mode in favor of the 2073 ability to significantly decrease the registration processing time. 2074 From the security perspective this procedure should only be allowed 2075 if the layer 2 radio access network provides acceptable mobile node 2076 authentication. 2078 To provide for stronger authentication, the Full or the Group 2079 Registration procedures must be used (see Section 3.1.3.1.2, 2080 Section 3.1.3.1.3). These procedures allow to use additional 2081 authentication procedures by making use of the Registration Request 2082 and Reply message extensions (see Figure 10, Figure 11). 2084 For the Mobile Routers, existing routing protocol security procedures 2085 such as the peer authentication may be used. 2087 7. IANA Considerations 2089 New ICMP code values for message types 9, 10, 133 and 134: 2091 Type=10 - IPv4 Router Solicitation, Code=1 - MLBN MSF Discovery 2092 Extension 2094 Type=9 - IPv4 Router Advertisement, Code=1 - MLBN MSF 2095 Advertisement Extension 2097 Type=133 - IPv6 Router Solicitation, Code=1 - MLBN MSF Discovery 2098 Extension 2100 Type=134 - IPv6 Router Advertisement, Code=1 - MLBN MSF 2101 Advertisement Extension 2103 New UDP port number: 2105 UDP Port RRR for the MLBN Full and Group Registration Protocol. 2107 New {AFI, SAFI} pairs for MP-BGP: 2109 AFI=X1, SAFI=Y1 - MLBN Mobility Binding IPv4 Unicast 2111 AFI=X1, SAFI=Y2 - MLBN Group Registration IPv4 Unicast 2113 AFI=X1, SAFI=Y3 - MLBN On-Demand Binding Information IPv4 Unicast 2115 AFI=X2, SAFI=Y1 - MLBN Mobility Binding IPv6 Unicast 2117 AFI=X2, SAFI=Y2 - MLBN Group Registration IPv6 Unicast 2119 AFI=X2, SAFI=Y3 - MLBN On-Demand Binding Information IPv6 Unicast 2121 8. Acknowledgements 2123 The authors would like to thank Dr. Stuart Elby of Verizon 2124 Communications for his insights and valuable suggestions related to 2125 this work. 2127 9. IPR Notice 2129 The IETF has been notified of intellectual property rights claimed in 2130 regard to some or all of the specification contained in this 2131 document. For more information consult the online list of claimed 2132 rights. 2134 10. References 2136 10.1. Normative References 2138 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 2139 September 1991. 2141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2142 Requirement Levels", BCP 14, RFC 2119, March 1997. 2144 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 2145 BGP-4", RFC 3107, May 2001. 2147 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 2148 August 2002. 2150 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 2151 in IPv6", RFC 3775, June 2004. 2153 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 2154 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 2155 RFC 3963, January 2005. 2157 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 2158 Protocol 4 (BGP-4)", RFC 4271, January 2006. 2160 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2161 Networks (VPNs)", RFC 4364, February 2006. 2163 [RFC4443] Conta, A. and S. Deering, "Internet Control Message 2164 Protocol (ICMPv6) for the Internet Protocol Version 6 2165 (IPv6) Specification", RFC 4443, March 2006. 2167 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2168 "Multiprotocol Extensions for BGP-4", RFC 4760, 2169 January 2007. 2171 [RFC4861] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 2172 Discovery for IP Version 6 (IPv6)", RFC 4861, 2173 September 2007. 2175 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 2176 B. Thomas, "LDP Specification", RFC 5036, October 2007. 2178 10.2. Informative References 2180 [MM-MPLS] Langar, L., Toshme, S., and N. Bouabdallah, "An Approach 2181 for Mobility Modeling - Towards an Efficient Mobility 2182 Management Support in Future Wireless Networks", IEEE/ 2183 IFIP NOMS, 2006. 2185 Authors' Addresses 2187 Oleg Berzin 2188 Verizon Communications 2189 1717 Arch Street 2190 Philadelphia, PA 19103 2191 US 2193 Phone: +1 215-466-2738 2194 Email: oleg.berzin@verizon.com 2196 Andrew G. Malis 2197 Verizon Communications 2198 40 Sylvan Road 2199 Waltham, MA 02451 2200 US 2202 Phone: +1 781-466-2362 2203 Email: andrew.g.malis@verizon.com 2205 Full Copyright Statement 2207 Copyright (C) The IETF Trust (2007). 2209 This document is subject to the rights, licenses and restrictions 2210 contained in BCP 78, and except as set forth therein, the authors 2211 retain all their rights. 2213 This document and the information contained herein are provided on an 2214 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2215 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2216 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2217 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2218 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2219 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2221 Intellectual Property 2223 The IETF takes no position regarding the validity or scope of any 2224 Intellectual Property Rights or other rights that might be claimed to 2225 pertain to the implementation or use of the technology described in 2226 this document or the extent to which any license under such rights 2227 might or might not be available; nor does it represent that it has 2228 made any independent effort to identify any such rights. Information 2229 on the procedures with respect to rights in RFC documents can be 2230 found in BCP 78 and BCP 79. 2232 Copies of IPR disclosures made to the IETF Secretariat and any 2233 assurances of licenses to be made available, or the result of an 2234 attempt made to obtain a general license or permission for the use of 2235 such proprietary rights by implementers or users of this 2236 specification can be obtained from the IETF on-line IPR repository at 2237 http://www.ietf.org/ipr. 2239 The IETF invites any interested party to bring to its attention any 2240 copyrights, patents or patent applications, or other proprietary 2241 rights that may cover technology that may be required to implement 2242 this standard. Please address the information to the IETF at 2243 ietf-ipr@ietf.org. 2245 Acknowledgment 2247 Funding for the RFC Editor function is provided by the IETF 2248 Administrative Support Activity (IASA).