--- 1/draft-ietf-dmm-pmipv6-dlif-01.txt 2018-08-29 03:13:07.733803830 -0700 +++ 2/draft-ietf-dmm-pmipv6-dlif-02.txt 2018-08-29 03:13:07.805805580 -0700 @@ -1,41 +1,41 @@ DMM Working Group CJ. Bernardos Internet-Draft A. de la Oliva Intended status: Standards Track UC3M -Expires: December 31, 2018 F. Giust - NEC +Expires: March 2, 2019 F. Giust + Athonet JC. Zuniga SIGFOX A. Mourad InterDigital - June 29, 2018 + August 29, 2018 Proxy Mobile IPv6 extensions for Distributed Mobility Management - draft-ietf-dmm-pmipv6-dlif-01 + draft-ietf-dmm-pmipv6-dlif-02 Abstract Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does - not rely on centralized deployed anchors to provide IP mobility + not rely on centrally deployed anchors to provide IP mobility support. There are many different approaches to address Distributed Mobility Management, as for example extending network-based mobility protocols - (like Proxy Mobile IPv6), or client-based mobility protocols (as + (like Proxy Mobile IPv6), or client-based mobility protocols (like Mobile IPv6), among others. This document follows the former - approach, and proposes a solution based on Proxy Mobile IPv6 in which + approach and proposes a solution based on Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router (called mobility anchor and access router). The mobility anchor and access router is an enhanced access router which is also able to operate as - local mobility anchor or mobility access gateway, on a per prefix + a local mobility anchor or mobility access gateway, on a per prefix basis. The document focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. @@ -47,21 +47,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 31, 2018. + This Internet-Draft will expire on March 2, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -78,79 +78,79 @@ 3. PMIPv6 DMM extensions . . . . . . . . . . . . . . . . . . . . 5 3.1. Initial registration . . . . . . . . . . . . . . . . . . 7 3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 8 3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 10 3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 11 3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 12 3.6. The Distributed Logical Interface (DLIF) concept . . . . 12 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 16 4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 17 - 4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 17 - 4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 18 - 4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 19 + 4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 18 + 4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 19 + 4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 20 4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 21 - 4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 21 + 4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 22 4.8. DLIF Link-layer Address Option . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 - 8.2. Informative References . . . . . . . . . . . . . . . . . 24 + 8.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. Comparison with Requirement document . . . . . . . . 25 A.1. Distributed mobility management . . . . . . . . . . . . . 25 A.2. Bypassable network-layer mobility support for each application session . . . . . . . . . . . . . . . . . . . 26 A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 26 A.4. Existing mobility protocols . . . . . . . . . . . . . . . 26 A.5. Coexistence with deployed networks/hosts and operability across different networks . . . . . . . . . . . . . . . . 27 A.6. Operation and management considerations . . . . . . . . . 27 A.7. Security considerations . . . . . . . . . . . . . . . . . 27 A.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix B. Implementation experience . . . . . . . . . . . . . 28 Appendix C. Applicability to the fog environment . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction The Distributed Mobility Management (DMM) paradigm aims at minimizing - the impact of currently standardized mobility management solutions, + the impact of currently standardized mobility management solutions which are centralized (at least to a considerable extent). Current IP mobility solutions, standardized with the names of Mobile - IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213], just to cite the two - most relevant examples, offer mobility support at the cost of + IPv6 [RFC6275], or Proxy Mobile IPv6 (PMIPv6) [RFC5213], just to cite + the two most relevant examples, offer mobility support at the cost of handling operations at a cardinal point, the mobility anchor (i.e., the home agent for Mobile IPv6, and the local mobility anchor for Proxy Mobile IPv6), and burdening it with data forwarding and control mechanisms for a great amount of users. As stated in [RFC7333], centralized mobility solutions are prone to several problems and limitations: longer (sub-optimal) routing paths, scalability problems, signaling overhead (and most likely a longer associated handover latency), more complex network deployment, higher vulnerability due to the existence of a potential single point of - failure, and lack of granularity on the mobility management service + failure, and lack of granularity of the mobility management service (i.e., mobility is offered on a per-node basis, not being possible to define finer granularity policies, as for example per-application). The purpose of Distributed Mobility Management is to overcome the limitations of the traditional centralized mobility management [RFC7333] [RFC7429]; the main concept behind DMM solutions is indeed - bringing the mobility anchor closer to the MN. Following this idea, - in our proposal, the central anchor is moved to the edge of the - network, being deployed in the default gateway of the mobile node. - That is, the first elements that provide IP connectivity to a set of - MNs are also the mobility managers for those MNs. In the following, - we will call these entities Mobility Anchor and Access Routers - (MAARs). + bringing the mobility anchor closer to the Mobile Node (MN). + Following this idea, in our proposal, the central anchor is moved to + the edge of the network, being deployed in the default gateway of the + mobile node. That is, the first elements that provide IP + connectivity to a set of MNs are also the mobility managers for those + MNs. In the following, we will call these entities Mobility Anchor + and Access Routers (MAARs). This document focuses on network-based DMM, hence the starting point is making PMIPv6 working in a distributed manner [RFC7429]. Mobility is handled by the network without the MNs involvement, but, differently from PMIPv6, when the MN moves from one access network to another, it also changes anchor router, hence requiring signaling between the anchors to retrieve the MN's previous location(s). Also, a key-aspect of network-based DMM, is that a prefix pool belongs exclusively to each MAAR, in the sense that those prefixes are assigned by the MAAR to the MNs attached to it, and they are routable @@ -178,141 +178,140 @@ Proxy Care-of Address (P-CoA) Proxy Binding Update (PBU) Proxy Binding Acknowledgement (PBA) The following terms used in this document are defined in the DMM Deployment Models and Architectural Considerations document [I-D.ietf-dmm-deployment-models]: - Home Control-Plane Anchor (H-CPA) + Home Control-Plane Anchor (Home-CPA) Home Data Plane Anchor (Home-DPA) Access Control Plane Node (Access-CPN) Access Data Plane Node (Access-DPN) The following terms are defined and used in this document: MAAR (Mobility Anchor and Access Router). First hop router where the mobile nodes attach to. It also plays the role of mobility manager for the IPv6 prefixes it anchors, running the functionalities of PMIP's MAG and LMA. Depending on the prefix, it plays the role of Access-DPN, Home-DPA and Access-CPN. CMD (Central Mobility Database). Node that stores the BCEs allocated - for the MNs in the mobility domain. It plays the role of H-CPA. + for the MNs in the mobility domain. It plays the role of Home- + CPA. P-MAAR (Previous MAAR). MAAR which was previously visited by the MN and is still involved in an active flow using an IPv6 prefix it has advertised to the MN (i.e., MAAR where that IPv6 prefix is - anchored). There might be multiple P-MAARs for an MN's mobility - session. It plays the role of Home-DPA. + anchored). It plays the role of Home-DPA for the flows it is + still serving for the MN's mobility session. There might be + multiple P-MAARs for an MN's mobility session. S-MAAR (Serving MAAR). MAAR which the MN is currently attached to. Depending on the prefix, it plays the role of Access-DPN, Home-DPA and Access-CPN. DLIF (Distributed Logical Interface). It is a logical interface at the IP stack of the MAAR. For each active prefix used by the - mobile node, the serving MAAR has a DLIF configured (associated to - the anchoring MAAR). In this way, a serving MAAR exposes itself - towards each MN as multiple routers, one per active anchoring - MAAR. + mobile node, the S-MAAR has a DLIF configured (associated to each + MAAR still anchoring flows). In this way, a S-MAAR exposes itself + towards each MN as multiple routers, one as itself and one per + P-MAAR. 3. PMIPv6 DMM extensions - The solution consists in de-coupling the entities that participate in + The solution consists of de-coupling the entities that participate in the data and the control planes: the data plane becomes distributed and managed by the MAARs near the edge of the network, while the - control plane, besides on the MAARs, relies on a central entity + control plane, besides those on the MAARs, relies on a central entity called Central Mobility Database (CMD). In the proposed architecture, the hierarchy present in PMIPv6 between LMA and MAG is preserved, but with the following substantial variations: o The LMA is relieved from the data forwarding role, only the Binding Cache and its management operations are maintained. Hence the LMA is renamed into Central Mobility Database (CMD), which is - therefore an H-CPA. Also, the CMD is able to send and parse both - PBU and PBA messages. + therefore an Home-CPA. Also, the CMD is able to send and parse + both PBU and PBA messages. o The MAG is enriched with the LMA functionalities, hence the name Mobility Anchor and Access Router (MAAR). It maintains a local Binding Cache for the MNs that are attached to it and it is able to send and parse PBU and PBA messages. - o The binding cache will have to be extended to include information - regarding previous MAARs where the mobile node was anchored and - still retains active data sessions, see Appendix B for further - details. + o The binding cache will be extended to include information + regarding P-MAARs where the mobile node was anchored and still + retains active data sessions, see Appendix B for further details. o Each MAAR has a unique set of global prefixes (which are configurable), that can be allocated by the MAAR to the MNs, but must be exclusive to that MAAR, i.e. no other MAAR can allocate the same prefixes. - The MAARs leverage on the Central Mobility Database (CMD) to access - and update information related to the MNs, stored as mobility - sessions; hence, a centralized node maintains a global view on the - status of the network. The CMD is queried whenever a MN is detected - to join/leave the mobility domain. It might be a fresh attachment, a - detachment or a handover, but as MAARs are not aware of past - information related to a mobility session, they contact the CMD to - retrieve the data of interest and eventually take the appropriate - action. The procedure adopted for the query and the messages - exchange sequence might vary to optimize the update latency and/or - the signaling overhead. Here is presented one method for the initial - registration, and three different approaches to update the mobility - sessions using PBUs and PBAs. Each approach assigns a different role - to the CMD: + The MAARs leverage the Central Mobility Database (CMD) to access and + update information related to the MNs, stored as mobility sessions; + hence, a centralized node maintains a global view of the network + status. The CMD is queried whenever a MN is detected to join/leave + the mobility domain. It might be a fresh attachment, a detachment or + a handover, but as MAARs are not aware of past information related to + a mobility session, they contact the CMD to retrieve the data of + interest and eventually take the appropriate action. The procedure + adopted for the query and the messages exchange sequence might vary + to optimize the update latency and/or the signaling overhead. Here + is presented one method for the initial registration, and three + different approaches to update the mobility sessions using PBUs and + PBAs. Each approach assigns a different role to the CMD: o The CMD is a PBU/PBA relay; o The CMD is only a MAAR locator; o The CMD is a PBU/PBA proxy. This solution can be categorized under Model-1: Split Home Anchor Mode in [I-D.ietf-dmm-deployment-models]. As another note, the solution described in this document allows performing per-prefix anchoring decisions, to support e.g., some flows to be anchored at a central Home-DPA (like a traditional LMA) or to enable an application to switch to the locally anchored prefix to gain route optimization, as indicated in [I-D.ietf-dmm-ondemand-mobility]. - Note that an MN MAY move across diferent MAARs, which might involve - that several P-MAARs exist at a given moment of time, each of them + Note that a MN MAY move across different MAARs, which might result in + several P-MAARs existing at a given moment of time, each of them anchoring a prefix used by the MN. 3.1. Initial registration - Upon the MN's attachment to a MAAR, say MAAR1, if the MN is - authorized for the service, an IPv6 global prefix belonging to the - MAAR's prefix pool is reserved for it (Pref1) into a temporary - Binding Cache Entry (BCE) allocated locally. The prefix is sent in a - [RFC5213] PBU with the MN's Identifier (MN-ID) to the CMD, which, - since the session is new, stores a permanent BCE containing as main - fields the MN-ID, the MN's prefix and MAAR1's address as Proxy-CoA. - The CMD replies to MAAR1 with a PBA including the usual options - defined in PMIP/RFC5213, meaning that the MN's registration is fresh - and no past status is available. MAAR1 definitely stores the - temporary BCE previously allocated and unicasts a Router + Upon the MN's attachment to a MAAR, say MAAR1 as shown in Figure 1, + if the MN is authorized for the service, an IPv6 global prefix + belonging to the MAAR1's prefix pool is reserved for it (Pref1) into + a temporary Binding Cache Entry (BCE) allocated locally. The prefix + is sent in a [RFC5213] PBU with the MN's Identifier (MN-ID) to the + CMD, which, since the session is new, stores a permanent BCE + containing as primary fields the MN-ID, the MN's prefix and MAAR1's + address as Proxy-CoA. The CMD replies to MAAR1 with a PBA including + the usual options defined in PMIPv6 [RFC5213], meaning that the MN's + registration is fresh and no past status is available. MAAR1 stores + the temporary BCE previously allocated and unicasts a Router Advertisement (RA) to the MN including the prefix reserved before, that can be used by the MN to configure an IPv6 address (e.g., with stateless auto-configuration, SLAAC). Alternative IPv6 auto- configuration mechanisms can also be used, though this document - describe the SLAAC-based one. The address is routable at the MAAR, + describes the SLAAC-based one. The address is routable at the MAAR, in the sense that it is on the path of packets addressed to the MN. Moreover, the MAAR acts as plain router for those packets, as no - encapsulation nor special handling takes place. Figure 1 illustrates - this scenario. + encapsulation nor special handling takes place. +-----+ +---+ +--+ |MAAR1| |CMD| |CN| +-----+ +---+ +*-+ | | * MN | * +---+ attach. | ***** _|CMD|_ detection | flow1 * / +-+-+ \ | | * / | \ local BCE | * / | \ @@ -325,30 +324,33 @@ finalized | * | | Pref1 * | | +*-+ | | |MN| | | +--+ Operations sequence Packets flow Figure 1: First attachment to the network + Note that the registration process does not change regardless of the + CMD's modes (relay, locator or proxy) described next. + 3.2. The CMD as PBU/PBA relay - When the MN moves from its current access and associates to MAAR2 - (now the S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it - stores a temporary BCE, and it sends a plain PBU to the CMD for - registration. Upon PBU reception and BC lookup, the CMD retrieves an - already existing entry for the MN, binding the MN-ID to its former - location; thus, the CMD forwards the PBU to the MAAR indicated as - Proxy CoA (MAAR1), including a new mobility option to communicate the - S-MAAR's global address to MAAR1, defined as Serving MAAR Option in + When the MN moves from its current access and attaches to MAAR2 (now + the S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it stores a + temporary BCE, and it sends a plain PBU to the CMD for registration. + Upon PBU reception and BC lookup, the CMD retrieves an already + existing entry for the MN, binding the MN-ID to its former location; + thus, the CMD forwards the PBU to the MAAR indicated as Proxy CoA + (MAAR1), including a new mobility option to communicate the S-MAAR's + global address to MAAR1, defined as Serving MAAR Option in Section 4.6. The CMD updates the P-CoA field in the BCE related to the MN with the S-MAAR's address. Upon PBU reception, MAAR1 can install a tunnel on its side towards MAAR2 and the related routes for Pref1. Then MAAR1 replies to the CMD with a PBA (including the option mentioned before) to ensure that the new location has successfully changed, containing the prefix anchored at MAAR1 in the Home Network Prefix option. The CMD, after receiving the PBA, updates the BCE populating an instance of the P-MAAR list. The P-MAAR list is an additional field on the BCE that @@ -391,28 +393,28 @@ | |--- PBA*-->| +*--*+ | | route ---move-->|*MN*| | | update +----+ Operations sequence Data Packets flow PBU/PBA Messages with * contain a new mobility option Figure 2: Scenario after a handover, CMD as relay - For next MN's movements the process is repeated except for the number - of P-MAARs involved, that rises accordingly to the number of prefixes - that the MN wishes to maintain. Indeed, once the CMD receives the - first PBU from the new S-MAAR, it forwards copies of the PBU to all - the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR - prior to handover) and in the P-MAARs list. They reply with a PBA to - the CMD, which aggregates them into a single one to notify the - S-MAAR, that finally can establish the tunnels with the P-MAARs. + For MN's next movements the process is repeated except the number of + P-MAARs involved increases, that rises accordingly to the number of + prefixes that the MN wishes to maintain. Indeed, once the CMD + receives the first PBU from the new S-MAAR, it forwards copies of the + PBU to all the P-MAARs indicated in the BCE as current P-CoA (i.e., + the MAAR prior to handover) and in the P-MAARs list. They reply with + a PBA to the CMD, which aggregates them into a single one to notify + the S-MAAR, that finally can establish the tunnels with the P-MAARs. It should be noted that this design separates the mobility management at the prefix granularity, and it can be tuned in order to erase old mobility sessions when not required, while the MN is reachable through the latest prefix acquired. Moreover, the latency associated to the mobility update is bound to the PBA sent by the furthest P-MAAR, in terms of RTT, that takes the longest time to reach the CMD. The drawback can be mitigated introducing a timeout at the CMD, by which, after its expiration, all the PBAs so far collected are transmitted, and the remaining are sent later upon their arrival. @@ -425,22 +427,22 @@ described in Section 3.2 up to the moment the P-MAAR receives the PBU with the P-MAAR option. At that point a P-MAAR is aware of the new MN's location (because of the S-MAAR's address in the S-MAAR option), and, besides sending a PBA to the CMD, it also sends a PBA to the S-MAAR including the prefix it is anchoring. This latter PBA does not need to include new options, as the prefix is embedded in the HNP option and the P-MAAR's address is taken from the message's source address. The CMD is relieved from forwarding the PBA to the S-MAAR, as the latter receives a copy directly from the P-MAAR with the necessary information to build the tunnels and set the appropriate - routes. In Figure 3 is illustrated the new messages sequence, while - the data forwarding is unaltered. + routes. Figure 3 illustrates the new message sequence, while the + data forwarding is unaltered. +-----+ +---+ +-----+ +--+ +--+ |MAAR1| |CMD| |MAAR2| |CN| |CN| +-----+ +---+ +-----+ +*-+ +*-+ | | | * * | | MN * +---+ * | | attach. ***** _|CMD|_ * | | det. flow1 * / +-+-+ \ *flow2 | |<-- PBU ---| * / | \ * | BCE | * / | ******* @@ -530,22 +532,20 @@ o A previous MAAR stops the BCE timer upon receiving a PBU from the CMD containing a "Serving MAAR" option. In this way only the Serving MAAR is allowed to de-register the mobility session, arguing that the MN left definitely the domain. o Previous MAARs can, upon BCE expiry, send de-registration messages to the CMD, which, instead of acknowledging the message with a 0 lifetime, send back a PBA with a non-zero lifetime, hence re- newing the session, if the MN is still connected to the domain. - The evaluation of these methods is left for future work. - 3.6. The Distributed Logical Interface (DLIF) concept One of the main challenges of a network-based DMM solution is how to allow a mobile node to simultaneously send/receive traffic which is anchored at different MAARs, and how to influence on the preference of the mobile node selecting the source IPv6 address for a new communication, without requiring special support on the mobile node stack. This document defines the Distributed Logical Interface (DLIF), which is a software construct that allows to easily hide the change of anchor from the mobile node. @@ -566,58 +566,57 @@ x x x x prefA::/64 x x prefB::/64 (AdvPrefLft=0) x x (o) | +-----+ prefA::MN1 | MN1 | prefB::MN1 (deprecated) +-----+ - Figure 5: DLIF: exposing multiple routers (one per active anchoring - MAAR) + Figure 5: DLIF: exposing multiple routers (one per P-MAAR) The basic idea of the DLIF concept is the following. Each serving MAAR exposes itself towards a given MN as multiple routers, one per - active anchoring MAAR associated to the MN. Let's consider the - example shown in Figure 5, MN1 initially attaches to MAAR1, - configuring an IPv6 address (prefA::MN1) from a prefix locally - anchored at MAAR1 (prefA::/64). At this stage, MAAR1 plays both the - role of anchoring and serving MAAR, and also it behaves as a plain - IPv6 access router. MAAR1 creates a distributed logical interface to - communicate (point-to-point link) with MN1, exposing itself as a - (logical) router with a specific MAC (e.g., 00:11:22:33:01:01) and - IPv6 addresses (e.g., prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) - using the DLIF mn1mar1. As explained below, these addresses - represent the "logical" identity of MAAR1 towards MN1, and will - "follow" the mobile node while roaming within the domain (note that - the place where all this information is maintained and updated is - out-of-scope of this draft; potential examples are to keep it on the - home subscriber server -- HSS -- or the user's profile). + P-MAAR associated to the MN. Let's consider the example shown in + Figure 5, MN1 initially attaches to MAAR1, configuring an IPv6 + address (prefA::MN1) from a prefix locally anchored at MAAR1 + (prefA::/64). At this stage, MAAR1 plays both the role of anchoring + and serving MAAR, and also it behaves as a plain IPv6 access router. + MAAR1 creates a distributed logical interface to communicate (point- + to-point link) with MN1, exposing itself as a (logical) router with a + specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g., + prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) using the DLIF + mn1mar1. As explained below, these addresses represent the "logical" + identity of MAAR1 towards MN1, and will "follow" the mobile node + while roaming within the domain (note that the place where all this + information is maintained and updated is out-of-scope of this draft; + potential examples are to keep it on the home subscriber server -- + HSS -- or the user's profile). If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in the example of Figure 5), this MAAR will create a new logical interface (mn1mar2) to expose itself towards MN1, providing it with a locally anchored prefix (prefB::/64). In this case, since the MN1 has another active IPv6 address anchored at a MAAR1, MAAR2 also needs to create an additional logical interface configured to exactly resemble the one used by MAAR1 to communicate with MN1. In this - example, there is only one active anchoring MAAR (in addition to - MAAR2, which is the serving one): MAAR1, so only the logical - interface mn1mar1 is created, but the same process would be repeated - in case there were more active anchoring MAARs involved. In order to - maintain the prefix anchored at MAAR1 reachable, a tunnel between - MAAR1 and MAAR2 is established and the routing is modified - accordingly. The PBU/PBA signaling is used to set-up the bi- - directional tunnel between MAAR1 and MAAR2, and it might also be used - to convey to MAAR2 the information about the prefix(es) anchored at - MAAR1 and about the addresses of the associated DLIF (i.e., mn1mar1). + example, there is only one P-MAAR (in addition to MAAR2, which is the + serving one): MAAR1, so only the logical interface mn1mar1 is + created, but the same process would be repeated in case there were + more P-MAARs involved. In order to maintain the prefix anchored at + MAAR1 reachable, a tunnel between MAAR1 and MAAR2 is established and + the routing is modified accordingly. The PBU/PBA signaling is used + to set-up the bi-directional tunnel between MAAR1 and MAAR2, and it + might also be used to convey to MAAR2 the information about the + prefix(es) anchored at MAAR1 and about the addresses of the + associated DLIF (i.e., mn1mar1). +------------------------------------------+ +----------------------+ | MAAR1 | | MAAR2 | |+----------------------------------------+| |+--------------------+| ||+------------------++------------------+|| ||+------------------+|| |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| ||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2|||| |||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 |||| |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| ||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 ||| @@ -631,85 +630,86 @@ | | | +--+--+ +--+--+ +--+--+ | MN3 | | MN2 | | MN1 | +-----+ +-----+ +-----+ Figure 6: Distributed Logical Interface concept Figure 6 shows the logical interface concept in more detail. The figure shows two MAARs and three MNs. MAAR1 is currently serving MN2 and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two - active anchoring MAARs: MAAR1 and MAAR2. Note that a serving MAAR - always plays the role of anchoring MAAR for the attached (served) - MNs. Each MAAR has one single physical wireless interface. + P-MAARs: MAAR1 and MAAR2. Note that a serving MAAR always plays the + role of anchoring MAAR for the attached (served) MNs. Each MAAR has + one single physical wireless interface. As introduced before, each MN always "sees" multiple logical routers - -- one per active anchoring MAAR -- independently of to which serving - MAAR the MN is currently attached. From the point of view of the MN, - these MAARs are portrayed as different routers, although the MN is - physically attached to one single interface. The way this is - achieved is by the serving MAAR configuring different logical - interfaces. If we focus on MN1, it is currently attached to MAAR2 - (i.e., MAAR2 is its serving MAAR) and, therefore, it has configured - an IPv6 address from MAAR2's pool (e.g., prefB::/64). MAAR2 has set- - up a logical interface (mn1mar2) on top of its wireless physical - interface (phy if MAAR2) which is used to serve MN1. This interface - has a logical MAC address (LMAC6), different from the hardware MAC - address (HMAC2) of the physical interface of MAAR2. Over the mn1mar2 - interface, MAAR2 advertises its locally anchored prefix prefB::/64. - Before attaching to MAAR2, MN1 visited MAAR1, configuring also an - address locally anchored at this MAAR, which is still being used by - the MN1 in active communications. MN1 keeps "seeing" an interface - connecting to MAAR1, as if it were directly connected to the two - MAARs. This is achieved by the serving MAAR (MAAR2) configuring an - additional distributed logical interface: mn1mar1, which behaves - exactly as the logical interface configured by the actual MAAR1 when - MN1 was attached to it. This means that both the MAC and IPv6 - addresses configured on this logical interface remain the same - regardless of the physical MAAR which is serving the MN. The - information required by a serving MAAR to properly configure this - logical interfaces can be obtained in different ways: as part of the - information conveyed in the PBA, from an external database (e.g., the - HSS) or by other means. As shown in the figure, each MAAR may have - several logical interfaces associated to each attached MN, having - always at least one (since a serving MAAR is also an anchoring MAAR - for the attached MN). + -- one per P-MAAR -- independently of to which serving MAAR the MN is + currently attached. From the point of view of the MN, these MAARs + are portrayed as different routers, although the MN is physically + attached to one single interface. The way this is achieved is by the + serving MAAR configuring different logical interfaces. If we focus + on MN1, it is currently attached to MAAR2 (i.e., MAAR2 is its serving + MAAR) and, therefore, it has configured an IPv6 address from MAAR2's + pool (e.g., prefB::/64). MAAR2 has set-up a logical interface + (mn1mar2) on top of its wireless physical interface (phy if MAAR2) + which is used to serve MN1. This interface has a logical MAC address + (LMAC6), different from the hardware MAC address (HMAC2) of the + physical interface of MAAR2. Over the mn1mar2 interface, MAAR2 + advertises its locally anchored prefix prefB::/64. Before attaching + to MAAR2, MN1 visited MAAR1, configuring also an address locally + anchored at this MAAR, which is still being used by the MN1 in active + communications. MN1 keeps "seeing" an interface connecting to MAAR1, + as if it were directly connected to the two MAARs. This is achieved + by the serving MAAR (MAAR2) configuring an additional distributed + logical interface: mn1mar1, which behaves exactly as the logical + interface configured by the actual MAAR1 when MN1 was attached to it. + This means that both the MAC and IPv6 addresses configured on this + logical interface remain the same regardless of the physical MAAR + which is serving the MN. The information required by a serving MAAR + to properly configure this logical interfaces can be obtained in + different ways: as part of the information conveyed in the PBA, from + an external database (e.g., the HSS) or by other means. As shown in + the figure, each MAAR may have several logical interfaces associated + to each attached MN, having always at least one (since a serving MAAR + is also an anchoring MAAR for the attached MN). In order to enforce the use of the prefix locally anchored at the serving MAAR, the router advertisements sent over those logical interfaces playing the role of anchoring MAARs (different from the serving one) include a zero preferred prefix lifetime (and a non-zero valid prefix lifetime, so the prefix remains valid, while being deprecated). The goal is to deprecate the prefixes delegated by these MAARs (which will be no longer serving the MN). Note that on- going communications keep on using those addresses, even if they are deprecated, so this only affects to new sessions. The distributed logical interface concept also enables the following use case. Suppose that access to a local IP network is provided by a given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that the resources available at that network cannot be reached from outside the local network (e.g., cannot be accessed by an MN attached to MAAR2). This is similar to the local IP access scenario - considered by 3GPP. The goal is to allow an MN to be able to roam - while still being able to have connectivity to this local IP network. - The solution adopted to support this case makes use of RFC 4191 - [RFC4191] more specific routes when the MN moves to a MAAR different - from the one providing access to the local IP network (MAAR1 in the - example). These routes are advertised through the distributed - logical interface representing the MAAR providing access to the local - network (MAAR1 in this example). In this way, if MN1 moves from - MAAR1 to MAAR2, any active session that MN1 may have with a node of - the local network connected to MAAR1 will survive, being the traffic - forwarded via the tunnel between MAAR1 and MAAR2. Also, any - potential future connection attempt towards the local network will be - supported, even though MN1 is no longer attached to MAAR1. + considered by 3GPP, where a local gateway node is selected for + sessions requiring access to services provided locally (instead of + going through a central gateway). The goal is to allow an MN to be + able to roam while still being able to have connectivity to this + local IP network. The solution adopted to support this case makes + use of RFC 4191 [RFC4191] more specific routes when the MN moves to a + MAAR different from the one providing access to the local IP network + (MAAR1 in the example). These routes are advertised through the + distributed logical interface representing the MAAR providing access + to the local network (MAAR1 in this example). In this way, if MN1 + moves from MAAR1 to MAAR2, any active session that MN1 may have with + a node of the local network connected to MAAR1 will survive, being + the traffic forwarded via the tunnel between MAAR1 and MAAR2. Also, + any potential future connection attempt towards the local network + will be supported, even though MN1 is no longer attached to MAAR1. 4. Message Format This section defines extensions to the Proxy Mobile IPv6 [RFC5213] protocol messages. 4.1. Proxy Binding Update A new flag (D) is included in the Proxy Binding Update to indicate that the Proxy Binding Update is coming from a Mobility Anchor and @@ -727,95 +727,100 @@ . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAAR Flag (D) The D Flag is set to indicate to the receiver of the message that - the Proxy Binding Update is from a MAAR. + the Proxy Binding Update is from a MAAR. When an LMA that does + not support the extensions described in this document receives a + message with the D-Flag set, the PBU in that case MUST NOT be + processed by the LMA and an error MUST be returned. Mobility Options - Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2 of - [RFC6275]. The MAAR MUST ignore and skip any options that it does not understand. 4.2. Proxy Binding Acknowledgment A new flag (D) is included in the Proxy Binding Acknowledgment to - indicate that the sender supports operating as a distributed gateway. - The rest of the Proxy Binding Acknowledgment format remains the same - as defined in [RFC5213]. + indicate that the sender supports operating as a Mobility Anchor and + Access Router. The rest of the Proxy Binding Acknowledgment format + remains the same as defined in [RFC5213]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|P|D| Reser | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAAR (D) The D is set to indicate that the sender of the message supports - operating as a distributed gateway. + operating as a Mobility Anchor and Access Router. When a MAG that + does not support the extensions described in this document + receives a message with the D-Flag set, the PBA in that case MUST + NOT be processed by the MAG and an error MUST be returned. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2 of [RFC6275]. The MAAR MUST ignore and skip any options that it does not understand. 4.3. Anchored Prefix Option A new Anchored Prefix option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgment messages exchanged - between distributed gateways. This option is used for exchanging the - mobile node's prefix anchored at the anchoring MAAR. There can be - multiple Anchored Prefix options present in the message. + between MAARs and CMDs. Therefore, this option can only appear if + the D bit is set in a PBU/PBA. This option is used for exchanging + the mobile node's prefix anchored at the anchoring MAAR. There can + be multiple Anchored Prefix options present in the message. The Anchored Prefix Option has an alignment requirement of 8n+4. Its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Anchored Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type - To be assigned by IANA. + TBD1. Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 18. Reserved This field is unused for now. The value MUST be initialized to 0 @@ -820,29 +825,29 @@ This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Prefix Length 8-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option. Anchored Prefix - A sixteen-byte field containing the mobile node's IPv6 Anchored Prefix. 4.4. Local Prefix Option A new Local Prefix option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgment messages exchanged between - MAARs. This option is used for exchanging a prefix of a local + MAARs. Therefore, this option can only appear if the D bit is set in + a PBU/PBA. This option is used for exchanging a prefix of a local network that is only reachable via the anchoring MAAR. There can be multiple Local Prefix options present in the message. The Local Prefix Option has an alignment requirement of 8n+4. Its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix Length | @@ -851,21 +856,21 @@ + + | | + Local Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type - To be assigned by IANA. + TBD2. Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 18. Reserved This field is unused for now. The value MUST be initialized to 0 @@ -905,21 +910,21 @@ + + | | + Home Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type - To be assigned by IANA. + TBD3. Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 33. Prefix Length 8-bit unsigned integer indicating the prefix length of the IPv6 @@ -950,99 +955,99 @@ + + | | + S-MAAR's address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type - To be assigned by IANA. + TBD4. Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 16. Serving MAAR's address A sixteen-byte field containing the S-MAAR's IPv6 global address. 4.7. DLIF Link-local Address Option A new DLIF Link-local Address option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgment messages exchanged between MAARs. This option is used for exchanging the link-local address of the DLIF to be configured on the serving MAAR - so it resembles the DLIF configured on the anchoring MAAR. + so it resembles the DLIF configured on the P-MAAR. The DLIF Link-local Address option has an alignment requirement of 8n+6. Its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DLIF Link-local Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type - To be assigned by IANA. + TBD5. Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 16. DLIF Link-local Address A sixteen-byte field containing the link-local address of the logical interface. 4.8. DLIF Link-layer Address Option A new DLIF Link-layer Address option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgment messages exchanged between MAARs. This option is used for exchanging the link-layer address of the DLIF to be configured on the serving MAAR - so it resembles the DLIF configured on the anchoring MAAR. + so it resembles the DLIF configured on the P-MAAR. The format of the DLIF Link-layer Address option is shown below. Based on the size of the address, the option MUST be aligned appropriately, as per mobility option alignment requirements specified in [RFC6275]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + DLIF Link-layer Address + . ... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type - To be assigned by IANA. + TBD6. Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. Reserved This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. @@ -1075,20 +1080,23 @@ MAAR. 7. Acknowledgments The authors would like to thank Marco Liebsch, Dirk von Hugo, Alex Petrescu, Daniel Corujo, Akbar Rahman, Danny Moses, Xinpeng Wei and Satoru Matsushima for their comments and discussion on the documents [I-D.bernardos-dmm-distributed-anchoring] and [I-D.bernardos-dmm-pmip] on which the present document is based. + The authors would also like to thank Lyle Bertz for his deep review + of this document and his very valuable comments and suggestions. + 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and @@ -1122,21 +1130,21 @@ bernardos-dmm-pmip-09 (work in progress), September 2017. [I-D.ietf-dmm-deployment-models] Gundavelli, S. and S. Jeon, "DMM Deployment Models and Architectural Considerations", draft-ietf-dmm-deployment- models-04 (work in progress), May 2018. [I-D.ietf-dmm-ondemand-mobility] Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. Jeon, "On Demand Mobility Management", draft-ietf-dmm- - ondemand-mobility-14 (work in progress), March 2018. + ondemand-mobility-15 (work in progress), July 2018. [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, . [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and CJ. Bernardos, "Distributed Mobility Management: Current Practices and Gap Analysis", RFC 7429, DOI 10.17487/RFC7429, January 2015, @@ -1420,28 +1428,23 @@ Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 8803 Email: aoliva@it.uc3m.es URI: http://www.it.uc3m.es/aoliva/ Fabio Giust - NEC Laboratories Europe - NEC Europe Ltd. - Kurfuersten-Anlage 36 - Heidelberg D-69115 - Germany + Athonet S.r.l. - Phone: +49 6221 4342216 - Email: fabio.giust@neclab.eu + Email: fabio.giust.2011@ieee.org Juan Carlos Zuniga SIGFOX 425 rue Jean Rostand Labege 31670 France Email: j.c.zuniga@ieee.org URI: http://www.sigfox.com/