ALTO WG L. Bertz Internet-Draft Sprint Intended status: Informational October 19, 2015 Expires: April 16, 2016 Mobility Network Models in ALTO draft-bertz-alto-mobilitynets-00 Abstract Application Layer Traffic Optimization can become complex in networks supporting IP mobility. This document discusses a general model approach for such networks and a method to minimize ALTO client queries. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 http://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 April 16, 2016. Copyright Notice Copyright (c) 2015 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Bertz Expires April 16, 2016 [Page 1] Internet-Draft ALTO-Mobility-Models October 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. General Approach . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Attachment Point and Address Pool Representation . . . . 4 2.2. Dynamic and Static Relationship Representation . . . . . 5 2.3. Other Considerations in Mobility . . . . . . . . . . . . 6 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. CDN Request Router . . . . . . . . . . . . . . . . . . . 7 3.2. Dynamic Mobility Management (DMM) Forwarding Policy Configuration (FPC) . . . . . . . . . . . . . . . . . . . 7 4. Possible ALTO Extensions . . . . . . . . . . . . . . . . . . 7 5. Informative References . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Networks have devices that vary in terms of mobility. IP mobility can provide both session continuity (maintaining the IP endpoint while the device moves from a point of network attachment to others) and reachability (maintaining the IP address for an extended period of time). [ONDEMANDMOBILITY] provides a mechanism for devices to select the type of mobility session desired. It breaks down IP mobility into three different types by address: o Fixed IP Address - Provides IP session continuity and IP address reachability o Sustained IP Address - Provides only IP address continuity o Nomadic IP Address - Provides neither IP session continuity nor IP address reachability There are multiple points of attachment where each is typically noted by a single endpoint address, e.g. a E-UTRAN Global Cell Identifier (EGCID). The mobility client communicates through the point of attachment to a mobility gateway such as a Mobile Access Gateway (MAG) for Proxy Mobile IP (PMIP) or a Serving Gateway (SGW) in 3GPP networks. These devices provide the session continuity. They forward traffic through a tunnel, e.g. GTP or GRE, to an anchor function, e.g. Local Mobility Anchor (LMA) for PMIP or PDN-Gateway (PGW) for 3GPP mobility networks. Such anchor functions provide address reachability. Figure 1 shows an example of PMIP and 3GPP mobility elements in a network. Bertz Expires April 16, 2016 [Page 2] Internet-Draft ALTO-Mobility-Models October 2015 Device--+ | +==========+ +==========+ +==============+ +==========+ | | +======+ | | +======+ | | +==========+ | | Point of |--|-|-| |-|--|-| LMA1 |-|-+-| | Service1 | | | Attach A | | | | MAG1 | | | +======+ | | | +==========+ | +==========+ | | | | | | | | | | | | +======+ | | | | | | | | | | | | | _----_ | | | +=====+ | | | | | _( )_ | +==========+ +-|-| MME | | | | +-|-( Internet )-|- | Point of | | | +=====+ | | | | | (_ _) | | Attach B |-+ | | | | | | | '----' | +==========+ | | +======+ | | +=====+ | | | | (eNodeB) +-|-| SGW1 |-|--|-| PGW |--|-+ | | | +======+ | | +=====+ | | | +==========+ | | | | | +-|-| Service2 | | +==========+ +==========+ | +==========+ | Tier 1 Tier 2 +==============+ Tier 3 Figure 1: PMIP / 3GPP Mobile Network Example Representation of such networks in ALTO is further complicated by the fact that Anchor Functions assign individual IP address from pools of addresses in the home network. Such pools appear as routes and associated with PIDs that are typically associated with a network map. Attachment points, being a single value, are typically represented as ALTO Endpoints but mobile points of attachment use type formats not currently supported in ALTO. In many networks the assets assigned may be dedicated. For example, the assets in Tier 1 of Figure 1 may have assets in Tier 2 statically assigned to them. Such 'direct' relationships would be present in the ALTO Endpoint Property Service (EPS). For example, the endpoint of MAG1 would have a property of "lma" : "lma1" (or IP address of LMA1) The points of attachment could have similar static assignments in the EPS. Such representation is difficult and even quite complicated when the property value is a large array. Other relationships may be more dynamic and decisions are best made by looking at metrics in a Costmap or Endpoint Costmap. Bertz Expires April 16, 2016 [Page 3] Internet-Draft ALTO-Mobility-Models October 2015 In summary, networks supporting various levels of IP mobility have multiple representation challenges in ALTO: o The Points of Attachment are typically an endpoint type not currently supported in ALTO. o Anchor Functions allocate addresses from pools that are typically represented as PIDs in a network map while the anchor function itself is an endpoint. o Relationships can be dynamic or static for the same type of query. This results in using EPS to determine static relationships and EPCS/CS to acquire dynamic relationships (possibly repeatedly) just to complete a single ALTO based decision. 2. General Approach 2.1. Attachment Point and Address Pool Representation Due their importance, network attachment point representations are represented as PIDs in network maps with no routes. PID properties [PIDPROPS] could be used to associate the non-ALTO supported endpoint type as a property of the Point of Attachment. If all of the endpoints associated with an Attachment Point are contained by another PID it is possible to represent all endpoints in a PID. However, any change could result in a PID conflict which is not allowed. This approach was not used here. Address Pools are represented as PIDs. Two pools may belong to the same PID if they are assigned to the same element or aggregated into a PID that contains the pools. Figure 2 shows the modified mapping. The eNodeB now appears as an endpoint (element) associated to Point of Attach B. Bertz Expires April 16, 2016 [Page 4] Internet-Draft ALTO-Mobility-Models October 2015 +==========+ +============+ +==========+ +==============+ | Point of | | +======+ | | +======+ | | +==========+ | | Attach A |---|-| |---|---|-| LMA1 |-|-+-| | Server1 | | +==========+ | | MAG1 | | | +======+ | | | +==========+ | +-|-| | | | | | | | | | +======+ | | | | | | | | | | | | | _----_ | | | +=====+ | | | | | _( )_ | +==========+ +-|-| MME | | | | +-|-( Internet )-|-- | Point of | | | +=====+ | | | | | (_ _) | | Attach B |-+ | | | | | | | '----' | +==========+ | | +======+ | | +=====+ | | | | +-|-| SGW1 |---|---|-| PGW |--|-+ | | | | +======+ | | +=====+ | | | +==========+ | | | | | | +-|-| Server2 | | | | +========+ | +==========+ | +==========+ | +-|-| eNodeB | | Tier 2 +==============+ | +========+ | Tier 3 +============+ Tier 1 Figure 2: Mobile Network Mapping Address Pools from the PGW and LMA1 appear in PIDs and may appear in the same PID if both the PGW and LMA1 are part of the same PID. 2.2. Dynamic and Static Relationship Representation In order to reduce the number of ALTO services required for Client queries the Static Relationships are mapped to Dynamic relationship based metrics. The following logic is applied. 1. If a direct relationship exists between a PID and an endpoint the ALTO server should generate a PID to represent the endpoint. The PID must only contain the endpoint as its single entry. There server will generate a costmap value between the newly generated and existing PIDs. 2. If the relationship is direct and between two endpoints a EPCS value should generated. The values used should be the maximum/minimum for a metric in order to achieve the desired result of always returning the endpoint in the direct relationship (or the PID it represents). Bertz Expires April 16, 2016 [Page 5] Internet-Draft ALTO-Mobility-Models October 2015 2.3. Other Considerations in Mobility Quite often more than one characteristic is used in selecting mobility gateways and anchor functions. Figure 3 below shows an example where the address types defined in [ONDEMANDMOBILITY] will dictate the LMA chosen. +====================+ +==========+ | +======+ +======+ | | Point of |---|-| |--| LMA1 | | Device-| Attach A | | | MAG1 | +======+ | +==========+ | | | | | | | | +==========+ | | | | | Point of |---|-| | | | Attach B | | | | | +==========+ | | |-----------|--+ | | | | | +==========+ | | | | | | Point of |---|-| | | | | Attach C | | +======+ | | +======+ +==========+ +====================+ +-| | | LMA3 | +====================+ +-| | +==========+ | +======+ | | +======+ | Point of |---|-| |-----------|--+ | Attach D | | | MAG2 | | +==========+ | | | | | | | | +==========+ | | | +======+ | | Point of |---|-| |--| LMA2 | | | Attach E | | +======+ +======+ | +==========+ +====================+ Figure 3: Multiple LMA Options If a Fixed IP Address is required then LMA3 is the preferred choice. If the device requires a Sustained Address and is traveling at slow speed, which is often referred to as a device's speed state, then LMA1 is sufficient. If the speed state is high, e.g. the device may be in a moving vehicle, then LMA3 may be a better selection. Two options exist when considering how an ALTO client could select a proper LMA: 1. The LMAs could be pre-filtered using the EPS. Bertz Expires April 16, 2016 [Page 6] Internet-Draft ALTO-Mobility-Models October 2015 2. The ALTO server can represent criteria such as speed state as another metric and use multi-metric search methods. 3. Examples 3.1. CDN Request Router Content Delivery Network (CDN) Request Routers (RRs) take an external IP address provided by an upstream CDN over a CDNI interface. Using ALTO a RR can determine the correct CDN Node. Following example Figure 2 a RR can determine if Server1 or Server2 is most appropriate for devices served by the LGW or LMA. For devices that are directly attached to the network, e.g. a fixed (wired) device, the RR can query for the best Server for the Point of Attachment. 3.2. Dynamic Mobility Management (DMM) Forwarding Policy Configuration (FPC) DMM FPC [DMMFPC] provides the ability for a control plane element (FPC Client) to use FPC dataplane nodes for forwarding. Communication between the Client and nodes is accomplished by an FPC Agent which may not be co-located with the dataplane node and may, in fact, represent multiple dataplane nodes. The Client must select the best Dataplane Node and then its corresponding agent. It can accomplish this by: 1. Querying EPS for all endpoints with FPC Dataplane nodes and, during the query, their FPC Agent information. There are number of ways to accomplish this. Ideally, EPS can be extended to select any nodes, e.g. ipv4:* or ipv6:* in the query, along with the corresponding properties. 2. Query ECPS for the best Dataplane node that serves the mobility client. 3. Once selected, contact the FPC agent. 4. Possible ALTO Extensions This document does not propose significant ALTO extensions as much as how data can be mapped or computed in various ALTO services in order to minimize the queries a client must make. Bertz Expires April 16, 2016 [Page 7] Internet-Draft ALTO-Mobility-Models October 2015 The only proposed extension is to permit a wildcard or empty value in the ALTO EPS query to permit an open ended query. Such a service would deviate from the current EPS definition to only return endpoints that contain the value as opposed to return all endpoints including those with empty structures. 5. Informative References [DMMFPC] Liebsch, M., Matsushima, S., Gundavelli, S. and Moses, D. "Protocol for Forwarding Policy Configuration (FPC) in DMM", 2015. [ONDEMANDMOBILITY] Yegin, A., Kweon, K., Lee, J., Park, J., and Moses, D. "On Demand Mobility Management", 2015. [PIDPROPS] Roome, W., "Extensible Property Maps for the ALTO Protocol", 2015. Author's Address Lyle Bertz Sprint 6220 Sprint Parkway Overland Park KS 66251 USA Email: lyleb551144@gmail.com Bertz Expires April 16, 2016 [Page 8]