Internet DRAFT - draft-bertz-alto-mobilitynets
draft-bertz-alto-mobilitynets
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]