idnits 2.17.00 (12 Aug 2021) /tmp/idnits63228/draft-gundavelli-dmm-mfa-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 date (September 19, 2018) is 1333 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) == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-03 == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-09 == Outdated reference: draft-ietf-dmm-ondemand-mobility has been published as RFC 8653 == Outdated reference: A later version (-21) exists of draft-ietf-dmm-srv6-mobile-uplane-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM WG S. Gundavelli 3 Internet-Draft Cisco 4 Intended status: Standards Track M. Liebsch 5 Expires: March 23, 2019 NEC 6 S. Matsushima 7 SoftBank 8 September 19, 2018 10 Mobility-aware Floating Anchor (MFA) 11 draft-gundavelli-dmm-mfa-01.txt 13 Abstract 15 IP mobility protocols are designed to allow a mobile node to remain 16 reachable while moving around in the network. The currently deployed 17 mobility management protocols are anchor-based approaches, where a 18 mobile node's IP sessions are anchored on a central node. The mobile 19 node's IP traffic enters and exits from this anchor node and it 20 remains as the control point for all subscriber services. This 21 architecture based on fixed IP anchors comes with some complexity and 22 there is some interest from the mobile operators to eliminate the use 23 of fixed anchors, and other residual elements such as the overlay 24 tunneling that come with it. 26 This document describes a new approach for realizing a mobile user- 27 plane that does not require fixed IP anchors. The architectural- 28 basis for this approach is the separation of control and user plane, 29 and the use of programmability constructs of the user-plane for 30 traffic steering. This approach is referred to as, Mobility-aware 31 Floating Anchor (MFA). 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 23, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 69 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. The Network Topology Database . . . . . . . . . . . . . . 9 73 3.2. The Node Location Database . . . . . . . . . . . . . . . . 9 74 3.3. Determination of the Correspondent Node Anchor . . . . . . 10 75 3.4. Traffic Steering Approaches . . . . . . . . . . . . . . . 10 76 3.5. Mobile Node Attachment Triggers . . . . . . . . . . . . . 12 77 3.6. Programming the User-plane . . . . . . . . . . . . . . . . 12 78 4. Life of a Mobile Node in a MFA Domain . . . . . . . . . . . . 14 79 4.1. MN's Initial Attachment to a MFA Domain . . . . . . . . . 15 80 4.2. MN's Roaming within the MFA Domain . . . . . . . . . . . . 17 81 4.3. Traffic Steering State Removal . . . . . . . . . . . . . . 20 82 4.4. Mobile Node's new IP flows . . . . . . . . . . . . . . . . 21 83 5. MFA in 5G System Architecture . . . . . . . . . . . . . . . . 21 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 92 1. Introduction 94 IP mobility protocols are designed to allow a mobile node to remain 95 reachable while moving around in the network. The currently deployed 96 mobility management protocols are anchor-based approaches, where a 97 mobile node's IP sessions are anchored on a central node. The mobile 98 node's IP traffic enters and exits from this anchor node and it 99 remains as the control point for all subscriber services. This 100 architecture based on fixed IP anchors comes with some complexity and 101 there is some interest from the mobile operators to eliminate the use 102 of fixed anchors, and other residual elements such as the overlay 103 tunneling that come with it. Some of the key objectives for this 104 effort are listed below. 106 o Access-agnostic, shared user-plane that can be used for multiple 107 access technologies 109 o Optimized Routing for the mobile node's IP flows with topology 110 awareness and leveraging the transport QoS 112 o Elimination of overlay tunnels from the user-plane network for 113 avoiding packet fragmentation, and reducing encapsulation related 114 packet-size overhead 116 o Elimination of centralized mobility anchors and shift towards a 117 distributed mobility architecture, leveraging the edge compute at 118 radio-access network for offloading some of the subscriber 119 management services 121 o Co-existence with control-plane and user-plane separated 122 architecture; a stateless user-plane with no tunnels, and a 123 control plane with the business/service logic 125 o Support for services including accounting, charging, lawful- 126 interception and other user plane services 128 Currently, there is a study item in 3GPP to explore options for 129 simplifying the mobile user-plane. There are few proposals in IETF, 130 which are presented as candidate solutions for user-plane 131 simplification. However, each of these proposals come with certain 132 complexity and do not leverage the 3GPP control plane, or the 133 programmability aspects of the user-plane. For example, ILA defines 134 a translation scheme without the need for overlay tunnels, but it 135 also introduces significant amount of translation related state in 136 the user-plane, and additionally introduces a new control-plane 137 protocol for managing the mapping tables and the cache states. 138 Therefore, we believe that none of the currently known approaches can 139 adequately meet the stated goals for user-plane simplification. 141 This document describes a new approach for realizing a mobile user- 142 plane that does not require any fixed IP anchors. The first-hop 143 router on the link where the mobile node is attached remains as the 144 IP anchor and thereby eliminating the need for IP tunneling to some 145 central anchor node. Even when the mobile node moves in the network 146 and changes its point of attachment, the IP anchor is always the 147 first-hop router on that new link. The MFA entities will track the 148 mobile node's movements in the network and will ensure the mobile 149 node's IP flows always take the most optimal routing path. This is 150 achieved by MFA entities programming the needed traffic steering 151 rules for moving mobile node's IP packets directly between the 152 correspondent node and the mobile node's edge anchor, which can be 153 relocated to a new edge, e.g. in case of mobility. Furthermore, this 154 approach does not require a new control-plane protocol, but instead 155 leverages the SDN interfaces of the user-plane, and the mobility 156 events in the control-plane for managing IP mobility. The 157 architectural basis for this approach is the separation of control 158 and user plane, and the use of programmability constructs of the 159 user-plane for traffic steering. This approach is referred to as, 160 Mobility-aware Floating Anchor (MFA). The rest of the document 161 explains the operational details of the MFA approach. 163 2. Conventions and Terminology 165 2.1. Conventions 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 2.2. Terminology 173 All mobility related terms used in this document are to be 174 interpreted as defined in the IETF mobility specifications, including 175 [RFC5213] and [RFC6275]. Additionally, this document uses the 176 following terms: 178 MFA Domain 180 MFA domain refers to the network where the mobility management of 181 a mobile node is handled by the MFA entities. The MFA domain 182 includes MFA mobile node anchors, MFA corresponding node anchors, 183 and MFA node controller, between which security associations can 184 be set up for authorizing the configuration of traffic steering 185 policies and other mobility management functions. 187 MFA Mobile Node Anchor (MFA-MNA) 188 Its an MFA function located in the user-plane network very close 189 to the layer-2 access-point to where the mobile node is attached. 190 It is typically on the first-hop router for the mobile node's IP 191 traffic. The node hosting this function is required to support 192 the standard IPv6 packet forwarding function, FPC or a similar 193 interface for policy configuration, and packet steering functions 194 such as based on SRv6 or alternative means that can support per- 195 flow or per-flow-aggregate traffic steering. Typically, the MFA- 196 MNA function will be collocated with the User Plane Function (UPF) 197 in the 3GPP 5G system architecture. 199 MFA Corresponding Node Anchor (MFA-CNA) 201 Its an MFA function located in the user-plane node in the path 202 between the mobile node and the correspondent node. If the 203 correspondent node is another mobile node in the MFA domain, then 204 the MFA-CNA is on the first hop router on the link shared with the 205 correspondent node. The node hosting this function is required to 206 support the standard IPv6 packet forwarding function, FPC or a 207 similar interface for policy configuration, and packet steering 208 functions such as based on SRv6 or alternative means that can 209 support per-flow or per-flow-aggregate traffic steering. 210 Typically, the MFA-CNA function will be collocated with the IP 211 forwarding nodes on the N6 interface of the 3GPP 5G system 212 architecture. 214 MFA Node 216 A generic term used for referring to MFA-MNA, or the MFA-CNA. 218 MFA Node-Controller (MFA-NC) 220 The is the function that controls the forwarding policies on the 221 MFA-MNA and MFA-CNA nodes. This entity interfaces with the MFA 222 node using the FPC interface [I-D.ietf-dmm-fpc-cpdp], or a similar 223 interface that support user-plane policy configuration. This is 224 typically co-located with the SMF, or the AMF functions in the 225 3GPP 5G system architecture, and on WLAN controller in the case of 226 Wi-Fi access architectures. 228 Node Location Database (NLDB) 230 A database that contains the location information of every mobile 231 node that is part of the MFA domain and is currently attached to 232 the network. 234 Network Topology Database (NTDB) 235 A database that contains the MFA node information along with the 236 link state and directly connected neighbor information. 238 Home Network Prefix (HNP) 240 An IPv6 prefix assigned to the mobile node. This prefix is hosted 241 by the MFA-MNA on the access link shared with the mobile node. 242 The network will provide mobility support for the HNP prefixes. A 243 meta-data tag indicating the mobility property 244 [I-D.ietf-dmm-ondemand-mobility] is included in router 245 advertisements and in address assignment related protocol 246 messages. 248 Local Network Prefix (LNP) 250 An IPv6 prefix assigned to the mobile node. This prefix is hosted 251 by the MFA-MNA on the access link shared with the mobile node. 252 The network will not provide mobility support for the LNP 253 prefixes. A meta-data tag indicating that there is no mobility 254 support [I-D.ietf-dmm-ondemand-mobility] is included in router 255 advertisements and in address assignment related protocol 256 messages. 258 3. Overview 260 This specification describes the MFA protocol. The MFA protocol is 261 designed for providing mobility management support to a mobile node 262 without the need for a fixed IP anchor. In this approach the mobile 263 node's IP session is always anchored on the first-hop router sharing 264 the link with the mobile node. The entities in the MFA domain track 265 the mobile node's movements in the MFA domain and will provision the 266 forwarding states in the user-plane nodes for optimal routing and for 267 ensuring the anchor is always the first-hop router. Any time the 268 mobile node moves within the MFA domain and resulting in the mobile 269 node's IP flows going through the previous anchor, the mobility 270 entities detect this event and a corrective action is taken by 271 provisioning the forwarding nodes with the path stitching rules. The 272 result of this approach is an user-plane with no fixed anchors, and 273 dynamically programmed user-plane for mobility and optimal packet 274 routing. 276 The following are the key functional entities in the MFA domain: 278 o MFA Node Controller (MFA-NC) 280 o MFA Mobile Node Anchor (MFA-MNA) 281 o MFA Correspondent Node anchor (MFA-CNA) 283 The MFA-NC is typically collocated with the access network specific 284 control-plane functions. It interfaces with the radio network/ 285 authentication functions for detecting the mobile node's movements in 286 the MFA domain for managing the forwarding states in the user-plane 287 entities, MFA-MNA and MFA-CNA. The MFA node controller requires 288 access to node location database and network topology database. 289 These are the conceptual entities that can be realized using existing 290 elements that are already present in different access architectures. 292 The MFA-MNA and the MFA-CNA are the functions in the user-plane 293 network and they are collocated with the elements in the network that 294 perform IP packet forwarding functions. The MFA-MNA is typically 295 located on the first-hop router and whereas the MFA-CNA can be 296 collocated with the access-gateways and transit routers. These 297 entities interface with the MNA-NC using FPC 298 ([I-D.ietf-dmm-fpc-cpdp]), or an alternative interface), for managing 299 the IP forwarding policies. 301 +------+ MN Attach/Detach Triggers 302 | Auth |--------------. 303 | IWF | | 304 +------+ \|/ 305 +-----------------------+ 306 _ _ _ | MFA Node | 307 | | Controller |- - . 308 | +-----------------------+ | 309 __ _ _| _ _ | 310 [ Node ] | 311 | Location | . __ __|__ __ 312 | DB | / \ | Network | 313 +-=-=-=-=-=-+ | | Topology | 314 | | DB | 315 \|/ +=-=-=-=-=-=+ 317 Control-Plane (FPC Interface) 318 -------------------------------------------------------------------- 319 User-Plane 321 \ +----+ +----+ / 322 AP -|AG-1|------- -------|AG-4|- AP 323 / +----+ | Transit Router | +----+ \ 324 | +----+ | 325 | |TR-2| (CNA) | 326 | +----+ | 327 | | | 328 \ +----+ +----+ : +----+ +----+ / 329 AP -|AG-2|- - -|TR-1|- - - - - - - - - |TR-4|- - -|AG-5|- AP 330 / +----+ +----+ : +----+ +----+ \ 331 | | | 332 | +----+ | 333 | |TR-3| | 334 | +----+ | 335 \ +----+ | | | +----+ / 336 AP -|AG-3|------- | -------|AG-6|- AP 337 / +----+ | +----+ \ 338 Access-Gateway _----_ 339 (MNA) _( )_ 340 -( Internet )- 341 (_ _) 342 '----' 344 * MFA-MNA is collocated with the access gateways 345 ** MFA-CNA is collocated with the access gateways and transit routers 347 Figure 1: Example of a MFA Domain 349 3.1. The Network Topology Database 351 The network topology database contains the complete and the current 352 information about all the MFA nodes in the network. The information 353 includes the capabilities of each node, supported functions, 354 supported interfaces with the interface-type, connected neighbors, 355 hosted prefixes on each link, security configuration and other 356 related configuration elements. The topology database can be used to 357 determine the route between two nodes within the MFA domain, or the 358 best exit gateway for reaching a correspondent node outside the MFA 359 domain. 361 3.2. The Node Location Database 363 The node location database consists of location information of each 364 mobile node that is currently attached to the MFA domain. It also 365 includes the type of attachment, previous anchor, and other 366 information elements, such as the mobile node's connection status and 367 detailed or approximate location (e.g. tracking area) in case of 368 device dormancy. Typically, the MFA entities obtain this information 369 from the control-plane functions in the access network. For example, 370 a WLAN controller and the authentication functions will be able to 371 provide this information in IEEE 802.11 based networks. In 5G system 372 architecture this information can be obtained from AMF/SMF functions. 374 Below diagram is an example NLDB database. 376 +===============+===========+===========+============+ 377 | MN | Current | Previous | Handover | 378 | Identifier | Anchor | Anchor | Type | 379 +===============+===========+========================+ 380 | MN1@ietf.org | AG1 | - | NEW_ATTACH | 381 +---------------+-----------+-----------+------------+ 382 | MN2@ietf.org | AG6 | AG2 | HANDOVER | 383 +---------------+-----------+-----------+------------+ 384 | MN3@ietf.org | - | AG4 | UNKNOWN | 385 +---------------+-----------+-----------+------------+ 387 Figure 2: Example NLDB Table 389 3.3. Determination of the Correspondent Node Anchor 391 The anchor for a correspondent node is a MFA node that is closest to 392 the correspondent node and is in path for all the MN-CN IP traffic 393 flows. The MFA node controller leverages the topology database for 394 the CN-anchor determination. 396 If the correspondent node is another mobile node in the MFA domain, 397 then the CN-Anchor for that correspondent node is the access gateway 398 to which it is currently attached. 400 If the correspondent node is outside the MFA domain, then the CN- 401 anchor is typically the exit gateway, or any MFA node that is always 402 in path for reaching the CN's network. This is typically the PE 403 router of the data center that hosts the correspondent node service, 404 or a programmable data plane node inside the data center. 406 The below illustration is an example topology of a MFA domain. The 407 domain consists of MFA nodes, mobile and correspondent nodes. A 408 query for CN2's anchor should result in finding AG4, as that is the 409 MFA node in the traffic path and closest to CN2. Similarly, the 410 query for CN3's anchor which is outside the MFA domain should result 411 in finding TR3 as that is the last exit gateway in the MFA domain and 412 closest to the CN3. 414 AG1 AG4 - - CN2 415 | TR2 | 416 MN1- - -AG2-----TR1--|--TR4----AG5 417 | TR3 | 418 AG3 | AG6 419 {internet} 420 | 421 CN3 423 Figure 3: CN Anchor Determination - Example Topology 425 3.4. Traffic Steering Approaches 427 The MFA nodes support traffic steering approaches for moving the 428 mobile node's IP traffic between the MFA nodes over the most optimal 429 routing path. Segment Routing for IPv6 (SRv6) is one approach that 430 this specification focuses on for steering the traffic between two 431 points in the network, whereas the MFA-NC can utilize the available 432 information from Network Topology- and Node Location Database to 433 enforce policies in the MFA nodes in support of alternative data 434 plane protocols to enable traffic steering. Future versions of the 435 document may include information about additional mechanisms. 437 When using SRv6 for traffic steering, the approaches specified in 438 [I-D.ietf-dmm-srv6-mobile-uplane] and 439 [I-D.filsfils-spring-srv6-network-programming] will be leveraged for 440 moving the mobile node's IP traffic between the MFA-MNA and the MFA- 441 CNA nodes. The SRv6 policy including the SID information and the 442 associated functions are pushed from the MFA Node controller to the 443 MFA nodes. This document mostly leverages the functions specified in 444 those documents, but may require some changes to the SRv6 functions 445 for reporting the flow meta-data of the non-optimal traffic flows to 446 the MFA node controller. The definitions of those SRv6 functions 447 will be specified in either in the future revisions of this document, 448 or in other IETF documents. 450 The following table captures the possible SRv6 function activation 451 when IP traffic steering approach is in use. This is only an 452 example. 454 +-----------+--------------------------+--------------------------+ 455 | FLOW | MN-Anchor | CN-Anchor | 456 | DIRECTION | | | 457 +-----------+--------------------------+--------------------------+ 458 | | Variant of T.Insert | Variant of End.X | 459 | | | | 460 | MN to CN | (Transit with insertion |(Or, End.B6, instantiation| 461 | | of SRv6 policy and may | of a binding SID); | 462 | | require trigger to MFA-NC| Or, End.T for internet | 463 | | such as activation of | traffic | 464 | | Flow.Report) | | 465 | | | | 466 +-----------+--------------------------+--------------------------+ 467 | | Variant of End.X | Variant of T.Insert | 468 | | | | 469 | | (Layer-3 cross connect | (Transit with insertion | 470 | |(Or, End.B6, instantiation| of SRv6 policy and may | 471 | CN to MN | of a binding SID | require trigger to MFA-NC| 472 | | | such as activation of | 473 | | | Flow.Report. | 474 | | | | 475 +-----------+--------------------------+--------------------------+ 477 Figure 4: Using SRv6 for Traffic Steering - Example 479 3.5. Mobile Node Attachment Triggers 481 The MFA domain relies on the access network for certain key events 482 related to the mobile node's movements in the network. These events 483 include: 485 o INITIAL_ATTACH - Initial Attachment of the mobile node to the MFA 486 domain 488 o HANDOVER - Layer-2/Layer-3 Handover of the mobile node within the 489 MFA Domain 491 o DETACH - Detachment of the mobile node from the MFA domain 493 o UNKNOWN - State of the mobile node is Unknown; TBD 495 The MFA node controller interfaces with the radio network and the 496 authentication infrastructure for these events. These events drive 497 the policy configuration on the MFA nodes. 499 3.6. Programming the User-plane 501 The MFA-NC leverages suitable southbound semantics and operation to 502 enforce traffic steering rules in the selected access gateways (AG) 503 and/or transient routers (TR). One suitable data model and operation 504 is being specified in [I-D.ietf-dmm-fpc-cpdp] for Forwarding Policy 505 Configuration (FPC). The model and operation applies in between a 506 FPC Client function and an FPC Agent function. 508 A deployment of FPC with the specification per this document about 509 MFA, the FPC Client is co-located with the MFA-NC, whereas the FPC 510 Agent function is co-located with functions that enforce user plane 511 configuration per the rules received from the FPC Client. The FPC 512 Agent can either reside on an transport network- or SDN controller 513 and be in charge of the configuration of multiple user plane nodes 514 (MFA-TR, MFA-MA, MFA-CA), or an FPC Agent resides on each MFA node. 516 The following figure schematically draws an example how FPC can 517 integrate with the functional MFA architecture per this 518 specification. The example assumes that MFA nodes can be 519 programmatically configured by an SDN Controller. Details about 520 whether a single or multiple distributed SDN Controllers are deployed 521 are left out. 523 The FPC data model includes the following components: 525 Data Plane Nodes (DPN) Model: 527 Representation of nodes in the data plane which can be selected 528 and enforce rules per the control plane's directives. DPNs take a 529 particular role, which is identified in the model. In the context 530 of this document, the role of a DPN can be, for example, an anchor 531 node or a transit router. 533 Topology Model: 535 Representation of DPNs in the network and associate in between 536 DPNs. The FPC Client and Agent use the Topology to select most 537 appropriate data plane node resources for a communication. In the 538 context of this document, Topology has can be leveraged to 539 implement the NTDB for the selection of steering paths and 540 associated DPNs which function as MFA-MNA, MFA-CNA, or MFA-TR. 542 Policy Model: 544 Defines and identifies rules for enforcement at DPNs. 546 Mobility-Context: 548 Holds information associated with a mobile node and its mobility 549 sessions. In the context of this document, Mobility-Context can 550 be enriched with traffic steering related rules. 552 Monitor: 554 Provides mechanisms to register monitors (traffic, events) in the 555 data plane and define status reporting schedules, which can be 556 periodic or event-based. In the context of this document, 557 Monitors may be used to detect traffic from a CN to an MN on an 558 MFA node, which could result in a notification to the MFA-NC for 559 path optimization and associated steering of traffic to the MN's 560 current MFA-MNA. 562 Please refer to [I-D.ietf-dmm-fpc-cpdp] for model and operational 563 details. 565 +-----------------------+ 566 +----+ | MFA Node | +----+ 567 |NLDB+----+ Controller +----+NTDB| 568 +----+ +-----+ - - - - +----+ +----+ 569 | FPC Client | 570 +------------+ 571 | 572 | FPC models and operation 573 | 574 +------------+ 575 | FPC Agent | 576 +-+ - - - - +-+ 577 | SDN Controller | 578 +----------------+ 579 ^ 580 +---------+----------+-----------+----------+ 581 | | +---+ | | 582 v v |TR2| v v 583 +-------+---+ +---+ +---+ +---+ +---+-------+ 584 //-|MFA-NMA/AG2|-----|TR1|----------------|TR4|------|AG4/MFA-CAN|-// 585 +-------+---+ +---+ +---+ +---+-------+ 587 Figure 5: Deployment of the FPC models and operation in between the 588 MFA-NC and MFA nodes on the user plane 590 4. Life of a Mobile Node in a MFA Domain 592 Reference Topology 593 +-----------------------+ 594 | MFA Node | 595 | Controller | 596 +-----------------------+ 598 \ +----+ +----+ / 599 AP -|AG-1|----- -----|AG-4|- AP CN1 600 / +----+ | MFA Transit Router | +----+ \ 601 | +----+ | 602 | |TR-2| | 603 | +----+ | 604 | | | 605 \ +----+ +----+ : +----+ +----+ / 606 MN AP -|AG-2|- -|TR-1|- - - - - - - - - |TR-4|- -|AG-5|- AP 607 / +----+ +----+ : +----+ +----+ \ 608 | | | 609 | +----+ | 610 | |TR-3| | 611 | +----+ | 612 \ +----+ | | | +----+ / 613 AP -|AG-3|----- | -----|AG-6|- AP 614 / +----+ | +----+ \ 615 MFA Access-Gateway _----_ 616 _( )_ 617 -( Internet )---- CN2 618 (_ _) 619 '----' 621 Figure 6: Reference Topology 623 4.1. MN's Initial Attachment to a MFA Domain 625 A mobile node, MN enters the MFA domain and attaches to the access 626 point on the gateway AG-2. 628 +===+ +--+ +----+ +----+ +--+ +===+ +===+ 629 |MN1| |AP| |AG-2| |AIWF| |NC| |CN1| |CN2| 630 +===+ +--+ +----+ +----+ +--+ +===+ +===+ 631 | | | | | | | 632 1 *-ATTACH-* | | | | | 633 | | | | | | | 634 2 *<-------*-AUTH------------>* | | | 635 | | | | | | | 636 3 | | | *-NOTIFY-->* | | 637 | | | | * | | 638 4 | | *<-PROV---------------* | | 639 | | | | | | | 640 5 *<--IP_CONFIG--->* | | | | 641 | | | | | | | 642 6 *< -(OPTIMIZED) -X- USER_PLANE_PACKET (HNP Flow)->* | 643 | | | | | | | 644 7 *< -(OPTIMIZED)- X- USER_PLANE_PACKET (LNP Flow) - - - - - >* 645 | | | | | | | 647 Figure 7: Mobile Node's Initial Attachment to a MFA Domain 649 o 1-ATTACH: The mobile node with NAI (MN1@ietf.org) performs a 650 layer-2 attach to the access point. This access point is 651 connected to the access-gateway, AG-2, over a layer-2 link. The 652 mobile node anchor function is supported on AG-2 and is active. 654 o 2-AUTH: The mobile node completes the access authentication access 655 technology specific access mechanisms. The mobile node's identity 656 is established and is authorized for MFA domain access. The 657 Authentication interworking (AUTH-IWK) function records the mobile 658 node's identity, type of attach as INITIAL_ATTACH, and the current 659 location of the mobile node in the access-network, to the node 660 location database. 662 o 3-NOTIFY: The Auth-IWK function delivers the attach event to the 663 MFA node controller. The information elements that are delivered 664 include the mobile node identifier (MN-1@ietf.org), type of attach 665 as INITIAL_ATTACH, and the identity of the access gateway, which 666 is AG-2. 668 o 4-PROV: The NC provisions AG-2 for hosting the MN's home-network 669 prefix(es). The assigned prefixes are HNP, H1::/64 and LNP, 670 L1::/64. These prefixes are from a larger aggregate block (Ex: 671 H1:://48; L1::/48) which are topologically anchored on AG-2. The 672 policies for hosting the HNP prefixes on the link are provisioned 673 using FPC interface. The AG-2 will include meta-data in the IPv6 674 RA messages for indicating the properties of the prefixes; H1::/64 675 as the prefix with mobility support and L1 as the prefix with no 676 mobility support. 678 o 5-IP_CONFIG: The mobile node generates one ore more IPv6 addresses 679 using the prefixes H1 and L1. The generated addresses are tagged 680 with the property meta-data in the host's source address policy 681 table. This allows the applications on the mobile node to pick 682 the addresses based on the application's mobility requirements. 684 o 6-USER_PLANE_PACKET: The mobile node establishes IP flow with CN1. 685 The source address is based on the prefix H1. This IP address 686 will have mobility support. The packets associated with this flow 687 will take the optimized routing path. There are no tunnels, or 688 special traffic steering rules in the network. 690 o 7-USER_PLANE_PACKET: The mobile node establishes IP flow with CN2. 691 The source address is based on the prefix L1. This IP address 692 will not have mobility support. There are no tunnels, or special 693 traffic steering rules in the network. 695 4.2. MN's Roaming within the MFA Domain 697 The mobile node roams and changes its point of attachment. It was 698 initially attached to the access network on AG-2 and now it attaches 699 to access network on AG-6. At the time of roaming, the mobile node 700 had two active IPv6 prefixes HNP, H1::/64 and LNP, L1::/64 and there 701 were two active IP flows, one to CN1 using an IPv6 address from the 702 prefix H1::/64 and another flow to CN2 using an IPv6 address from the 703 prefix L1:://64. The MFA network will ensure the prefix H1::/64 will 704 be routable on the new network and the active flow to CN1 will 705 survive, however the prefix L1::/64 will not be routable in the new 706 access network and therefore the flow to CN2 will not survive. 708 +===+ +--+ +----+ +----+ +--+ +----+ +-----+ +===+ 709 |MN1| |AP| |AG-6| |AIWF| |NC| |AG-2| |CN1-A| |CN1| 710 +===+ +--+ +----+ +----+ +--+ +----+ +-----+ +===+ 711 | | | | | | | | 712 1 *-ATTACH-* | | | | | | 713 | | | | | | | | 714 2 *<-AUTH--------------->* | | | | 715 3 | | | *-NOTIFY--->* | | | 716 4 | | *<-PROV-------------* | | | 717 5 | | | | *-PROV--->* | | 718 | | | | | | | | 719 6 *<-IP-CONFIG-->* | | | | | 720 | | | | | | | | 721 7 *<-(NON_OPTIM)-X - USER_PLANE_PACKET - - - - X - - - -X- - ->* 722 | | | | | * | | 723 8 | | | | *<-REPORT-* | | 724 9 | | *<-FLOW_STEERING----* | | | 725 10| | | | *-FLOW_STEERING--->* | 726 | | | | | | | | 727 11*<-(OPTIMIZED)-X - USER_PLANE_PACKET -(HNP Flow) - - -X- - ->* 728 | | | | | | | | 730 Figure 8: Mobile Node's Roaming within the MFA Domain 732 o 1-ATTACH: The mobile node with NAI (MN1@ietf.org) roams in the 733 network from AG-2 to AG-6. 735 o 2-AUTH: The mobile node completes the handover to the new access 736 network using access network specific security mechanisms. The 737 Auth-IWK function updates the mobile node's location in the node- 738 location database. The updated entry in the node location 739 database will include the mobile node's NAI, attach type as 740 HANDOVER, and the current access-network location as AG-6. 742 o 3-NOTIFY: The Auth-IWK function function delivers the handover 743 event to the MFA node controller. The information elements that 744 are delivered include the mobile node identifier (MN-1@ietf.org), 745 type of attach as HANDOVER, and the identity of the access gateway 746 as AG-6. 748 o 4-IP_PROV: The NC provisions AG-6 for hosting the MN's home- 749 network prefix and local network prefix. The home network prefix, 750 H1::/64 is from the previous anchor, AG-2 and is not topologically 751 anchored on AG-6. However, for supporting mobility the prefix is 752 hosted on the access link while the mobile node is attached to 753 that access network and till there are active flows. The NC also 754 provisions AG-6 for hosting a new local network prefix, L2::/64. 755 This prefix, L2::/64 is from a larger aggregate block that is 756 topologically anchored on AG-6. The AG-6 will include meta-data 757 in the IPv6 RA messages for indicating the properties of the 758 prefixes; H1::/64 as the prefix with mobility support and L2::/64 759 as the prefix with no mobility support. The NC also provisions a 760 traffic steering rule to steer all uplink IP traffic with source 761 address H1::/64 through the previous anchor AG-2. 763 o 5-IP_PROV: The NC provisions AG-2 to steer all IP traffic to 764 destination addresses matching the prefix, H1::/64 to AG-6, and it 765 also provisions a rule to report flow meta-data of those flows 766 taking the non-optimal traffic path through AG-2. This 767 essentially allows the NC to learn about any mobile node's IP 768 flows still going through AG-2, so it can stitch the optimized 769 path for those flows and remove AG-2 from the path for those 770 flows. 772 o 6-IP_CONFIG: The prefix H1::/64, obtained at the new location, 773 will continue to be available on the new access link. The new 774 local network prefix L2::/64 will also be available on the new 775 access link and will be marked as a prefix with no mobility 776 property. The mobile node may generate one, or more IPv6 777 addresses using the prefix L2::/64. The prefix L1::/64 is no 778 longer hosted on the new link and the mobile node will remove it 779 from interface configuration. 781 o 7-USER_PLANE_PACKET: Any uplink IP link from CN1 will come to 782 AG-2, as its the topological anchor for that address/prefix and 783 AG-2 will steer the traffic directly to AG-6. On detecting an IP 784 flow with the IP address belonging to prefix H1::/64, AG-2 will 785 report the CN1-MN1 flow meta-data to NC. 787 o 8-Report: The NC on receiving this event will lookup the CN anchor 788 for the flow in its node location database. If the CN is another 789 MN within the MFA domain, its current anchor information is 790 retrieved from the node location database. However, if the CN is 791 a node outside the MFA domain, the anchor for this node can be any 792 transit router in the MFA domain which is always in path for that 793 destination. The CN-anchor determination for nodes outside the 794 MFA domain will be based on the network topology database. 796 o 9-FLOW_STEERING: The NC inserts a IP traffic steering rule on AG-6 797 to steer the MN1-CN1's IP flows using H1::/64 directly to CN1's 798 anchor which is CN1-A, and bypassing AG-2. 800 o 10-FLOW_STEERING: The NC inserts a IP traffic steering rule on 801 CN1-A to steer the MN1-CN1 IP flows using H1::/64 directly to 802 MN1's current anchor which is AG-6, and bypassing AG-2. 804 o 11-USER_PLANE_PACKET: The MN1-CN1's IP flows using H1::/64 will be 805 steered directly from CN1-A to AG-6; AG-2 will not be in the path. 807 4.3. Traffic Steering State Removal 809 The mobile node's IP flows that were established at the previous 810 location are no longer active. The steering state that was 811 introduced at AG-6 and CN1-A will removed on detecting the inactive 812 flows. The network may also optionally choose to withdraw the prefix 813 H1::/64 and may assign a new HNP prefix which are topologically 814 anchored in the new location. 816 +===+ +--+ +----+ +----+ +--+ +----+ +-----+ +===+ 817 |MN1| |AP| |AG-6| |AIWF| |NC| |AG-2| |CN1-A| |CN1| 818 +===+ +--+ +----+ +----+ +--+ +----+ +-----+ +===+ 819 | | | | | | | | 820 *<- - - - - - -X - USER-PLANE-PACKET - - - - - - - - -X- - ->* 821 | | | | | | | | 822 1 |- - - - - - - * - INACTIVE_FLOW_DETECT - - - - - - - * - - -| 823 | | * | | | * | 824 2 | | *----REPORT-------->*<----REPORT-------* | 825 | | *<-REMOVE_STATE-----* | | | 826 | | | | *-REMOVE_STATE-----> | 827 | | | | | | | | 829 Figure 9: State Removal 831 o 1-IN_ACTIVE_FLOW_DETECT: At some point the MN1-CN1 flow using the 832 prefix H1::/64 is no longer active. 834 o 2-REPORT: Both AG-6 and AG-2 will detect the inactive flows and 835 may report this event to the NC. The steering state associated 836 with MN1-CN1 flow using the prefix H1::/64 may be removed prior to 837 reporting to the NC. Optionally, the NC on receiving the 838 INACTIVE_FLOW_DETECT event may provision AG-6 and CN1-A to remove 839 the steering state. 841 o 4-REMOVE_STATE: 843 4.4. Mobile Node's new IP flows 845 The mobile node's IP flows that were established at the previous 846 location are no longer active and any created steering state was 847 removed. The network may optionally choose to withdraw the prefix 848 H1::/64 and may assign a new HNP prefix which is topologically 849 anchored in the new location. All new IP flows will use the new 850 prefix and the flows will take optimal routing path. 852 +===+ +--+ +----+ +----+ +--+ +===+ 853 |MN1| |AP| |AG-6| |AIWF| |NC| |CN3| 854 +===+ +--+ +----+ +----+ +--+ +===+ 855 | | | | | | 856 1 *<- - - - - - -X - USER-PLANE-PACKET - - - - - - - - - - ->* 857 | | | | | | 859 Figure 10: New Flows 861 o 1-USER_PLANE_PACKET: The mobile node's has established some IP 862 flows using the IP address from the new HNP and LNP assigned at 863 the new location. These IP flows will take optimal routing path 864 and there is no need for any steering state, or the use of tunnels 865 in the network for the mobile node's traffic. 867 5. MFA in 5G System Architecture 869 3GPP is specifying the 5G System Architecture, which follows a split 870 between control- and data plane. Key control plane functions, which 871 have interfaces to the data plane, are the Access Network and 872 Mobility Management Function (AMF), and the Session Management 873 Function (SMF). AMF and SMF cooperate to set up data plane nodes in 874 the (radio) access network ((R)AN) and the core network, which 875 comprises one or multiple User Plane Functions (UPF). As soon as a 876 mobile node (UE) attaches to the network, as Packet Data Unit (PDU) 877 Session is established and the SMF in the control plane selects one 878 UPF as PDU Session Anchor, which serves also as IP address anchor. 879 The SMF may select one more UPF on the path in between the PDU 880 Session Anchor and the (R)AN, which enables routing traffic in 881 between the UE and a local packet data network (PDN) with a 882 correspondent node or service without the need to traverse the PDU 883 Session Anchor. 885 In the view of MFA, each UPF can represent a locator for the UE's 886 downlink traffic on the N9 as well as on the N6 reference point in 887 the 5G System Architecture. Since the SMF is in charge of UPF 888 selection and configuration, the MFA-NC can leverage the SMF to 889 retrieve node location information per this specification's procedure 890 to access the NLDB from the MFA-NC. For MFA node selection and 891 traffic steering, the MFA-NC may need more information about the data 892 plane in terms of the transport network nodes and topology. Details 893 about the NTDB are left out of this version of the document, but a 894 realization may exploit available Topology information per 895 [I-D.ietf-dmm-fpc-cpdp]. 897 In the figure below, a UE's UPFs can function as MFA nodes, either as 898 MFA-MNA or as MFA-CNA in case of mobile to mobile communication. 899 Other transport network nodes, which may function as MFA-CNA for the 900 UE's communication with a (non-mobile) correspondent node or service, 901 are not explicitly depicted in the below figure. The MFA function 902 can be tightly coupled with a UFP (co-located) or loosely coupled 903 (separated). The MFA-NC utilized the FPC models and operation to 904 enforce traffic steering policies in the MFA nodes. In case of loose 905 coupling, the SMF utilizes the N4 protocol per the 3GPP standard to 906 configure the selected UPF, whereas the MFA-NC uses FPC to enforce 907 policies in the associated (loosely coupled) MFA node. In case of 908 tight coupling, the MFA-NC may be co-located with the SMF and a 909 single reference point and associated protocol may be used in between 910 the SMF/MFA-NC and a UPF/MFA node. 912 +----+ +----+ +----+ +----+ +----+ +----+ +----+ 913 |NSSF| |NEF | |NRF | |AUSF| |UDM | |PCF | | AF | 914 +----+ +----+ +----+ +----+ +----+ +----+ +----+ 915 | | | | | | | 916 ---------------------------------------------------------- 917 | | | 918 +-----+ +-----+ +------+ 919 +-------| AMF | | SMF |----+----|MFA-NC|--+ 920 | +-----+ +-----+ | +------+ | 921 | | N4| NLDB | NTDB 922 | | | | 923 | | FPC +---:----------------+ 924 | | | | | FPC 925 |N1 | N2 +-|---+------+ +-------+--------+ 926 | | | | N4 | | | 927 +----+ +-----+ +------+ +------+ | 928 | UE | |(R)AN|-----| UPF |------| UPF |-----------(PDN) 929 +----+ +-----+ N3 | + | N9 | + | N6 930 | MFA | | MFA | 931 +------+ +------+ 932 Figure 11: New Flows 934 6. IANA Considerations 936 TBD 938 7. Security Considerations 940 This specification allows a mobility node controller to provision IP 941 traffic steering policies on the user plane nodes. It essentially 942 leverages the FPC interface [I-D.ietf-dmm-fpc-cpdp] for interfacing 943 with the user-plane anchor nodes. The security considerations 944 specified in the FPC specification are sufficient for securing the 945 messages carried on this interface. 947 The traffic steering rules that are provisioned on the MFA nodes by 948 the MFA node controller are the standard policy rules that the FPC 949 interface defines and does not require any new security 950 considerations. 952 8. Acknowledgements 954 TBD 956 9. References 958 9.1. Normative References 960 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 961 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 962 RFC2119, March 1997, 963 . 965 9.2. Informative References 967 [I-D.filsfils-spring-srv6-network-programming] 968 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 969 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 970 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 971 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 972 Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., 973 Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. 974 Camarillo, "SRv6 Network Programming", 975 draft-filsfils-spring-srv6-network-programming-03 (work in 976 progress), December 2017. 978 [I-D.ietf-dmm-fpc-cpdp] 979 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 980 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 981 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-09 982 (work in progress), October 2017. 984 [I-D.ietf-dmm-ondemand-mobility] 985 Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. 986 Jeon, "On Demand Mobility Management", 987 draft-ietf-dmm-ondemand-mobility-13 (work in progress), 988 January 2018. 990 [I-D.ietf-dmm-srv6-mobile-uplane] 991 Matsushima, S., Filsfils, C., Kohno, M., 992 daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing 993 IPv6 for Mobile User-Plane", 994 draft-ietf-dmm-srv6-mobile-uplane-00 (work in progress), 995 November 2017. 997 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 998 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 999 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1000 . 1002 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1003 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, 1004 July 2011, . 1006 Authors' Addresses 1008 Sri Gundavelli 1009 Cisco 1010 170 West Tasman Drive 1011 San Jose, CA 95134 1012 USA 1014 Email: sgundave@cisco.com 1015 Marco Liebsch 1016 NEC 1017 Kurfuersten-Anlage 36 1018 D-69115 Heidelberg, 1019 Germany 1021 Email: liebsch@neclab.eu 1023 Satoru Matsushima 1024 SoftBank 1025 Tokyo, 1026 Japan 1028 Email: satoru.matsushima@g.softbank.co.jp