idnits 2.17.00 (12 Aug 2021) /tmp/idnits45789/draft-berzin-malis-mpls-mobility-02.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 2384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2408. 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 non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 29, 2008) is 4945 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) -- Looks like a reference, but probably isn't: '1' on line 608 ** 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 (~~), 5 warnings (==), 8 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, 2009 Verizon Communications 5 October 29, 2008 7 Mobility Support Using MPLS and MP-BGP Signaling 8 draft-berzin-malis-mpls-mobility-02.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, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document describes a new approach to handling user mobility at 42 the network layer in the context of Multi-Protocol 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 Multi-Protocol 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.3.2.2. Explicit Prefix Registration . . . . . . . . . 30 84 3.1.4. Registration and Status - IPv6 . . . . . . . . . . . . 31 85 3.2. Integration with MP-BGP . . . . . . . . . . . . . . . . . 32 86 3.2.1. Mobility Address Family . . . . . . . . . . . . . . . 32 87 3.2.2. Mobility Bindings . . . . . . . . . . . . . . . . . . 34 88 3.2.3. Group Registration Management with MP-BGP . . . . . . 36 89 3.2.4. BGP Capability Advertisement . . . . . . . . . . . . . 39 90 3.3. Mobile Application Priority Indication and Recognition . . 39 91 3.4. Application Service Type Indication . . . . . . . . . . . 40 92 4. Network Update and Hand-off Processing . . . . . . . . . . . . 41 93 4.1. Network Update Modes and Types . . . . . . . . . . . . . . 41 94 4.1.1. Unsolicited Downstream Push Mode . . . . . . . . . . . 41 95 4.1.2. Selective Downstream Push Mode . . . . . . . . . . . . 41 96 4.1.3. Predictive Downstream Push Mode . . . . . . . . . . . 41 97 4.1.4. Hierarchical On-Demand Distribution Mode . . . . . . . 42 98 4.1.4.1. On-Demand Requests for Mobility Binding 99 Information . . . . . . . . . . . . . . . . . . . 42 100 4.1.5. Network Update Types . . . . . . . . . . . . . . . . . 45 101 4.1.5.1. Internal Update Type . . . . . . . . . . . . . . . 45 102 4.1.5.2. External Update Type . . . . . . . . . . . . . . . 45 103 4.1.6. Network Hierarchy Considerations . . . . . . . . . . . 45 104 4.1.7. Regionalization and Scalability . . . . . . . . . . . 46 105 4.1.7.1. Hierarchical Mobility Label Based Network 106 (H-MLBN) . . . . . . . . . . . . . . . . . . . . . 47 107 4.2. Hand-off Processing . . . . . . . . . . . . . . . . . . . 48 108 4.3. Micro-Mobility Handling . . . . . . . . . . . . . . . . . 49 109 4.3.1. Local Micro-Mobility . . . . . . . . . . . . . . . . . 50 110 4.3.2. Group Micro-Mobility . . . . . . . . . . . . . . . . . 50 111 5. Datagram Delivery . . . . . . . . . . . . . . . . . . . . . . 51 112 6. Security Considerations . . . . . . . . . . . . . . . . . . . 52 113 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 114 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 115 9. Patent Issues . . . . . . . . . . . . . . . . . . . . . . . . 55 116 10. Changes from Previous Revisions . . . . . . . . . . . . . . . 56 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 118 11.1. Normative References . . . . . . . . . . . . . . . . . . . 57 119 11.2. Informative References . . . . . . . . . . . . . . . . . . 57 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 121 Intellectual Property and Copyright Statements . . . . . . . . . . 60 123 1. Requirements notation 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2. Introduction 131 The requirements to support user mobility range from the physical 132 aspects of wireless access networks to the logical aspects of the 133 network control and forwarding plane operation. In the context of 134 this work the main requirement for the mobility support architecture 135 is to de-couple the network layer addressing and the associated 136 logical network topology from the ability of the network to optimally 137 deliver the packets to the mobile user. The optimal traffic delivery 138 is interpreted as the delivery of packets to the new node location 139 following the best (often the shortest in terms of the routing 140 protocol metrics) path between the mobile node and the correspondent 141 node. 143 The issue is that this optimal path cannot be used by the network to 144 communicate with the mobile user based on the IP address and routing 145 protocols. This is due to the inability of a conventional IP network 146 to react to the mobile user movements by adjusting the routing and 147 forwarding information in the network nodes (routers) to reflect the 148 new location of the mobile user with respect to the IP topology. 150 Thus a method is required to identify the logical location of the 151 user in the network topology in such a manner that the traffic 152 delivery to the user at a new location follows the optimal path in 153 the context of the routing protocol used in the network. A natural 154 fit to provide this method is the MPLS architecture. MPLS does not 155 perform the forwarding of IP traffic based on the IP addresses and 156 uses labels instead. The important point, however, is that MPLS by 157 itself cannot solve the mobility problem as ultimately the traffic 158 must originate from the source IP address and terminate at the 159 destination IP address (which would still be the old home address). 160 In order to use MPLS to forward the traffic to the new user location 161 along the optimal path the labels must be assigned specifically to 162 the mobile node at the new location and distributed to the network 163 nodes. These special labels are referred to as Mobility Labels and 164 are associated (bound) to the mobile node IP address. 166 This document proposes to use the Mobility Label as a second label in 167 the MPLS label stack. The first label in the stack is the one that 168 identifies the LSP (Label Switched Path) between the two Label Edge 169 Routers and the second label in the stack can be used to identify the 170 IP address of the mobile node and deliver the traffic to it. The 171 assignment and the distribution of the first label in the stack is 172 handled by the conventional MPLS architecture elements and protocols 173 such as LDP (Label Distribution Protocol [RFC5036]). It is proposed 174 that the assignment and distribution of the second label - the 175 Mobility Label - be based on the existing framework of MP-BGP (Multi- 176 Protocol Border Gateway Protocol [RFC4760]). The mobility management 177 scheme based on MP-BGP at the control plane level and MPLS at the 178 forwarding plane level represents a system in which both the control 179 and forwarding processes are integrated to ensure the optimal traffic 180 delivery that is not fully achieved in the existing network layer 181 mobility management approaches. 183 2.1. Architecture Requirements 185 Integrated Control and Forwarding Plane - the network update process 186 by the Control Plane must result in the optimal traffic delivery by 187 the Forwarding Plane. 189 Robust and Flexible Protocol Framework - Mobility Management Control 190 Plane Protocol and the associated functions must be placed at the 191 intelligent network edges and allow to avoid the need to involve all 192 nodes in the network (including the core nodes) in the network update 193 process. 195 Mobility Management Control Plane Protocol must allow for flexible 196 and seamless introduction of new features and for support for Mobile 197 Hosts and Mobile Routers. 199 Evolutionary Architecture and Implementation Approach - Mobility 200 Management scheme should be based as much as possible on the existing 201 network architectures and protocol framework. Only minimal changes 202 to the operation of mobile nodes should be expected. 204 Efficient Network Responsiveness - the impact on the mobile 205 application due to the service disruption caused by the mobile node's 206 movements and the associated network update and delivery processes 207 should be reasonably minimal. 209 Acceptable Network Scalability and Performance - the new requirements 210 for Mobility Management functions should not result in decreased 211 network scalability and performance. 213 2.2. Existing Solutions 215 2.2.1. Mobile IP 217 Mobile IP [RFC3344] was developed to provide macro mobility 218 management for the mobile hosts using IP version 4 (IPv4). It was 219 subsequently extended to support IPv6. Due to its complete reliance 220 on the logical network topology determined by the distribution of the 221 IP sub-nets Mobile IP solves the mobility problem by using the 222 following two major techniques: mobile node registration and traffic 223 tunneling. The main entities in Mobile IP are the Mobile Node (MN) 224 itself, the Correspondent Node (CN) - the host that is communicating 225 with the MN, the Home Agent (HA) - this is the router that owns the 226 original home sub-net to which the MN is assigned, the Foreign Agent 227 (FA) - this is the router that owns the sub-net to which the MN has 228 moved (the foreign sub-net), and finally the Care-of-Address (CoA) - 229 the IP address that belongs to the FA and that is used to represent 230 the MN while it is located in the foreign sub-net. The basic 231 mobility handling by Mobile IP results in a sub-optimal forwarding 232 path in the direction of traffic from the CN to the new location of 233 the MN. This is because the traffic is first sent to the HA and then 234 tunneled to the FA/MN. Although the route optimization scheme exists 235 where the mobility bindings are sent by the HA directly to the CN 236 with the CoA of the MN for direct traffic forwarding, it requires the 237 CN to i) implement the binding processing and ii) use IP tunneling to 238 send packets to the MN. 240 2.2.2. Mobile IPv6/HMIP/NEMO 242 Mobile IPv6 [RFC3775] provides macro-mobility support for IPv6. It 243 improves Mobile IPv4 by eliminating the need for the FA, use of the 244 IPv6 neighbor discovery instead of ARP, use of the IPv6 Link Local 245 (LLOC) address instead of CoA. It also provides basic support for 246 mobile routers via NEMO (Network Mobility) [RFC3963] and enables 247 hierarchical mobility management (HMIP). However MIPv6 does not 248 provide for the integration of the control and forwarding planes and 249 still requires the use of the HA which results in sub-optimal traffic 250 routing. The routing optimization based on the direct binding 251 exchange between the CN and the MN resolves the sub-optimal routing 252 but introduces the requirement for the return routability procedure 253 and the use of a special IPv6 routing header (similar in function to 254 IPv4 tunneling) directly on the CN and MN. In addition, Hierarchical 255 MIPv6 requires registrations to multiple entities (MAP - Mobility 256 Anchor Point, HA) and supports IPv6 only. 258 2.2.3. MPLS Micro-Mobility 260 MPLS Micro-Mobility [MM-MPLS] integrates MIP and MPLS traffic 261 forwarding to provide a solution in which MIP is used for macro 262 mobility management and MPLS is used to support micro-mobility. 263 Micro-mobility reflects the mobile host movements that can be handled 264 without the re-registration with the MIP HA. To achieve this, the MN 265 registers with a hierarchical set of Label Edge Mobility Agents 266 (LEMA). The LEMA at the top of the hierarchical set is registered 267 with the MIP HA as the FA for the MN. The MIP HA tunnels all packets 268 from the CN to the MN to the top level LEMA as in regular MIP. The 269 LEMA then sends packets on the MPLS LSP to the network location of 270 the MN using MPLS labels. As the MN moves to new locations, the 271 hand-off procedures are invoked that start with the MN requesting the 272 hand-off and the LEMA(s) performing the set of signaling steps 273 resulting in the redirection of the MPLS LSP from the old serving 274 LEMA to the new serving LEMA. If the MN movement results in a 275 condition in which the old top level LEMA can no longer serve the MN, 276 the MN re-registers with the new hierarchical set of LEMA(s) and the 277 top level LEMA is registered as the FA with the Mobile IP HA. 278 Although MPLS Micro-Mobility makes use of the MPLS traffic forwarding 279 it still is an extension of Mobile IP and therefore does not result 280 in the elimination of triangular routing. 282 2.3. Protocol Overview 284 MP-BGP and its ability to carry the overlay MPLS label information 285 [RFC3107] is proposed for the mobility management. Namely when the 286 mobile hosts or routers change their network locations they can 287 register with the edge nodes of the MPLS network (LER) and at that 288 time assigned Mobility Labels. The Mobility Labels in turn are 289 associated with the IP addresses of mobile hosts or routers thus 290 forming the Mobility Bindings. These Mobility Bindings are then 291 encoded in the Multi-Protocol BGP Address Family messaging structure 292 and are distributed among the rest of the MPLS network LER nodes 293 using the MP-BGP protocol. The Mobility Binding provides an explicit 294 association between the overlay MPLS label and a single or multiple 295 individual IP addresses of mobile hosts or IP address ranges 296 (prefixes) that are served by mobile routers. The MP-BGP NEXT_HOP 297 attribute associated with the BGP UPDATE message [RFC4271] used to 298 carry the Mobility Binding provides an implicit association between 299 the overlay Mobility Label and the infrastructure MPLS label that is 300 in turn associated with the LSP to reach the LER that sourced the 301 Mobility Binding. The MPLS LER capability to provide mobility 302 support can be referred to as the Mobility Support Function (MSF) 303 (see Section 3). The MSF includes: a) Mobile Host/Router Discovery, 304 Registration and Status Procedures, b) Mobility Label Association and 305 de-Association Procedures, c) Integration with MP- BGP and d) Mobile 306 Application Priority Indication and Recognition. Please see [MLBN]. 308 2.4. Architecture Overview 310 This mobility architecture is proposed in the context of MPLS 311 networks. As such it is a requirement of this architecture that all 312 nodes in the network support MPLS control and forwarding plane 313 procedures and in particular it is a further requirement that the 314 edge nodes of the MPLS network implement the Mobility Support 315 Function described in Section 3. This architecture does not rely on 316 Mobile IP for macro-mobility support. In other words there is no 317 concept of a home network that the mobile node belongs to and 318 therefore there is no requirement to register with the Home Agent. 319 It is the assumption of this architecture that a mobile host or 320 router is always identified as being in the foreign network thus 321 always requiring mobility support. In addition, there is no 322 requirement for the CoA. 324 The simplest way to implement this assumption is to administratively 325 allocate a range of IP addresses for all mobile hosts and routers of 326 an organization and to implement in the MSF the configurable ability 327 to recognize the pre-allocated mobility address ranges. As such, a 328 service provider would assign IP addresses to all of their mobile 329 subscribers from a pre-allocated address range. This range does not 330 have to be flat and can be in turn sub-netted. The IPv4 or IPv6 331 mobility address pre-allocation scheme allows utilization of this 332 mobility management architecture as a separate overlay MPLS service. 333 The only requirement related to the LER MSF pre-configuration is the 334 static identification of the overall mobility address range in the 335 scope of the LER-wide MSF. 337 Regardless of the static identification of the overall address range 338 allocated to the mobile devices, the individual mobile nodes identify 339 themselves dynamically to the MSF. This capability is especially 340 useful when this architecture is applied to provide mobility support 341 to both mobile hosts and routers. Specifically, during the 342 registration procedure a mobile node could identify itself as either 343 a mobile host or a mobile router. If it is a mobile router the MSF 344 is expected to establish a routing protocol adjacency with the mobile 345 router as well as to utilize an extended Mobility Binding structure 346 in which multiple IP prefixes served by the mobile router may be sent 347 in a single Mobility Binding optionally associated with a single 348 Mobility Label. 350 The mobile node must always register with the serving MSF and thus be 351 associated with the Mobility Label. This requirement will support 352 the ability to implement specific mobility features such as the 353 application sensitivity recognition via the processing prioritization 354 scheme. 356 2.4.1. Node Roles 358 From the network architecture perspective the proposed mobility 359 solution follows the classical MPLS network architecture with two 360 major node classes: LSR and LER also known as P and PE respectively. 361 The LER (PE) nodes reside at the edges of the network and perform the 362 corresponding edge functions such as the customer interface 363 management, label stack imposition/deposition and label information 364 distribution for both the infrastructure MPLS transport and the 365 overlay MPLS services. In addition to these edge functions we 366 introduce the Mobility Support Function that integrates directly with 367 the LER control plane responsible for the overlay MPLS services. The 368 role of the LSR (P) nodes remains exactly the same as in the 369 classical MPLS architecture - participate in the infrastructure label 370 distribution process and switch traffic based on the MPLS labels 371 (outer labels) between the LER nodes. The LSR (P) nodes need not 372 implement the MSF. Other aspects of the architecture include the 373 access interface, the interface to other networks and the network 374 hierarchy. 376 2.4.2. Attachment Options 378 The two major access interface options considered here are: Direct 379 Attachment of the LER node to the Radio Access Network and Indirect 380 Attachment of the LER node to the Radio Access Network. The terms 381 direct and indirect are not used to indicate that the LER node has or 382 does not have the integrated wireless radio interface. The term 383 direct is used to reflect that a direct layer 2 path exists between 384 the mobile node and the MSF enabled LER either via the integrated 385 radio interface or via the wire-line grooming network to the wire- 386 line side of the Radio Access Network Base Stations. The term 387 Indirect is used to reflect that there is no direct layer 2 path 388 between the Radio Access Network and the MSF enabled LER node. The 389 Indirect Attachment means that there is another layer 3 device (such 390 as the Customer Edge - CE router in the MPLS Architecture 391 terminology) between the MSF enabled LER and the Radio Access 392 Network. The CE router in turn connects to the Radio Network via 393 Direct Attachment (in the sense of the term defined here) by using 394 the integrated wireless interface or by using the wire-line grooming 395 network. The reason for establishing these two access options 396 relates to the type of service environments that the proposed 397 architecture will most likely be applicable to. 399 The Direct Attachment option is most suitable for the use case where 400 mobility is offered as an overlay service in a service provider's 401 mobility enabled MPLS network. In this case the Mobility Support 402 Function may be viewed as one of the functions in the MPLS for Mobile 403 Networks Architecture. An example of such a use case is the Wireless 404 Telephone service with data or multi-media capabilities (such as 405 EV-DO) in which mobility management is handled by the MSF enabled 406 MPLS network. The mobile nodes may be the wireless telephone sets 407 with IPv4 or IPv6 stacks and the corresponding mobility addresses 408 assigned by the service provider, communicating via the Radio Access 409 Network Base Stations to the MSF enabled LER nodes. A simple 410 registration procedure triggers the assignment of the overlay 411 Mobility Labels and the subsequent mobility management by MP-BGP. 413 The Indirect Attachment option is most suitable when the mobility 414 service is integrated with other overlay MPLS services such as Layer 415 3 VPN [RFC4364]. This use case is applicable for the enterprise 416 networking where the mobile nodes can be the wireless workstations or 417 wireless IP telephones, and the enterprise sites connecting to the 418 service provider's mobility enabled MPLS network via the CE routers. 419 The simplest way to accommodate the presence of the CE routers is to 420 implement the MSF function on the CE router and use the MP-BGP and 421 Mobility Labels between the CE router and the LER (PE) router in the 422 context of the customer specific MPLS VPN. This also implies the use 423 of MPLS and MP-BGP between the CE and PE routers for the delivery of 424 traffic to the mobile nodes behind the CE router, but since there 425 will be no LSR (P) routers between the MSF enabled CE and the PE 426 router there is actually no need for the outer stack MPLS labels and 427 therefore no need to integrate the CE routers with the service 428 provider's MPLS infrastructure. The MPLS LER (PE) router will need 429 to accept the Mobility Binding information via the use of MP-BGP from 430 the CE router within the MPLS VPN and then propagate that information 431 into the MPLS network using the L3 VPN MPLS overlay service also 432 based on MP-BGP. 434 The direct attachment option is shown in Fig.1, where a MSF enabled 435 LER node interfaces with multiple Radio Cells or Cell Clusters via 436 the L2 network such as Ethernet. Each Radio Cell Cluster is assigned 437 into a L2 Virtual LAN and associated with a L3 sub-net that is 438 terminated at a logical interface of the LER node. The logical 439 interfaces are controlled by the MSF and the associated set of Radio 440 Cells or Clusters forms a Mobility Region. 442 In Fig. 2 a similar arrangement is illustrated but in this case there 443 is no direct L2 path between the Radio Access Network and the MPLS 444 edge. A CE router provides the MSF and communicates the Mobility 445 Binding information by means of MP-BGP to the MPLS LER (PE) router. 447 +-----+ 448 |MSF ++-----------+ +------------+ 449 Radio Cell +----++ | | | 450 ,-----. | LER ........MPLS Network 451 / \ | | | | 452 / ((++)) \ +--+-+-++-+-++ +------------+ 453 ( || ) L3 Logical Interfaces 454 ,----+. +`-._/ / / / / / / 455 / \ /`-. +--+-+-+-+-+-++ 456 / ((++))`+----' `+._ / / /| /| .-----, 457 ( || ,-----. ___|___ / / / `-. / \ 458 \ ++--''''''''' | / | `-. |`. / ((++)) \ 459 \ // ((++)) \ |.-' `. `-. `-. || ) 460 `----(' || .-'+--------+----+`-.\ `-.+ .+----, 461 \ +_.-'/ L2 Network `+. / \ 462 \ / \ ``-.-+'((++)) \ 463 `-----' `. .----`-. || ) 464 Base Station \ / \\`-.+ / 465 `. ((++)) \\ / 466 ( \ || `)----' 467 \ `.++ / 468 \ / 469 `-----' 470 Base Station 472 Direct Attachment Option 474 Figure 1 476 +-----+ 477 |MSF ++-----------+ +-----------+ 478 Radio Cell +----++ | MP-BGP+| | 479 ,-----. | CE .......... MPLS LER | 480 / \ | |Mobility| | 481 / ((++)) \ +--+-+-++-+-++ +-----------+ 482 ( || ) L3 Logical Interfaces 483 ,----+. +`-._/ / / / / / / 484 / \ /`-. +--+-+-+-+-+-++ 485 / ((++))`+----' `+._ / / /| /| .-----, 486 ( || ,-----. ___|___ / / / `-. / \ 487 \ ++--''''''''' | / | `-. |`. / ((++)) \ 488 \ // ((++)) \ |.-' `. `-. `-. || ) 489 `----(' || .-'+--------+----+`-.\ `-.+ .+----, 490 \ +_.-'/ L2 Network `+. / \ 491 \ / \ ``-.-+'((++)) \ 492 `-----' `. .----`-. || ) 493 Base Station \ / \\`-.+ / 494 `. ((++)) \\ / 495 ( \ || `)----' 496 \ `.++ / 497 \ / 498 `-----' 499 Base Station 501 In-Direct Attachment Option 503 Figure 2 505 2.4.3. Network Hierarchy 507 The distribution of the Mobility Binding information using MP-BGP may 508 be achieved by constructing a flat or hierarchical MP-BGP peering 509 topology among the participating LER nodes. The flat peering logical 510 structure requires a full mesh of MP-BGP sessions and the 511 hierarchical peering structure can make use of the BGP Route 512 Reflectors in which some LER nodes are designated as the Route 513 Reflectors and establish peering sessions between themselves and all 514 other LER supporting MSF (Route-Reflector-Clients). The BGP Route 515 Reflectors capable of supporting MPLS Mobility are referred to as 516 Mobility Route Reflectors. It is important to note that the Mobility 517 Route Reflectors need not support the MSF but must be able to 518 interpret and relay the MSF related MP-BGP messaging. 520 2.4.4. Interface to Other Networks 522 The interface to other networks depends on how the mobility is to be 523 managed between the interconnecting networks. If all mobility 524 functions are to be managed by a service provider's network (given 525 that the network has sufficient coverage) then the interface to other 526 networks can be as simple as the peering gateway node that connects 527 the service provider's MPLS network to the rest of the world. In 528 this case there is no need to extend the MPLS processing over this 529 interface, and since by construction all mobility IP addresses belong 530 to the IP address space of the service provider, the general peering 531 arrangement to other networks where the IP address range of the 532 service provider is advertised out to the Internet will enable the 533 communication between the mobile nodes and the outside destinations. 534 In case of the mobile node roaming, this may be supported between the 535 service provider networks that both implement the customer facing 536 Mobility Support Function and the Network-to-Network Interface (NNI) 537 that employs the use of MPLS label exchange (including the Mobility 538 Labels). 540 3. Mobility Support Function 542 This section describes the proposed set of functional elements of the 543 MPLS LER node capable of providing mobility management services. 544 This document refers to these functional elements as a Mobility 545 Support Function (MSF). 547 3.1. Mobile Node Discovery, Registration and Status 549 3.1.1. Discovery Process - IPv4 551 As in [RFC3344] the discovery of the MSF by the mobile nodes is based 552 on the ICMP Router Discovery [RFC1256] with specific extensions for 553 Mobility Label Based Network (MLBN). The format of the extensions 554 used in this proposal also follows the [RFC3344] section 1.9. 556 The discovery process should be initiated by a mobile host or router 557 by sending the ICMP Router Solicitation message with MLBN MSF 558 Discovery Extension and the TTL set to 1. This ICMP message along 559 with the MLBN Extension is referred to as the MSF Discovery message. 560 The MSF Discovery message should carry the information about the type 561 of the mobile node: Mobile Host or Mobile Router. 563 Upon receipt of the MSF Discovery message the MSF LER must respond 564 with the ICMP Router Advertisement including the MLBN specific 565 Extension. This message is referred to as the MSF Advertisement. 566 The MSF Advertisement will carry different information depending on 567 the type of the mobile node and the registration mode. 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Type | Code | Checksum | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Reserved | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | MSF Discovery Extension TLV (variable) | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 ICMP Router Solicitation with MSF Discovery Extension 581 Figure 3 583 Link Layer Fields: Destination Address - This should be the 584 multicast or broadcast Link Layer Address. 586 IP Fields: Source Address - IP Address of the Mobile Host or IP 587 address of the interface of the Mobile Router from which this 588 message is sent. 590 Destination Address - This is the all-routers multicast address 591 224.0.0.2 or the limited broadcast address 255.255.255.255. 593 TTL - TTL should be set to 1. 595 ICMP Fields: Type = 10 Router Solicitation. 597 Code = 1 MLBN MSF Discovery Extension included. 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Type | Code | Checksum | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Num Addrs |Addr Entry Size| Lifetime | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Router Address[1] | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Preference Level[1] | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | MSF Advertisement Extension (variable) | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 ICMP Router Advertisement with MSF Advertisement Extension 615 Figure 4 617 Link Layer Fields: Destination Address - This should be the source 618 address used to deliver the MSF Discovery message from the mobile 619 node. 621 IP Fields: Source Address - IP Address of the MSF. 623 Destination Address - This is the unicast IP address used in the 624 IP header of the MSF Discovery message from the mobile node. 626 TTL - TTL should be set to 1. 628 ICMP Fields: Type = 9 Router Advertisement. 630 Code = 1 MLBN MSF Advertisement Extension included. 632 Please refer to [RFC1256] for the specification of the remaining 633 fields in both of the above messages. 635 3.1.1.1. MSF Discovery by Mobile Hosts - IPv4 637 Mobile hosts should initiate the MSF Discovery process by sending the 638 MSF Discovery message. The MSF Discovery Extension format for Mobile 639 Hosts is shown below. 641 0 1 2 3 642 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 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Type | Length |H|Pri. |L|ASTI | Area_ID | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Mobile Host IPv4 Source Address | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Correlation ID | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 Mobile Host MSF Discovery Extension for IPv4 653 Figure 5 655 Type - 0 = MSF Discovery 657 Length - Length of the message in octets. 659 H - Mobile Node Type Indication. 0 = Mobile Host. 661 Pri. - A 3-bit Priority Code (0-7). 663 L - Lightweight Registration Requested (1). 665 ASTI - Application Service Type Indication. This 3-bit field may 666 be used to indicate to the MSF what type of service is to be used 667 by the mobile host. For example, "Internet Access Only" or Full 668 Mobile-to-Mobile Routing". This indication can then be mapped to 669 the Network Update Mode Code used in the Mobility Binding 670 structure. 672 Area_ID - An Identifier (1-255) associated with the Area Mobility 673 Route Reflector. Area_ID=0 must be used for initial registrations 674 by mobile nodes. 676 Correlation ID - a number used to keep track of the Lightweight 677 Registration message pairs - MSF Discovery/MSF Advertisement. 679 3.1.1.2. MSF Discovery by Mobile Routers - IPv4 681 Mobile routers should initiate the MSF Discovery process by sending 682 the MSF Discovery message. The MSF Discovery Extension format for 683 Mobile Routers is shown below. 685 0 1 2 3 686 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 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Type | Length |R|Pri. |L|Res. | Area_ID | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Mobile IPv4 Router-ID | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Mobile Router MSF Discovery Extension 695 Figure 6 697 Type - 0 = MSF Discovery 699 Length - Length of the message in octets. 701 R - Mobile Node Type Indication. 1 = Mobile Router. 703 Pri. - A 3-bit Priority Code (0-7). 705 L - Always set to 0 in the MSF Discovery sent by a mobile router. 707 Res. - Reserved. 709 Area_ID - An Identifier (1-255) associated with the Area Mobility 710 Route Reflector. Area_ID=0 must be used for initial registrations 711 by mobile nodes. 713 3.1.1.3. MSF Advertisement - IPv4 715 After receiving the MSF Discovery message from a mobile host or 716 router the MSF should reply with the MSF Advertisement message using 717 extension format shown below. 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Type | Length | Sequence Number | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Registration Lifetime |L|R|G|Reserved | Group ID | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | MSF IP Address | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | MSF Virtual Link Layer Address (first 32 bits) | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 |Last 16 bits | Reserved | Area_ID | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Correlation ID | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 MSF Advertisement Extension 737 Figure 7 739 Type - 1 = MSF Advertisement 741 Length - Length of the message in octets. 743 Sequence Number - The sequence number of the MSF Advertisement 744 message sent since the MSF is operational. 746 Registration Lifetime - the time in seconds until the registration 747 entry in the MSF database expires. 749 L - Lightweight Registration Confirmed (1). 751 R - Full Registration Required (1). 753 G - Group Registration Supported (1). 755 Group ID - Unique Registration Group Number. Should be zero if G 756 = 0 758 MSF IP Address - Virtual IP Address of the MSF (may be different 759 from any particular MSF LER interface IP address 761 MSF Virtual Link Layer Address - a MAC address shared and 762 recognized by all MPLS LER interfaces participating in the MSF. 763 This address may specifically be used to support Local Micro- 764 Mobility (see Section 4.3.1). 766 Area_ID - An Identifier (1-255) associated with the Area Mobility 767 Route Reflector. Area_ID=0 must be used for initial registrations 768 by mobile nodes. 770 Correlation ID - a number used to keep track of the registration 771 requests and the corresponding reply message pairs. 773 The MSF Advertisement should be sent to the unicast link layer 774 address and the unicast IP address of the mobile host or router that 775 were used in the MSF Discovery link layer header and the MSF 776 Discovery Extension payload respectively. 778 Upon receipt of the MSF Advertisement mobile hosts should continue to 779 send the MSF Discovery messages with the interval of 1/3 of the 780 specified Registration Lifetime. The MSF should send the MSF 781 Advertisements in response to the periodic MSF Discovery messages 782 from the mobile hosts using the corresponding Correlation IDs. If a 783 mobile host does not get responses to three MSF Discovery messages 784 (serving as the keepalives) the mobile host should initiate a new MSF 785 Discovery process using a new Correlation ID. 787 If the L flag in the MSF Advertisement is set, and the R flag is not, 788 indicating the Lightweight Registration mode (see Section 3.1.3.1), 789 the mobile hosts may start sending datagrams to their IP destinations 790 using the link layer address of the MSF. The L and R flags are 791 mutually exclusive and cannot be set at the same time. 793 If the R flag is set in the MSF Advertisement, indicating that 794 explicit registration is required, mobile hosts should transition to 795 the Full Registration mode (see Section 3.1.3.1.2). 797 The R flag must always be set in the MSF Advertisement if it is in 798 reply to the MSF Discovery sent by a mobile router. Upon receipt of 799 the MSF Advertisement a mobile router must transition to the Routing 800 Adjacency Establishment mode (see Section 3.1.3.2). 802 3.1.2. Discovery Process - IPv6 804 The MSF discovery process for IPv6 is identical to the discovery 805 process for IPv4 with the exception of the use of IPv6 specific 806 Router Solicitation and Advertisement messages based on ICMPv6 807 [RFC4443]. These messages are specified in [RFC4861]. As in the 808 IPv4 case the Router Solicitation and Advertisement messages carry 809 the MLBN extensions and are termed the MSF Discovery and the MSF 810 Advertisement respectively. 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Type | Code | Checksum | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Reserved | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | MSF Discovery Extension TLV (variable) | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 IPv6 Router Solicitation with MSF Discovery Extension 824 Figure 8 826 Link Layer Fields: Destination Address - This should be the 827 multicast or broadcast Link Layer Address. 829 IP Fields: Source Address - IP Address of the Mobile Host or IP 830 address of the interface of the Mobile Router from which this 831 message is sent. 833 Destination Address - This is the all-routers multicast address 834 FF02::2 836 ICMP Fields: Type = 133 Router Solicitation. 838 Code = 1 MLBN MSF Discovery Extension included. 840 0 1 2 3 841 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 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Type | Code | Checksum | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Reachable Time | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Retrans Timer | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | MSF Discovery Extension TLV (variable) | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 IPv6 Router Advertisement with MSF Advertisement Extension 856 Figure 9 858 Link Layer Fields: Destination Address - This should be the source 859 address used to deliver the MSF Discovery message from the mobile 860 node. 862 IP Fields: Source Address - IP Address of the MSF. 864 Destination Address - This is the unicast IP address used in the 865 IP header of the MSF Discovery message from the mobile node. 867 ICMP Fields: Type = 134 Router Advertisement. 869 Code = 1 MLBN MSF Advertisement Extension included. 871 Please refer to [RFC4861] for the specification of the remaining 872 fields in both of the above messages. 874 3.1.2.1. MSF Discovery by Mobile Hosts - IPv6 876 The MSF Discovery message format for IPv6 mobile hosts is identical 877 to the IPv4 message with the IPv6 Source Address used instead of the 878 IPv4 (see Section 3.1.1.1). 880 3.1.2.2. MSF Discovery by Mobile Routers - IPv6 882 The MSF Discovery message format for IPv6 mobile routers is identical 883 to the IPv4 message with the IPv6 Router ID used instead of the IPv4 884 (see Section 3.1.1.2). 886 3.1.2.3. MSF Advertisement - IPv6 888 The MSF Advertisement message format for IPv6 is identical to the 889 IPv4 message format (see Section 3.1.1.3). 891 3.1.3. Registration and Status - IPv4 893 3.1.3.1. Mobile Host Registration - IPv4 895 3.1.3.1.1. Lightweight Registration - IPv4 897 MLBN eliminates the need for the registrations with the Home Agent 898 and Care-of-Addresses. This makes it possible to implement a 899 Lightweight Registration procedure which is simply the completion of 900 the MSF Discovery process (Section 3.1.1). The Lightweight 901 Registration is indicated by the presence of the L flag in the MSF 902 Advertisement message. With the Lightweight Registration the MSF 903 should allocate the local Mobility Label and create the Mobility 904 Binding structure (Section 3.2.2) immediately following the receipt 905 of the MSF Discovery message from a mobile host. The MSF should also 906 initiate the network update process (see Section 4) based on the 907 selected update mode and the indicated mobile application priority. 909 The network update mode selection may be based on the Application 910 Service Type Indication (ASTI) from the MSF discovery message sent by 911 the mobile host. ASTI is a 3-bit field that may be used to indicate 912 to the MSF what type of service is to be used by the mobile host. 913 For example, "Internet Access Only" or "Full Mobile-to-Mobile 914 Routing". This indication can then be mapped to the Network Update 915 Mode Code used in the Mobility Binding structure. 917 3.1.3.1.2. Full Registration - IPv4 919 Full Registration is a registration mode which allows to perform 920 additional functions as part of the registration process. An example 921 of such function is the Mobile Host Authentication. Full 922 registration mode is indicated in the MSF Advertisement by setting 923 the R flag. 925 Full Registration messaging makes use of the UDP port RRR and may 926 provide a mechanism for various functional extensions. Full 927 Registration uses two message types: 929 Registration Request - Type 1 931 Registration Reply - Type 2 933 The Registration Message formats are shown below. 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Type | Length |H| Rri.|ASTI | Area_ID | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Mobile Host IPv4 Source Address | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | MSF Address | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Correlation ID | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Extensions 947 +-+-+-+-+-+-+.... 949 Full Registration Request 951 Figure 10 953 Type - 1 = Full Registration Request 955 Length - Length of the message in octets. 957 H - Mobile Node Type Indication. 0 = Mobile Host 959 Pri. - A 3-bit priority code (0-7). 961 ASTI - Application Service Type Indication. This 3-bit field may 962 be used to indicate to the MSF what type of service is to be used 963 by the mobile host. For example, "Internet Access Only" or Full 964 Mobile-to-Mobile Routing". This indication can then be mapped to 965 the Network Update Mode Code used in the Mobility Binding 966 structure. 968 Area_ID - An Identifier (1-255) associated with the Area Mobility 969 Route Reflector. Area_ID=0 must be used for initial registrations 970 by mobile nodes. 972 Correlation ID - a number used to keep track of the registration 973 requests and the corresponding reply message pairs. 975 0 1 2 3 976 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 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Type | Length | Flags | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Registration Lifetime | Reserved | Area_ID | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Mobile Host IPv4 Source Address | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | MSF IP Address | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | MSF Virtual Link Layer Address (first 32 bits) | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 |Last 16 bits | Reserved | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Correlation ID | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Extensions 993 +-+-+-+-+-+-+.... 995 Full Registration Reply 997 Figure 11 999 Type - 2 = Full Registration Reply 1001 Length - Length of the message in octets. 1003 Flags - To be defined 1005 Registration Lifetime - the time in seconds until the registration 1006 entry in the MSF database expires. 1008 Area_ID - An Identifier (1-255) associated with the Area Mobility 1009 Route Reflector. Area_ID=0 must be used for initial registrations 1010 by mobile nodes. 1012 MSF IP Address - Virtual IP Address of the MSF (may be different 1013 from any particular MSF LER interface IP address 1015 MSF Virtual Link Layer Address - a MAC address shared and 1016 recognized by all MPLS LER interfaces participating in the MSF. 1017 This address may specifically be used to support Local Micro- 1018 Mobility (see Section 4.3.1). 1020 Correlation ID - a number used to keep track of the registration 1021 requests and the corresponding reply message pairs. 1023 3.1.3.1.3. Group Registration - IPv4 1025 Clearly the discovery and registration procedure has a great effect 1026 on the network responsiveness especially when a mobile host moves 1027 from one serving MSF to another. The following enhanced registration 1028 scheme can be implemented to simplify the registrations resulting 1029 from the MSF-to-MSF hand-off and therefore improve the network 1030 responsiveness. We refer to it as the Group Registration. 1032 The entire MPLS edge network may be divided in groups or regions 1033 containing the geographically close MSF enabled LER nodes. Each 1034 group should be assigned a unique Group ID (1-255). The mobile host 1035 will register with a LER node within a group using a Group 1036 Registration procedure. The LER node will distribute the 1037 registration information to the rest of the group members using the 1038 established MP-BGP peering sessions. These messages may be coded as 1039 another type of the NLRI in the Address Family structure. The size 1040 of the region should be large enough to ensure a high probability 1041 that the range of movements of a mobile host will be covered by the 1042 service area of the group but at the same time not too large to avoid 1043 a large registration table size shared among the group members. The 1044 group members can be identified administratively and preconfigured in 1045 the MSF serving LER nodes. 1047 During the initial registration process and as part of the 1048 registration acknowledgement the serving LER may indicate to the 1049 mobile host that it is registered to a group and from now on should 1050 use a group virtual link layer address and a group virtual IP address 1051 for further communications (the addresses may be communicated in the 1052 acknowledgement payload). 1054 The group registration allows to implement the implicit logic by 1055 which no further registrations are required from the mobile node due 1056 to its movements once the initial group registration has been 1057 established. The group members may also pre-allocate the Mobility 1058 Labels and have them ready in case the mobile node moves into the 1059 member's serving area. Once the mobile node has moved into the 1060 serving area of the new MSF group member it continues to send packets 1061 to the group virtual link layer address and the virtual IP address. 1062 As soon as the packet from the mobile node is received by the group 1063 member it will forward the packet to its destination and distribute 1064 the new Mobility Binding to the network. A mobile host should 1065 continue to send the MSF Discovery messages destined to the group 1066 link layer address in order to keep the group registration active. 1068 The group member that is servicing the mobile host can periodically 1069 send the registration update messages to the group members in order 1070 to keep the Mobility Bindings in the standby status. If a group 1071 member has not received any keepalives or packets from the mobile 1072 host in a specified period of time it should silently deactivate its 1073 local registration entry and release the Mobility Label. If the 1074 mobile host happens to be serviced by another group member, this 1075 member will be sending the registration update messages to the group 1076 keeping the registration active. If no group member hears from the 1077 mobile node, the registration must be removed from the group database 1078 after a specified time and the associated Mobility Binding may be 1079 withdrawn from the network by means of the MP-BGP update. 1081 Group Registration message formats are very similar to the Full 1082 Registration message formats. The Group Registrations starts with 1083 the mobile host sending the MSF Discovery message and the MSF 1084 replying with the MSF Advertisement having the G flag set, indicating 1085 that the Group Registration is supported. After this the mobile host 1086 must transition to the Group Registration protocol using the same UDP 1087 port RRR as for the Full Registration. 1089 Group Registration uses two message types: 1091 Group Registration Request - Type 3 1092 Group Registration Reply - Type 4 1094 The Group Registration Message formats are shown below. 1096 0 1 2 3 1097 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 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Type | Length |H| Rri.|ASTI |G| Group ID | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Mobile Host IPv4 Source Address | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | MSF Address | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Correlation ID | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Area_ID | Extensions 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+.... 1110 Group Registration Request 1112 Figure 12 1114 Type - 3 = Group Registration Request 1116 Length - Length of the message in octets. 1118 H - Mobile Node Type Indication. 0 = Mobile Host 1120 Pri. - A 3-bit priority code (0-7). 1122 ASTI - Application Service Type Indication. This 3-bit field may 1123 be used to indicate to the MSF what type of service is to be used 1124 by the mobile host. For example, "Internet Access Only" or Full 1125 Mobile-to-Mobile Routing". This indication can then be mapped to 1126 the Network Update Mode Code used in the Mobility Binding 1127 structure. 1129 G - Group Registration Requested (1) 1131 Group ID - Unique Registration Group Number. Should be zero if G 1132 = 0 1134 Correlation ID - a number used to keep track of the registration 1135 requests and the corresponding reply message pairs. 1137 Area_ID - An Identifier (1-255) associated with the Area Mobility 1138 Route Reflector. Area_ID=0 must be used for initial registrations 1139 by mobile nodes. 1141 0 1 2 3 1142 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 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Type | Length | Flags | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Registration Lifetime |G| Reserved | Group ID | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | Mobile Host IPv4 Source Address | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Group Virtual IP Address | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | Group Virtual Link Layer Address (first 32 bits) | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 |Last 16 bits | Reserved | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Correlation ID | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | Area_ID | Extensions 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.... 1161 Group Registration Reply 1163 Figure 13 1165 Type - 4 = Group Registration Reply 1167 Length - Length of the message in octets. 1169 Flags - To be defined 1171 Registration Lifetime - the time in seconds until the registration 1172 entry in the MSF database expires. 1174 G - Group Registration Supported (1). 1176 Group ID - Unique Registration Group Number. Should be zero if G 1177 = 0 1179 Group Virtual IP Address - Virtual IP Address that is supported by 1180 all MSF's that belong to the Registration Group identified by the 1181 Group ID. This address may specifically be used to support Group 1182 Micro-Mobility (see Section 4.3.2). 1184 Group Virtual Link Layer Address - a MAC address shared and 1185 recognized by all MPLS LER interfaces of all MSF's that belong to 1186 the Registration Group identified by the Group ID. This address 1187 may specifically be used to support Group Micro-Mobility (see 1188 Section 4.3.2). 1190 Correlation ID - a number used to keep track of the registration 1191 requests and the corresponding reply message pairs. 1193 Area_ID - An Identifier (1-255) associated with the Area Mobility 1194 Route Reflector. Area_ID=0 must be used for initial registrations 1195 by mobile nodes. 1197 As in the Full Registration case the Group Registration allows to 1198 perform additional functions as part of the registration process by 1199 means of using the functional extensions. An example of such a 1200 function is the Mobile Host Authentication. 1202 After the completion of the Group Registration with the initial MSF 1203 that is part of the Registration Group, the mobile host must send the 1204 MSF Discovery messages destined to the Group Virtual Link Layer 1205 Address listing the Group ID and the Group Virtual IP Address. The 1206 registration information is communicated among the group members 1207 using MP-BGP signaling with the specific SAFI value assigned for this 1208 purpose (see Section 3.2.3). Any group member receiving the MSF 1209 Discovery messages from a mobile host for which the group 1210 registration is active must reply with the MSF Advertisement messages 1211 to the mobile host. When a mobile host moves from one group member 1212 to another it should continue to send packets to its IP destination 1213 using the Group Virtual Link Layer Address. 1215 3.1.3.2. Mobile Router Registration - IPv4 1217 Mobile routers should initiate the registration procedure by sending 1218 the registration message with the mobile router identification flag 1219 set and its Router ID (an IP address that belongs to the router) 1220 specified (see Section 3.1.1.2). 1222 Upon receipt of this registration information the MSF should initiate 1223 the establishment of the dynamic routing protocol adjacency with the 1224 mobile router using protocols such as BGPv4 [RFC4271]. The mobile 1225 router should advertise to the MSF the IP prefixes it serves using 1226 the established routing adjacency. 1228 3.1.3.2.1. Routing Adjacency Establishment 1230 The MSF should receive the routing protocol update from the mobile 1231 router and allocate a single Mobility Label to represent all of the 1232 served prefixes. This label should then be used in the Mobility 1233 Binding structure exported to the network by MP-BGP (see Figure 19). 1234 Optionally, each served IP prefix advertised by the mobile router can 1235 be associated with a separate Mobility Label. This can be used to 1236 provide different mobility processing priority to different IP 1237 prefixes. 1239 The mobile router status detection can be based on the state of the 1240 dynamic routing protocol adjacency maintained by the periodic 1241 keepalive messaging common to the routing protocols. 1243 3.1.3.2.2. Explicit Prefix Registration 1245 In some cases it is not desirable to establish a dynamic routing 1246 protocol adjacency between a mobile router and the MSF LER due to the 1247 considerations related to the conservation of RAN resources required 1248 to support the maintenance of the adjacency (e.g. periodic "hello" 1249 packets). 1251 An alternative method of enabling a mobile router to register it's 1252 locally attached sub-nets or prefixes is to include the prefix/length 1253 information in the MSF registration messages. 1255 The Explicit Prefix Registration message should be sent by a mobile 1256 router in response to the MSF Advertisement message it receives (see 1257 Section 3.1.1.3) following the initial MSF Discovery (see 1258 Section 3.1.1.2). 1260 The Explicit Prefix Registration message structure is shown below: 1262 0 1 2 3 1263 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 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Type | Length |R|Pri. |L|Res. | Area_ID | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | Mobile IPv4 Router-ID | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Sub-Type | Pref. Length | Prefix | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | Prefix | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1274 Mobile Router Explicit Prefix Registration Message 1276 Figure 14 1278 Type - 0 = MSF Discovery 1280 Length - Length of the message in octets. 1282 R - Mobile Node Type Indication. 1 = Mobile Router. 1284 Pri. - A 3-bit Priority Code (0-7). 1286 L - Always set to 0 in the MSF Discovery sent by a mobile router. 1288 Res. - Reserved. 1290 Area_ID - An Identifier (1-255) associated with the Area Mobility 1291 Route Reflector. Area_ID=0 must be used for initial registrations 1292 by mobile nodes. 1294 Sub-Type - 0 = Prefix Registration, 1 = Prefix De-registration. 1296 Pref. Length - Prefix Length. 1298 Prefix - Prefix Value. 1300 The MSF receiving the Explicit Prefix Registration from a mobile 1301 router should extract the prefix/length information from the received 1302 message and associate it with the mobile router ID in the 1303 registration record. In addition the MSF should use the received 1304 prefix/length information in the router mobility binding (see 1305 Figure 19). 1307 3.1.4. Registration and Status - IPv6 1309 The registration procedures described for IPv4 in Section 3.1.3 are 1310 fully extended to IPv6 using the same message formats and the UDP 1311 port number. In all messages the IPv4 addresses are replaced with 1312 their IPv6 equivalents (with the corresponding increase in the 1313 required field length). 1315 Thus, for mobile hosts the Lightweight, Full and Group Registration 1316 modes are supported (see Section 3.1.3.1.1, Section 3.1.3.1.2, 1317 Section 3.1.3.1.3), and for mobile routers the same IPv4 procedure 1318 described in Section 3.1.3.2 and modified to include the IPv6 1319 messages should be supported. 1321 In addition to the use of the MSF Discovery/Advertisement message as 1322 keepalives for determining the status of the reachability of the 1323 serving MSF function, mobile nodes may utilize IPv6 Neighbor 1324 Unreachability Detection procedures specified in [RFC4861] section 1325 7.3. 1327 3.2. Integration with MP-BGP 1329 In order to integrate the MSF on the LER with the MP-BGP processing, 1330 a new Address Family must be created. This Address Family must be 1331 assigned a new and unique AFI following the Address Family structure 1332 of MP-BGP. This Address Family may be referred to as the Mobility 1333 Address Family. In fact a number of Mobility Address Families may be 1334 created to support IPv4/IPv6 unicast/multicast protocols. In all 1335 cases the Address Families must use the structure that allows them to 1336 carry the overlay MPLS label information (a specially designated 1337 value of SAFI). 1339 3.2.1. Mobility Address Family 1341 In order to carry the Mobility Binding information the BGP UPDATE 1342 message with the MP_REACH_NLRI and MP_UNREACH_NLRI optional non- 1343 transitive attributes is used as specified in [RFC4760]. 1345 For the mobility management purposes a set of new Address Family 1346 Identifiers (AFI) and Subsequent Address Family Identifiers (SAFI) 1347 are defined. Specifically the following new AFI values are defined: 1349 Mobility IPv4 Unicast - AFI X1 SAFI Y1 1351 Mobility IPv6 Unicast - AFI X2 SAFI Y1 1353 The MP_REACH_NLRI attribute is used to update the LER nodes with new 1354 Mobility Binding information. The structure of the attribute is 1355 shown below. 1357 +---------------------------------------------------------+ 1358 | Address Family Identifier (2 octets) | 1359 +---------------------------------------------------------+ 1360 | Subsequent Address Family Identifier (1 octet) | 1361 +---------------------------------------------------------+ 1362 | Length of Next Hop Network Address (1 octet) | 1363 +---------------------------------------------------------+ 1364 | Network Address of Next Hop (variable) | 1365 +---------------------------------------------------------+ 1366 | Reserved (1 octet) | 1367 +---------------------------------------------------------+ 1368 | Mobility Binding (NLRI) Information (variable) | 1369 +---------------------------------------------------------+ 1371 MP_REACH_NLRI with Mobility Binding 1373 Figure 15 1375 The MP_UNREACH_NLRI attribute is used to withdraw the Mobility 1376 Binding information. The structure of the attribute is shown below. 1378 +---------------------------------------------------------+ 1379 | Address Family Identifier (2 octets) | 1380 +---------------------------------------------------------+ 1381 | Subsequent Address Family Identifier (1 octet) | 1382 +---------------------------------------------------------+ 1383 | Mobility Binding (Withdrawn Routes) (variable) | 1384 +---------------------------------------------------------+ 1386 MP_UNREACH_NLRI with Mobility Binding 1388 Figure 16 1390 The Mobility Binding itself is encoded in the NLRI format shown 1391 below. 1393 +---------------------------+ 1394 | Length (1 octet) | 1395 +---------------------------+ 1396 |Mobility Binding (variable)| 1397 +---------------------------+ 1399 NLRI Encoding for Mobility Bindings 1401 Figure 17 1403 For the definitions of the fields in the above figures (with the 1404 exception of the Mobility Binding related information) please see 1405 [RFC4760]. 1407 3.2.2. Mobility Bindings 1409 Two types of Mobility Binding formats are proposed: Host Mobility 1410 Binding and Router Mobility Binding. 1412 0 1 2 3 1413 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 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | Origin MP-BGP NEXT_HOP | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | Target MP-BGP NEXT_HOP | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | Mobile Host Address | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 |H| UM | UT | Mobility Label |Pri. |S| 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | Area_ID | 1424 +-+-+-+-+-+-+-+-+ 1426 NLRI Encoding for the Host Mobility Binding 1428 Figure 18 1430 Origin MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the 1431 Mobility Binding. This address may be carried in the IPv4 or IPv6 1432 format depending on the {AFI, SAFI} pair used. 1434 Target MP-BGP NEXT_HOP - Router ID of the MPLS LER to receive the 1435 Mobility Binding using Selective Downstream Push. For the 1436 Unsolicited Downstream Push this field should be set to 0. This 1437 address may be carried in the IPv4 or IPv6 format depending on the 1438 {AFI, SAFI} pair used. 1440 Mobile Host Address - IPv4 or IPv6 Address of the mobile host. 1441 This address may be carried in the IPv4 or IPv6 format depending 1442 on the {AFI, SAFI} pair used. 1444 H - Mobile Node Type Indication. 0 = Mobile Host 1446 UM - Update Mode. This 3-bit code is mapped to the ASTI code in 1447 the MSF Discovery and Registration Request messages to indicate 1448 the Network Update Mode selection (see Section 4). 1450 UT - Update Type. This 4-bit code is used to indicate the 1451 Mobility Update Type (internal, external, inter-carrier - see 1452 Section 4). 1454 Mobility Label - Overlay MPLS Label (20 bits) associated with the 1455 IP address of the mobile host in the MSF database. 1457 Pri. - A 3-bit priority code (0-7). 1459 S - Bottom of Stack. 1461 Area_ID - An Identifier (1-255) associated with the Area Mobility 1462 Route Reflector. 1464 0 1 2 3 1465 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 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | Origin MP-BGP NEXT_HOP | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Target MP-BGP NEXT_HOP | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Mobile Router ID | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 |R| UM | UT |No of Prefixes | IP Prefix 1 | 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 | IP Prefix 1 | Prefix 1 Len. | Variable No. | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | of Prefixes/Len | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Mobility Label |Pri. |S| Area_ID | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 NLRI Encoding for the Router Mobility Binding 1484 Figure 19 1486 Origin MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the 1487 Mobility Binding. This address may be carried in the IPv4 or IPv6 1488 format depending on the {AFI, SAFI} pair used. 1490 Target MP-BGP NEXT_HOP - Router ID of the MPLS LER to receive the 1491 Mobility Binding using Selective Downstream Push. For the 1492 Unsolicited Downstream Push this field should be set to 0. This 1493 address may be carried in the IPv4 or IPv6 format depending on the 1494 {AFI, SAFI} pair used. 1496 Mobile Router ID - IP Address of the mobile router. This address 1497 may be carried in the IPv4 or IPv6 format depending on the {AFI, 1498 SAFI} pair used. 1500 R - Mobile Node Type Indication. 1 = Mobile Router 1502 UM - Update Type. This 3-bit code is mapped to the ASTI code in 1503 the MSF Discovery and Registration Request messages to indicate 1504 the Network Update Mode selection (see Section 4). 1506 UT - Update Type. This 4-bit code is used to indicate the 1507 Mobility Update Type (internal, external, inter-carrier - see 1508 Section 4). 1510 No. of Prefixes - Number of IP Prefixes carried in this Mobility 1511 Binding. 1513 IP Prefix 1 - First IP Prefix (32 bits for IPv4, 128 bits for 1514 IPv6) 1516 Prefix 1 Len. - Length (in number of bits) of the network part of 1517 IP Prefix 1 1519 Mobility Label - Overlay MPLS Label (20 bits) associated with each 1520 of the IP Prefixes served by the mobile router in the MSF database 1521 of the originating LER. 1523 S - Bottom of Stack. 1525 Area_ID - An Identifier (1-255) associated with the Area Mobility 1526 Route Reflector. 1528 The receiving MSF must read the R flag in the Mobility Binding and 1529 associate the provided Mobility Label with each of the IP prefixes 1530 found in the body of the Mobility Binding. The derived associations 1531 must be installed in the MPLS forwarding table of the MPLS LER and in 1532 turn associated with the infrastructure label assigned to the "Origin 1533 MP-BGP NEXT_HOP" address indicated in the received Mobility Binding 1535 3.2.3. Group Registration Management with MP-BGP 1537 The Group Registration (Section 3.1.3.1.3) information obtained via 1538 the registration messaging with a mobile host is shared among the 1539 group members using existing MP-BGP peering sessions. To achieve 1540 this, the MSF should allow for a configuration capability to identify 1541 the group membership by assigning a Group ID to the MP-BGP peers that 1542 belong to the same group. The same capability should be provided 1543 within the Mobility Route Reflectors in order to be able to 1544 successfully update the group members with the mobile node 1545 registration information. 1547 The mobile host registration information includes the IP address of 1548 the mobile host, the Group ID, the priority and the ASTI codes as 1549 well as the MAC address of the mobile host. This information is 1550 encoded in the Address Family structure using the AFI values 1551 specified in Section 3.2.1 but with a specifically designated value 1552 of SAFI. The encoded information is then carried in the 1553 MP_REACH_NLRI or MP_UNREACH_NLRI. 1555 Specifically the following new SAFI value is defined: 1557 Mobility IPv4 Unicast - AFI X1 SAFI Y2 1559 Mobility IPv6 Unicast - AFI X2 SAFI Y2 1561 The NLRI encoding is shown below: 1563 0 1 2 3 1564 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 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | MP-BGP NEXT_HOP | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | Reserved |H| Rri.|ASTI |G| Group ID | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Mobile Host IP Address | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Group Virtual IP Address | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | Mobile Host MAC Address (first 32 bits) | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | Last 16 bits | Reserved | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | Correlation ID | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 Group Registration NLRI Encoding 1583 Figure 20 1585 MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the Group 1586 Registration Update. This address may be carried in the IPv4 or 1587 IPv6 format depending on the {AFI, SAFI} pair used. 1589 H - Mobile Node Type Indication. 0 = Mobile Host 1591 Pri. - A 3-bit priority code (0-7). 1593 ASTI - Application Service Type Indication. This 3-bit field may 1594 be used to indicate to the MSF what type of service is to be used 1595 by the mobile host. For example, "Internet Access Only" or Full 1596 Mobile-to-Mobile Routing". This indication can then be mapped to 1597 the Network Update Mode Code used in the Mobility Binding 1598 structure. 1600 G - Group Registration Requested (1) 1602 Group ID - Unique Registration Group Number. Should be zero if G 1603 = 0 1605 Mobile Host IP Address - IPv4 or IPv6 Address of the mobile host. 1606 This address may be carried in the IPv4 or IPv6 format depending 1607 on the {AFI, SAFI} pair used. 1609 Group Virtual IP Address - IPv4 or IPv6 address assigned for the 1610 group and joined by all LER interfaces participating in the MSF. 1611 For IPv6 this may be the Anycast IP address. 1613 Mobile Host MAC Address - MAC address of the mobile host. 1615 Correlation ID - a number used to keep track of the registration 1616 requests and the corresponding reply message pairs. 1618 The group registration information updates may be sent periodically 1619 by the group members. The registration information for multiple 1620 mobile hosts may be aggregated in a single MP-BGP UPDATE message. 1621 The mobile host registration information may be explicitly withdrawn 1622 by the group member that was the last to "hear" from the mobile host. 1624 If a group member receives the MP-BGP registration information update 1625 listing a mobile host that has an active local registration entry, 1626 the local registration information must be silently discarded and the 1627 corresponding local Mobility Binding deleted. The local Mobility 1628 Label should be returned to the local available label pool. 1630 If a local registration entry for a mobile host has expired, and if a 1631 mobile host registration information is not found in the incoming 1632 periodic MP-BGP registration information updates from any of the 1633 group members, the group member should send the MP-BGP registration 1634 information update carrying the host's registration information in 1635 the MP_UNREACH_NLRI attribute. In addition the group member should 1636 initiate a network update using the MP_UNREACH_NLRI with the encoded 1637 Mobility Binding for the host in order to withdraw the Mobility 1638 Binding from the MSF databases of the MPLS LER nodes. 1640 3.2.4. BGP Capability Advertisement 1642 The {AFI, SAFI} pairs defined in this document for mobility 1643 management must be supported by all BGP speakers participating in 1644 mobility management. A BGP Capability Advertisement as specified in 1645 [RFC4760] must be used by the BGP speakers to ensure compatibility. 1647 3.3. Mobile Application Priority Indication and Recognition 1649 Given the sensitivity of applications to the network service 1650 disruption the MSF function should include a mechanism by which an 1651 application may indicate the level of tolerance to the disruption due 1652 to the network handling of the hand-off process. This indication may 1653 be encoded in the registration messaging payload and then 1654 incorporated into the Mobility Binding protocol structure. The 1655 application sensitivity prioritization scheme may be used to control 1656 the Mobility Binding processing priority during the distribution 1657 process. For example a mobile host running a real time interactive 1658 application may be given a higher processing priority over the mobile 1659 host running an elastic data transfer application. The 1660 prioritization of processing leads to a differential treatment of the 1661 mobile application at various processing points of the mobile network 1662 such as the ingress MSF, the intermediate hierarchical route 1663 processing by MP-BGP Route Reflectors and the egress MSF. 1665 In addition to the processing priority, the priority indication 1666 mechanism may be used to implement the network update grouping and 1667 timing policies in a manner that could decrease the frequency of the 1668 updates and thus increase the scalability of the network. 1669 Specifically, the indicated application priorities may be mapped into 1670 the network update classes where the top priority may get an 1671 immediate network update and the lower priorities may be organized 1672 into classes. For each class the network update process may be 1673 delayed for a time period that is not expected to result in the 1674 unreasonable disruption to an application of a given priority level. 1675 The network updates for any new registration events of the same 1676 priority level that have occurred during the corresponding delay 1677 period may be grouped in a single MP-BGP update message. If a single 1678 update message cannot carry all of the newly arrived registrations an 1679 additional update should be created and sent. The update mode may be 1680 determined from the Application Service Type Indication communicated 1681 during the registration. 1683 3.4. Application Service Type Indication 1685 Application Service Type Indication (ASTI) is a 3-bit field that may 1686 be used to indicate to the MSF what type of service is to be used by 1687 the mobile host. For example, "Internet Access Only" or "Full 1688 Mobile-to-Mobile Routing". This indication may then be mapped to the 1689 Network Update Type Code used in the Mobility Binding structure. For 1690 example, if ASTI code 001 (binary) is used to indicate the "Internet 1691 Access Only" service, the local MSF may use the Selective Downstream 1692 Push (see Section 4.1.2) Network Update mode. In addition the MSF 1693 may include the corresponding Update Type code in the Mobility 1694 Binding structure in order to indicate to the Mobility Route 1695 Reflectors that the Selective Downstream Push is to be used. 1697 4. Network Update and Hand-off Processing 1699 4.1. Network Update Modes and Types 1701 The following four modes for the Mobility Binding Distribution or 1702 Withdrawal are proposed: i) unsolicited downstream push, ii) 1703 selective downstream push, iii) predictive downstream push, and iv) 1704 hierarchical on-demand distribution. 1706 4.1.1. Unsolicited Downstream Push Mode 1708 In this mode the originating LER node updates all other MSF enabled 1709 LER nodes that are directly peered with it. In case of a 1710 hierarchical topology the originating LER node sends a MP-BGP update 1711 with the Mobility Binding information to a Route Reflector which in 1712 turn updates all of the participating MSF enabled LER Route Reflector 1713 clients. Thus the network wide update can only considered to be 1714 complete if and only if all of the MSF LER nodes are updated. 1715 Clearly this distribution mode has scalability limitations and may be 1716 applicable for a relatively small number of the MSF enabled LER 1717 nodes. The Update Mode Code for this mode is binary 000. 1719 4.1.2. Selective Downstream Push Mode 1721 In this mode the Mobility Binding updates are only sent to a select 1722 set of the MSF enabled LER nodes. The underlying idea for this mode 1723 is that it is very likely that the most used destinations from the 1724 mobile host when it communicates with the Internet are the 1725 destinations reachable via a finite set of the service provider's 1726 Internet gateway nodes which are in turn reachable via a finite set 1727 of the MSF enabled LER nodes. As such, when a mobile host registers 1728 with the serving MSF, instead of using the Unsolicited Downstream 1729 Push to all LER nodes, the Mobility Binding update for this mobile 1730 host would be sent to a finite set of the LER nodes connected to the 1731 service provider Internet gateways. This mode can be used for the 1732 initial update process and the Unsolicited Downstream Push can be 1733 used at a later point in time. The Update Type Mode for this mode is 1734 binary 001. 1736 4.1.3. Predictive Downstream Push Mode 1738 In this mode the Mobility Binding updates are sent to those MSF 1739 enabled LER nodes which are identified as a NEXT_HOP for the FEC (and 1740 the corresponding LSP) leading to the destination of the packet 1741 originated by a mobile node. This mode is based on the fact that if 1742 the destination FEC exists in the serving MSF LER's routing table, 1743 and the mobile node sends a packet to the FEC, the LER will perform 1744 the label imposition (for the infrastructure label) by selecting the 1745 label corresponding to the FEC NEXT_HOP. This NEXT_HOP in turn 1746 identifies the destination MSF enabled LER node to which the Mobility 1747 Binding update needs to be sent. The predictive feature of this mode 1748 comes from the fact that the Mobility Binding update destination is 1749 predicted as the result of the originating LER's lookup of the 1750 destination FEC and its NEXT_HOP. Clearly it is likely that the LER 1751 node to which the predictive Mobility Binding update is sent may 1752 receive the reply packet from the mobile node's destination before 1753 the Mobility Binding for the originating host is received. In this 1754 case the LER that is being updated may buffer the reply packet for a 1755 reasonable period of time to wait for the mobility update. The 1756 Update Mode Code for this mode is binary 010. 1758 4.1.4. Hierarchical On-Demand Distribution Mode 1760 The Mobility Binding update is first sent by a serving MSF LER to a 1761 set of Mobility Route Reflectors using the Selective Downstream Push. 1762 Once the Mobility Route Reflectors have been updated, all other LER 1763 nodes must explicitly request Mobility Labels from the Mobility Route 1764 Reflectors for packets destined to a mobile node. The Update Mode 1765 Code for this mode is binary 011. 1767 4.1.4.1. On-Demand Requests for Mobility Binding Information 1769 To support the Hierarchical On-Demand Distribution Network Update 1770 Mode the following explicit Mobility Binding information request 1771 procedure based on MP-BGP may be used. When a MPLS LER supporting 1772 MPLS Mobility receives an IP packet, it first should check if the 1773 Destination Address listed in the IP header belongs to the overall IP 1774 address range assigned to the mobility functions and the 1775 corresponding mobile device fleet. If the Destination Address falls 1776 within this range and the matching Mobility Binding is present in the 1777 LER MSF database, the packet should be encapsulated using the 1778 appropriate MPLS label stack and forwarded on the LSP toward the LER 1779 that is listed as the "Origin MP-BGP NEXT_HOP" in the Mobility 1780 Binding. If the IP address is outside of the mobility fleet range 1781 the packet must be treated in accordance with the conventional rules 1782 based on either the IP or MPLS forwarding tables. 1784 If the packet falls into the mobility fleet range and no matching 1785 Mobility Binding entry exists in the MSF database, the LER should 1786 send an on-demand request for Mobility Binding Information to the 1787 designated Mobility Route Reflector. This request is encoded as a 1788 special type of the MP_REACH_NLRI attribute using a specific SAFI 1789 value and one of the AFI values defined earlier. The Mobility Route 1790 Reflector should process the request and return the Mobility Binding 1791 update to the requesting LER using the NLRI encoding shown in 1792 Section 3.2.2. 1794 Specifically the following new SAFI value is defined for the On- 1795 Demand Mobility Binding Information Request: 1797 Mobility IPv4 Unicast - AFI X1 SAFI Y3 1799 Mobility IPv6 Unicast - AFI X2 SAFI Y3 1801 The NLRI encoding is shown below: 1803 0 1 2 3 1804 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 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | MP-BGP NEXT_HOP | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 |Request Type | Area_ID | Number of Addresses | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 | IP Destination Address | 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 | IP Destination Address 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1815 NLRI Encoding for On-Demand Mobility Binding Request 1817 Figure 21 1819 MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the On- 1820 Demand Mobility Binding Information Request. This address may be 1821 carried in the IPv4 or IPv6 format depending on the {AFI, SAFI} 1822 pair used. 1824 Request Type - To be defined (may be "Specific, Partial, ALL or 1825 LRL"). 1827 Area_ID - An Identifier (1-255) associated with the Area Mobility 1828 Route Reflector. Area_ID=0 must be used for initial registrations 1829 by mobile nodes. 1831 Number of Addresses - Number of IP Destination Addresses listed in 1832 the On-Demand Request for which the Mobility Binding Information 1833 is requested 1835 IP Destination Address - The IPv4 or IPv6 address of a mobile host 1836 for which the Mobility Binding Information is requested. 1838 If the Request Type is not equal to LRL - Last Requestor List, the 1839 Mobility Route Reflector (mRR) should reply with a regular Mobility 1840 Binding Update. If the request type is equal to LRL, then the 1841 following reply format should be used: 1843 0 1 2 3 1844 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 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 | MP-BGP NEXT_HOP | 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 |Request Type | Reserved | Number of Addresses | 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 | LRL Length | IP Destination + | 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | Address | Last Requestor + | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 | Router_ID | L.R. Area_ID | Last + | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 | Requestor Router_ID | L.R. Area_ID | LRL + | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | Length | IP Destination + | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | Address | Last Requestor + | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | Router_ID | L.R. Area_ID | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1865 NLRI Encoding for On-Demand LRL Reply 1867 Figure 22 1869 MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the On- 1870 Demand LRL Reply. This address may be carried in the IPv4 or IPv6 1871 format depending on the {AFI, SAFI} pair used. 1873 Request Type - LRL Reply. 1875 Number of Addresses - LRL's in the reply 1877 IP Destination Address - The IPv4 or IPv6 address of a mobile host 1878 for which the LRL Information is requested. 1880 Last Requestor Router_ID - IP Address of the LER from which the 1881 On-Demand Mobility Binding Information Request for the mobile node 1882 in question was last received (may be more than one). 1884 L.R. Area_ID - ID of the Area mRR serving the LER from which the 1885 On-Demand Mobility Binding Information Request for the mobile node 1886 in question was last received (may be more than one). 1888 4.1.5. Network Update Types 1890 The network update types are carried within the Mobility Binding 1891 structure and are used in the hierarchical mobility management 1892 environment to indicate the nature of the update and the subsequent 1893 processing behavior by the appropriate network elements such as the 1894 Area Mobility Route Reflector (AMRR), Area Label Edge Router (ALER) 1895 and the Label Edge Router (LER). Please see section Section 4.1.6. 1897 4.1.5.1. Internal Update Type 1899 An internal update is initiated by an LER node local to a Mobility 1900 Area and carries the Mobility Binding information for a locally 1901 registered mobile device. The internal update is sent by an LER to 1902 the AMRR in order to update the ALER node. The internal update may 1903 also be sent by the ALER node to AMRR in response to the external 1904 update received by the ALER about the Mobility Bindings originating 1905 outside a local area. The Update Type Code for the Internal Update 1906 is binary 0000. 1908 4.1.5.2. External Update Type 1910 An external update is originated by the ALER in response to an 1911 internal update and is sent to the AMRR. The Update Type Code for 1912 the External Update is binary 0001. 1914 4.1.6. Network Hierarchy Considerations 1916 The first three update modes are directly applicable for the flat MSF 1917 LER peering topology and the fourth to the hierarchical peering 1918 environment. In the hierarchical peering environment only 1919 Unsolicited Downstream Push does not require any modifications to the 1920 Route Reflector operation. The Selective and Predictive modes 1921 require that the Route Reflectors perform selective MP-BGP updates 1922 for the Mobility Bindings distribution. This can be achieved by a 1923 modification of the Route Reflector update process where destinations 1924 of the selective updates indicated by the Update Mode Code can be 1925 derived from the "Target NEXT_HOP" parameter in the Mobility Binding 1926 structure. The Hierarchical On-Demand mode requires the Route 1927 Reflectors to store the Mobility Bindings and respond to the on- 1928 demand Mobility Binding requests initiated by the client MSF LER 1929 nodes or other Mobility Route Reflectors. 1931 4.1.7. Regionalization and Scalability 1933 To improve the scalability of the network update process the entire 1934 serving network may be divided into the Mobility Areas. Each 1935 Mobility Area is served by an Area Mobility Route Reflector (AMRR) 1936 and optionally with an Area LER, with the individual MSF LER nodes 1937 falling within the area and acting as the Route Reflector Clients. 1938 Each MSF LER node in turn may serve a specific geographic region 1939 called a Mobility Region that is covered by a given set of Radio 1940 Access Networks using Direct or In-direct Attachment options. This 1941 type of the hierarchical regionalized mobility signaling 1942 infrastructure is referred to as the Hierarchical Mobility Label 1943 Based Network (H-MLBN) and is shown in the figure below. 1945 AMRR1/ALER1 AMRR3/ALER3 1946 +----+ +----+ 1947 | +------------------+ `. 1948 .++-+-+ AMRR2/ALER2 +--+-\ `. 1949 .'//| | +----+ | |`. \ 1950 .' /| | +--------+ +---------+ |\ \ `. 1951 Mobility Area 1 ++++-\ Mobility Area 3 1952 .' / / | /\ \ `. | \ \ `. 1953 .' / | | Mobility Area 2 | \ `. `. 1954 +-.' / +-/ | / | \ \ | | \ \ 1955 +-+ +-/ +-+ +-\ | \ \ \ \-+ \ `.-+`. 1956 LER11 +-+ LER13+-+ +-/ | \-+ `. +-+ \-+ +-+ +`. 1957 . LER12 . LER14 +-+ +-\ +-+ +-\ LER31 +-+ LER33+-+ 1958 / \ . / \ . LER21 +-+ LER23+-+ . LER32 . LER34 1959 ; : / \ ; : / \ . LER22 . LER24 / \ . / \ . 1960 |11 | ;12 :|13 |;14 : / \ . / \ . ; : / \ ; : / \ 1961 | | | || || | ;21 : / \ ; : / \ |31 |;32 :|33 |;34 : 1962 |++ | | || || | | | ;22 :|23 |;24 : | || || || | 1963 :++MN | |: ;| | | | | || || | | || || || | 1964 \ / : ; \ / : ; | | | || || | : ;| |: ;|++ | 1965 ' \ / ' \ / : ; | |: ;| | \ / : ; \ / :++CN 1966 ' ' \ / : ; \ / : ; ' \ / ' \ / 1967 ' \ / ' \ / ' ' 1968 ' ' 1969 Mobility Regions 1971 Hierarchical Mobility Label Based Network (H-MLBN) 1973 Figure 23 1975 4.1.7.1. Hierarchical Mobility Label Based Network (H-MLBN) 1977 The operation of H-MLBN is based on the Hierarchical On-Demand 1978 Network Update mode and requires the individual MSF LER nodes to only 1979 directly update their respective Area Mobility Route Reflectors 1980 (using the Selective Update Mode and the Internal Update Type). 1981 After the Area mRR's have been updated with the Mobility Binding 1982 information, these bindings may be explicitly requested by the MSF 1983 LER's in the same Mobility Area or the LER's in other areas via their 1984 Area mRR's. To facilitate the hand-off process a Last Requestor List 1985 (LRL) is introduced and associated with each Mobility Binding at the 1986 Area mRR level. The LRL is a list of 2-tuples where each 2-tuple 1987 consists of the Router_ID and Area_ID of the AMRR nodes that have 1988 requested Mobility Binding information for a particular mobile node. 1989 The logical operation of H-MLBN is described below based on 1990 Figure 23. 1992 1. Assume that a previously unknown MN initiated a Discovery and 1993 Registration process in the Mobility Region 11. Upon successful 1994 registration MN communicates its IP address to the MSF in LER11 and 1995 receives the related MSF information including the Area_ID=1. 1996 (During the registration the newly initialized MN should use 1997 Area_ID=0). 1999 2. LER11 creates a Mobility Binding for the MN and updates AMRR1 2000 using the Selective Mode and Internal Type, and specifying the MN's 2001 IP address, It's own Router_ID, the locally significant Mobility 2002 Label and the Area_ID=1. AMRR1 stores the received Mobility Binding 2003 and associates an empty LRL with it. 2005 3. Assume that a Correspondent Node (CN) in the Mobility Region 34 2006 sends a packet to the MN in the Mobility Region 11. The packet 2007 reaches LER34. 2009 4. LER34 identifies that the packet falls into the mobility address 2010 range and requests Mobility Binding information from its Area MRR3 2011 using On-Demand Mobility Binding Request (see Figure 21). LER34 uses 2012 the value of the Area_ID=3 in the request. 2014 5. Since AMRR3 does not have the Mobility Binding for the MN it 2015 forwards the requests to both AMRR1 and AMRR2. AMRR1 replies with 2016 the Mobility Binding and AMRR3 forwards the reply to LER34. AMRR1 2017 associates an LRL with the Mobility Binding listing the AMRR3's 2018 Router_ID and the Area_ID=3. 2020 6. LER34 forwards the packet to the MN using the LSP between LER11 2021 and LER34 and a stacked Mobility Label extracted from the received 2022 Mobility Binding. If the H-MLBN makes use of the Area LER nodes 2023 (thus also using the forwarding plane hierarchy) the Mobility Labels 2024 may include the ALER's Router_ID instead of the LER Router_ID. Thus 2025 the path between the LER nodes may consist of multiple segments (a 2026 segmented LSP): LER-ALER, ALER-ALER, ALER-LER. 2028 7. Assume that MN now moves into the Mobility Region 22. It 2029 initiates a new Discovery and Registration procedure and registers 2030 with the MSF at LER22 specifying its IP address and the Last 2031 Area_ID=1. 2033 8. LER22 creates a local Mobility Binding for the MN and updates its 2034 regional AMRR2 using Selective Mode and Internal Type, and sending 2035 the Area_ID=1 along with the Mobility Binding. 2037 9. AMRR2 receives the new Mobility Binding and examines the 2038 associated value of Area_ID. If it is not equal to its own, then the 2039 LRL for this binding must be requested from the AMRR identified by 2040 the Area_ID. In this case AMRR2 sends the On-Demand request to AMRR1 2041 asking for the associated LRL created in step 5. 2043 10. AMRR2 receives the LRL={Router_ID=LER34, Region_ID=3} from AMRR1 2044 (see Figure 22) and sends a Mobility Binding update to AMRR3 using 2045 the Selective Downstream Push Mode and the External Update Type and 2046 with the "Target MP-BGP NEXT_HOP" set to the LER34 Router_ID. 2048 11. AMRR3 receives the updated Mobility Binding and looks up the 2049 "Target MP-BGP NEXT_HOP". In this case it is equal to the LER34 2050 Router_ID. AMRR3 updates LER34 with the new Mobility Binding using 2051 Selective Mode and Internal Type. LER34 starts to forward packets to 2052 the MN using the LSP between LER34 and LER22 (listed as the "Origin 2053 MP-BGP NEXT_HOP" in the updated Mobility Binding) and the new overlay 2054 Mobility Label. 2056 4.2. Hand-off Processing 2058 The use of the Multi-Protocol BGP for mobility management allows a 2059 simple basic hand-off processing scheme to be implemented. In 2060 particular, when a mobile node detects that it can no longer receive 2061 the keepalive acknowledgements from the serving MSF it initiates the 2062 new discovery and registration procedure. After the successful 2063 registration the new serving MSF will assign and distribute a new 2064 Mobility Binding to the rest of the participating LER nodes thus 2065 replacing the corresponding old Mobility Binding entries in their MSF 2066 databases. Once the entries have been replaced by the new Mobility 2067 Binding the LER nodes will automatically forward the packets destined 2068 for the mobile node onto the new LSPs connecting to the mobile node's 2069 new serving MSF and the corresponding new Radio Access Network. 2071 The described hand-off procedure provides a basic hand-off handling 2072 in that it requires a new mobile node registration to trigger the 2073 Mobility Binding update to the network. The service disruption due 2074 to the time required to detect the loss of communication and to 2075 discover the new MSF and register with it can be minimized by 2076 selecting the fast keepalive timers but this in turn will result in 2077 the increased processing overhead and a possible impact on 2078 scalability. At the same time the frequency of the hand-offs between 2079 the MSF LER nodes can reasonably be expected to be much lower then 2080 the frequency of the Layer 2 hand-offs because the MSF enabled LER is 2081 expected to serve a large area potentially covered by multiple Radio 2082 Access Networks. Therefore a reasonable configuration of the 2083 keepalive timers and the low frequency of the MSF-to-MSF hand-offs 2084 may result in an acceptable network responsiveness especially for 2085 disruption tolerant applications. 2087 In cases where the application sensitivity requires a better network 2088 responsiveness a number of more sophisticated hand-off methods can be 2089 implemented. One of the methods may make use of the Group 2090 Registration as described above. In this case no discovery or 2091 registration is required from the mobile node when it moves into the 2092 new service area - it simply must continue to send packets to the 2093 group address and whichever group member happens to be serving the 2094 mobile node will distribute the pre-assigned Mobility Label to update 2095 the network. Thus the hand-off latency becomes only a function of 2096 the MP-BGP update processing as opposed to being a function of a 2097 combination of a potentially lengthy discovery and registration as 2098 well as the MP-BGP update procedures. Again, this scheme requires a 2099 trade-off analysis between the gain in the network responsiveness and 2100 the cost in signaling and processing required to maintain the shared 2101 registration table. 2103 4.3. Micro-Mobility Handling 2105 In the context of Mobile IP Micro-Mobility can be defined as a range 2106 of the mobile node movements that do not require re-registrations 2107 with the Mobile IP HA. A number of proposals exist that are targeted 2108 to extend the range of micro-mobility by utilizing the hierarchical 2109 mobility management schemes. 2111 In the context of this document micro-mobility is defined as the 2112 range of the mobile node's movements that do not result in the 2113 registration with a new MSF or the network update by MP-BGP, or both. 2114 As such the following two micro-mobility scenarios are considered by 2115 this proposal. 2117 4.3.1. Local Micro-Mobility 2119 Local micro-mobility is defined as the range of movements of the 2120 mobile node that is contained within the serving area of a given MSF 2121 enabled LER node. Referring to Figure 1 this moving pattern would 2122 correspond to the mobile node transitioning between the radio cells 2123 associated with the L3 logical interfaces local to the serving LER 2124 node. Clearly such a movement pattern should not result in either 2125 the re-registration with the MSF or the network update by MP-BGP. 2127 In order to support Local Micro-Mobility the MSF should have the 2128 capability of "tracking" the mobile node association with the LER L3 2129 logical interfaces. This "tracking" may simply be based on the 2130 reception of the datagrams from the mobile node. If the packets from 2131 the same L2 address and L3 source addresses started arriving on a new 2132 L3 logical interface of the LER and the MSF registration for the 2133 mobile node in question is active the MSF should associate the new L3 2134 logical interface with the existing registration entry and the 2135 corresponding local Mobility Binding. 2137 4.3.2. Group Micro-Mobility 2139 Group Micro-Mobility makes direct use of the Group Registration 2140 described in Section 3.1.3. In this case the Group Micro-Mobility is 2141 defined as the range of the mobile node's movements that do not 2142 result in the MSF re-registration process. Group Micro-Mobility 2143 still requires the network update by MP-BGP. 2145 5. Datagram Delivery 2147 The delivery of packets from the MSF registered mobile node to other 2148 network destinations uses the same processing as in the other MPLS 2149 services. Namely, when a packet is received from the mobile node the 2150 LER looks up the MPLS forwarding database to find a FEC to which the 2151 destination IP address belongs. Once the FEC is identified the 2152 corresponding MPLS label (or label stack) is used to send the packet 2153 on the LSP toward the destination. 2155 For the packets destined to the mobile node, when the packet is 2156 received by the LER the MSF performs a lookup in the overlay MPLS 2157 forwarding table to find the Mobility Binding matching the 2158 destination address of the mobile node (this binding entry was 2159 populated as the result of the Mobility Binding Distribution 2160 process). Once the match is found the inner MPLS label is pushed 2161 onto the MPLS label stack. Then the LER performs an additional 2162 lookup to find a FEC and the corresponding label matching the "Origin 2163 MP-BGP NEXT_HOP" LER IP address associated with this Mobility 2164 Binding. This outer label is then pushed onto the MPLS label stack 2165 and the packet is forwarded on the LSP. 2167 At the receiving MSF enabled LER the packet is processed and the 2168 inner MPLS label is examined to find the reverse Mobility Binding 2169 match in order to identify the IP address of the mobile node. Once 2170 the IP address is identified the corresponding Layer 2 address is 2171 found in the MSF registration database. The packet payload is then 2172 encapsulated into the Layer 2 protocol and delivered to the mobile 2173 node. 2175 In the case when the mobility service is provided to the mobile 2176 router, the forwarding of packets follows the same procedure for the 2177 service provider MPLS network segment. The packet forwarding between 2178 the mobile router and the serving MSF enabled LER does not have to 2179 use MPLS and can be based on IPv4 or IPv6 and the corresponding radio 2180 attachment layer 2 protocol. 2182 6. Security Considerations 2184 The Lightweight Registration procedure (see Section 3.1.3.1.1) and 2185 the associated Network Update and traffic processing provides the 2186 capability to bypass the Full Registration mode in favor of the 2187 ability to significantly decrease the registration processing time. 2188 From the security perspective this procedure should only be allowed 2189 if the layer 2 radio access network provides acceptable mobile node 2190 authentication. 2192 To provide for stronger authentication, the Full or the Group 2193 Registration procedures must be used (see Section 3.1.3.1.2, 2194 Section 3.1.3.1.3). These procedures allow to use additional 2195 authentication procedures by making use of the Registration Request 2196 and Reply message extensions (see Figure 10, Figure 11). 2198 For the Mobile Routers, existing routing protocol security procedures 2199 such as the peer authentication may be used. 2201 7. IANA Considerations 2203 New ICMP code values for message types 9, 10, 133 and 134: 2205 Type=10 - IPv4 Router Solicitation, Code=1 - MLBN MSF Discovery 2206 Extension 2208 Type=9 - IPv4 Router Advertisement, Code=1 - MLBN MSF 2209 Advertisement Extension 2211 Type=133 - IPv6 Router Solicitation, Code=1 - MLBN MSF Discovery 2212 Extension 2214 Type=134 - IPv6 Router Advertisement, Code=1 - MLBN MSF 2215 Advertisement Extension 2217 New UDP port number: 2219 UDP Port RRR for the MLBN Full and Group Registration Protocol. 2221 New {AFI, SAFI} pairs for MP-BGP: 2223 AFI=X1, SAFI=Y1 - MLBN Mobility Binding IPv4 Unicast 2225 AFI=X1, SAFI=Y2 - MLBN Group Registration IPv4 Unicast 2227 AFI=X1, SAFI=Y3 - MLBN On-Demand Binding Information IPv4 Unicast 2229 AFI=X2, SAFI=Y1 - MLBN Mobility Binding IPv6 Unicast 2231 AFI=X2, SAFI=Y2 - MLBN Group Registration IPv6 Unicast 2233 AFI=X2, SAFI=Y3 - MLBN On-Demand Binding Information IPv6 Unicast 2235 8. Acknowledgements 2237 The authors would like to thank Dr. Stuart Elby of Verizon 2238 Communications for his insights and valuable suggestions related to 2239 this work. 2241 9. Patent Issues 2243 The IETF has been notified of intellectual property rights claimed in 2244 regard to some or all of the specification contained in this 2245 document. For more information consult the online list of claimed 2246 rights. 2248 The IETF takes no position regarding the validity or scope of any 2249 Intellectual Property Rights or other rights that might be claimed to 2250 pertain to the implementation or use of the technology described in 2251 this document or the extent to which any license under such rights 2252 might or might not be available; nor does it represent that it has 2253 made any independent effort to identify any such rights. Information 2254 on the procedures with respect to rights in RFC documents can be 2255 found in BCP 78 and BCP 79. 2257 The IETF invites any interested party to bring to its attention any 2258 copyrights, patents or patent applications, or other proprietary 2259 rights that may cover technology that may be required to implement 2260 this standard. Please address the information to the IETF at 2261 ietf-ipr@ietf.org. 2263 10. Changes from Previous Revisions 2265 00 -> 01 2267 - Replaced Region_ID with Area_ID in MSF Registration and Mobility 2268 Bindings 2270 - Replaced UT field in Mobility Binding with the UM field 2272 - Replaced the Resv. field in Mobility Binding with the UT field 2274 - Added Area_ID to the Mobility Binding Structure 2276 - Added sections 4.1.5, 4.1.5.1 and 4.1.5.2 2278 - Modified Section 4.1.7. Used H-MLBN instead of MILS 2280 - Added informative reference [H-MLBN] 2282 - Added Section 10 2284 01 -> 02 2286 - Added Section 3.1.3.2.2 2288 - Added informative reference [H-MLBN] 2290 11. References 2292 11.1. Normative References 2294 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 2295 September 1991. 2297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2298 Requirement Levels", BCP 14, RFC 2119, March 1997. 2300 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 2301 BGP-4", RFC 3107, May 2001. 2303 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 2304 August 2002. 2306 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 2307 in IPv6", RFC 3775, June 2004. 2309 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 2310 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 2311 RFC 3963, January 2005. 2313 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 2314 Protocol 4 (BGP-4)", RFC 4271, January 2006. 2316 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2317 Networks (VPNs)", RFC 4364, February 2006. 2319 [RFC4443] Conta, A. and S. Deering, "Internet Control Message 2320 Protocol (ICMPv6) for the Internet Protocol Version 6 2321 (IPv6) Specification", RFC 4443, December 1998. 2323 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2324 "Multiprotocol Extensions for BGP-4", RFC 4760, 2325 January 2007. 2327 [RFC4861] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 2328 Discovery for IP Version 6 (IPv6)", RFC 4861, 2329 September 2007. 2331 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 2332 B. Thomas, "LDP Specification", RFC 5036, January 2001. 2334 11.2. Informative References 2336 [H-MLBN] Berzin, O., "Mobility Label Based Network: Hierarchical 2337 Mobility Management and Packet Forwarding Architecture", 2338 Comput.-Netw. In submission, 2008. 2340 [MLBN] Berzin, O., "Mobility Label Based Network: Mobility 2341 Support in Label Switched Networks with Multi-protocol 2342 BGP", Comput.-Netw., Vol. 52, Issue 9, Page(s): 1732-1744. 2343 doi:10.1016/j.comnet.2008.03.001, 2008. 2345 [MM-MPLS] Langar, L., Toshme, S., and N. Bouabdallah, "An Approach 2346 for Mobility Modeling - Towards an Efficient Mobility 2347 Management Support in Future Wireless Networks", IEEE/ 2348 IFIP NOMS, 2006. 2350 Authors' Addresses 2352 Oleg Berzin 2353 Verizon Communications 2354 1717 Arch Street 2355 Philadelphia, PA 19103 2356 US 2358 Phone: +1 215-466-2738 2359 Email: oleg.berzin@verizon.com 2361 Andrew G. Malis 2362 Verizon Communications 2363 40 Sylvan Road 2364 Waltham, MA 02451 2365 US 2367 Phone: +1 781-466-2362 2368 Email: andrew.g.malis@verizon.com 2370 Full Copyright Statement 2372 Copyright (C) The IETF Trust (2008). 2374 This document is subject to the rights, licenses and restrictions 2375 contained in BCP 78, and except as set forth therein, the authors 2376 retain all their rights. 2378 This document and the information contained herein are provided on an 2379 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2380 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2381 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2382 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2383 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2384 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2386 Intellectual Property 2388 The IETF takes no position regarding the validity or scope of any 2389 Intellectual Property Rights or other rights that might be claimed to 2390 pertain to the implementation or use of the technology described in 2391 this document or the extent to which any license under such rights 2392 might or might not be available; nor does it represent that it has 2393 made any independent effort to identify any such rights. Information 2394 on the procedures with respect to rights in RFC documents can be 2395 found in BCP 78 and BCP 79. 2397 Copies of IPR disclosures made to the IETF Secretariat and any 2398 assurances of licenses to be made available, or the result of an 2399 attempt made to obtain a general license or permission for the use of 2400 such proprietary rights by implementers or users of this 2401 specification can be obtained from the IETF on-line IPR repository at 2402 http://www.ietf.org/ipr. 2404 The IETF invites any interested party to bring to its attention any 2405 copyrights, patents or patent applications, or other proprietary 2406 rights that may cover technology that may be required to implement 2407 this standard. Please address the information to the IETF at 2408 ietf-ipr@ietf.org. 2410 Acknowledgment 2412 Funding for the RFC Editor function is provided by the IETF 2413 Administrative Support Activity (IASA).