Subject: [5gangip] Minimising the use of tunnels with flow-based addresses

From: Bill Gage <[email-masked]>
Date: Tue, 5 Jan 2016 16:48:43 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 16, 2015 5:34 AM
> Subject: Re: [5gangip] tunnels
>
> So, in my mind any 5G mobile network would be built on top of IPv6, but
> it might contain new transport/tunneling protocols to solve specific
> requirements ... I would like to avoid all
> traffic being tunneled if possible, and that we only tunnel the traffic
> that needs to be tunneled.

Minimising the use of tunnels is a good design goal. The following describes a possible IPv6-based solution ...

------
In today's mobile wireless environment, an IP address is normally assigned to (an interface on) a Wireless Device when the Device registers with the network and the Device retains this address for as long as it is active in the wireless network. In contrast to operations in the Internet-at-large, the assigned address in a mobile environment typically identifies a Mobility Anchor point rather than the point where the Device is (currently) attached to the network.

The Mobility Anchors associated with ingress Border Gateways in large wireless networks must maintain a context for every (active) Device in order to forward packets properly. At the ingress points, maintaining context increases the amount of storage required and increases processing requirements to encapsulate each incoming packet into an appropriate tunnel packet for forwarding. Whenever a Wireless Device changes its point of attachment, control plane signalling packets using conventional mobility management protocols (e.g., PMIP) are exchanged between the serving Radio Edge Node(s) and the Mobility Anchor point for that Device. The overheads associated with this procedure become more acute in heterogeneous networks with a large number of small cells and a dense population of mobile Devices. Proposals for flow-level mobility using PMIP will further exacerbate this problem.

------
One alternative to packet forwarding in a mobile environment is to assign IPv6 network addresses to individual packet flows rather than to devices and their interfaces. Because most packet flows are short-lived, a packet flow can often be concluded within the coverage area of a single Radio Edge Node. For downlink packet flows, flow-based address assignment enables forwarding of packets directly to the Radio Edge Node associated with that flow address without the use of tunnels. This eliminates the transmission overhead associated with transport tunnels, the control overhead associated with the management of tunnels, and the maintenance of context at the network edges.

For web browsing activities, statistics from <httparchive.org> indicate that the average size of various types of objects is quite small, leading to short-lived packet flows when combined with HTTP pipelining:

Object      Object    Average number
 type     size (kB)     of packets
------------------------------------
GIF           8              6
JPEG         31             22
PNG          20             14
HTML          6              5
JS           16             11
CSS           9              7
Flash       106             73

Because the objects that constitute a web page may be distributed across servers in multiple domains, web browsing activities also make extensive use of DNS; each of these DNS transactions may also be performed using flow-based addresses. There are many other instances of short-lived flows in a wireless environment such as background application traffic from smartphones and machine-type communications from embedded (M2M) devices.

------
An IPv6 flow-based address may be constructed by replacing (some portion of) the low-order 64 bits of an address (the "interface" identifier) with a flow handle. Upon attachment to a Radio Edge Node, a Device would be assigned a block of IP addresses. If the addresses are associated with other semantics (e.g. QoS, SFC) then a Device may be assigned multiple IP address blocks. The high-order bits of an address block may be used to identify the Radio Edge Node(s) currently serving the Device.

When an application on a Device initiates a new uplink flow, the Device selects an available address from the (appropriate) block of addresses and uses it as the source address in all packets of the uplink flow. When the flow is terminated, the address may be reused with a subsequent flow.

There are, however, some applications (e.g. device management) where an IP address is expected to be assigned to a Wireless Device for a long period of time. In these instances, a Device may be configured with a long-lived IPv6 address for use by that application while short-lived traffic flows are dynamically assigned flow-based addresses. Mobility management for the long-lived address may make use of traditional, centralized  procedures (e.g., PMIP) while mobility management for the short-lived addresses makes use of the techniques described below.

------
A number of techniques may be employed to avoid the handover of a flow (and, hence, an address) from one Radio Edge Node to another:

1) quiescent mode mobility. In many instances, a mobile Device may change its point of attachment during a quiescent period when it has no active flows, eliminating the need for any actions related to packet flow or IP address maintenance. A quiescent period may occur naturally (e.g., while the user is not actively using the Device or is viewing previously downloaded material) or a quiescent period may be produced by using intelligent traffic management procedures in the Device, as described below.

2) anticipating packet flow termination. In many instances, a Wireless Device can estimate the number of packets that will be required in a flow in order to effect an exchange of information. For example, in HTTP, the size of the data object is specified in a transaction header received in one of the initial packets of the flow. The Device could defer or postpone a change in connectivity at the radio link layer until the information exchange is completed and the associated packet flow is terminated. Once completed, the Device could maintain its quiescent flow state until radio link connections have been established at the new point(s) of attachment, after which the Device would be free to initiate new packet flows as required.

3) segmenting large data transfers. There will be occasions when a Wireless Device may be faced with the transfer of a large data object. In these instances, the Wireless Device can mitigate the effects of being mobile during the data transfer by transferring the data object as a series of smaller chunks rather than as a single monolithic entity. Each chunk can be transferred separately such that the transfer of each chunk is represented as a different packet flow and downloading of a chunk can be completed as a short-lived flow within the coverage of a single Radio Edge Node. If the Wireless Device is mobile, this would allow different chunks to be transferred through different Radio Edge Nodes while still minimizing handover overhead. For example, when using HTTP, a Wireless Device can issue a GET request that is qualified by a RANGE to identify the chunk as a sequence of bytes within the data object. This is similar to the DASH technique used for downloading large video files.

------
Flow-based addressing is also synergistic with proposals for UDP-based transport protocols such as QUIC. In addition, the frequent change of IP source address also enhances the security and privacy of users by complicating the task of eavesdroppers who are attempting to track and correlate the activity of a host through its assigned network address. Flow-based addressing will also minimise the need for specialized routing and tunnelling protocols (e.g. PMIP, GTP) and for mobility-aware packet forwarding engines (e.g. SGW, PGW, SGSN) and will push mobility-based operations to the radio edge of the network (cf. DMM).

---

From: <[email-masked]>
Date: Thu, 7 Jan 2016 17:28:47 +0100

Hi Bill,
Thanks for posting your detailed proposal!
Sounds interesting .... but to clarify: Couldn't it become an issue for some devices that they need additional capabilities? Such as to ensure consistent mapping of states, e.g. addresses to flows etc.? 
Or did I misunderstand sth.?
Thanks!
Best Regards
Dirk 

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Bill Gage
Sent: Dienstag, 5. Januar 2016 17:49
To: [email-masked]
Subject: [5gangip] Minimising the use of tunnels with flow-based addresses

> So, in my mind any 5G mobile network would be built on top of IPv6, 
> but it might contain new transport/tunneling protocols to solve 
> specific requirements ... I would like to avoid all traffic being 
> tunneled if possible, and that we only tunnel the traffic that needs 
> to be tunneled.

------

------

------

------

------

_______________________________________________
5gangip mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/5gangip

---

From: Bill Gage <[email-masked]>
Date: Thu, 7 Jan 2016 19:17:50 +0000

Hello Dirk -
	The device certainly needs more capabilities than a basic IPv6 host, but the complexity is no worse (and possibly less) than proposals for multi-homing, or for multi-link operation, or for flow-level mobility, or for on-demand mobility.

Deployment is also straight forward because the changes are all in the device (and how it is configured) -- remote corresponding nodes and servers are not affected and nothing special is required in the packet forwarding infrastructure.

Cheers ...

> Sent: Thursday, January 7, 2016 11:29 AM
> Subject: RE: Minimising the use of tunnels with flow-based addresses
> 
> Hi Bill,
> Sounds interesting .... but to clarify: Couldn't it become an issue for
> some devices that they need additional capabilities? Such as to ensure
> consistent mapping of states, e.g. addresses to flows etc.?
> Minimising the use of tunnels is a good design goal. The following
> describes a possible IPv6-based solution ...
> 
> ------
> In today's mobile wireless environment, an IP address is normally assigned
> to (an interface on) a Wireless Device when the Device registers with the
> network and the Device retains this address for as long as it is active in
> the wireless network. In contrast to operations in the Internet-at-large,
> the assigned address in a mobile environment typically identifies a
> Mobility Anchor point rather than the point where the Device is
> (currently) attached to the network.
> 
> The Mobility Anchors associated with ingress Border Gateways in large
> wireless networks must maintain a context for every (active) Device in
> order to forward packets properly. At the ingress points, maintaining
> context increases the amount of storage required and increases processing
> requirements to encapsulate each incoming packet into an appropriate
> tunnel packet for forwarding. Whenever a Wireless Device changes its point
> of attachment, control plane signalling packets using conventional
> mobility management protocols (e.g., PMIP) are exchanged between the
> serving Radio Edge Node(s) and the Mobility Anchor point for that Device.
> The overheads associated with this procedure become more acute in
> heterogeneous networks with a large number of small cells and a dense
> population of mobile Devices. Proposals for flow-level mobility using PMIP
> will further exacerbate this problem.
> 
> ------
> One alternative to packet forwarding in a mobile environment is to assign
> IPv6 network addresses to individual packet flows rather than to devices
> and their interfaces. Because most packet flows are short-lived, a packet
> flow can often be concluded within the coverage area of a single Radio
> Edge Node. For downlink packet flows, flow-based address assignment
> enables forwarding of packets directly to the Radio Edge Node associated
> with that flow address without the use of tunnels. This eliminates the
> transmission overhead associated with transport tunnels, the control
> overhead associated with the management of tunnels, and the maintenance of
> context at the network edges.
> 
> For web browsing activities, statistics from <httparchive.org> indicate
> that the average size of various types of objects is quite small, leading
> to short-lived packet flows when combined with HTTP pipelining:
> 
> Because the objects that constitute a web page may be distributed across
> servers in multiple domains, web browsing activities also make extensive
> use of DNS; each of these DNS transactions may also be performed using
> flow-based addresses. There are many other instances of short-lived flows
> in a wireless environment such as background application traffic from
> smartphones and machine-type communications from embedded (M2M) devices.
> 
> ------
> An IPv6 flow-based address may be constructed by replacing (some portion
> of) the low-order 64 bits of an address (the "interface" identifier) with
> a flow handle. Upon attachment to a Radio Edge Node, a Device would be
> assigned a block of IP addresses. If the addresses are associated with
> other semantics (e.g. QoS, SFC) then a Device may be assigned multiple IP
> address blocks. The high-order bits of an address block may be used to
> identify the Radio Edge Node(s) currently serving the Device.
> 
> When an application on a Device initiates a new uplink flow, the Device
> selects an available address from the (appropriate) block of addresses and
> uses it as the source address in all packets of the uplink flow. When the
> flow is terminated, the address may be reused with a subsequent flow.
> 
> There are, however, some applications (e.g. device management) where an IP
> address is expected to be assigned to a Wireless Device for a long period
> of time. In these instances, a Device may be configured with a long-lived
> IPv6 address for use by that application while short-lived traffic flows
> are dynamically assigned flow-based addresses. Mobility management for the
> long-lived address may make use of traditional, centralized  procedures
> (e.g., PMIP) while mobility management for the short-lived addresses makes
> use of the techniques described below.
> 
> ------
> A number of techniques may be employed to avoid the handover of a flow
> (and, hence, an address) from one Radio Edge Node to another:
> 
> 1) quiescent mode mobility. In many instances, a mobile Device may change
> its point of attachment during a quiescent period when it has no active
> flows, eliminating the need for any actions related to packet flow or IP
> address maintenance. A quiescent period may occur naturally (e.g., while
> the user is not actively using the Device or is viewing previously
> downloaded material) or a quiescent period may be produced by using
> intelligent traffic management procedures in the Device, as described
> below.
> 
> 2) anticipating packet flow termination. In many instances, a Wireless
> Device can estimate the number of packets that will be required in a flow
> in order to effect an exchange of information. For example, in HTTP, the
> size of the data object is specified in a transaction header received in
> one of the initial packets of the flow. The Device could defer or postpone
> a change in connectivity at the radio link layer until the information
> exchange is completed and the associated packet flow is terminated. Once
> completed, the Device could maintain its quiescent flow state until radio
> link connections have been established at the new point(s) of attachment,
> after which the Device would be free to initiate new packet flows as
> required.
> 
> 3) segmenting large data transfers. There will be occasions when a
> Wireless Device may be faced with the transfer of a large data object. In
> these instances, the Wireless Device can mitigate the effects of being
> mobile during the data transfer by transferring the data object as a
> series of smaller chunks rather than as a single monolithic entity. Each
> chunk can be transferred separately such that the transfer of each chunk
> is represented as a different packet flow and downloading of a chunk can
> be completed as a short-lived flow within the coverage of a single Radio
> Edge Node. If the Wireless Device is mobile, this would allow different
> chunks to be transferred through different Radio Edge Nodes while still
> minimizing handover overhead. For example, when using HTTP, a Wireless
> Device can issue a GET request that is qualified by a RANGE to identify
> the chunk as a sequence of bytes within the data object. This is similar
> to the DASH technique used for downloading large video files.
> 
> ------
> Flow-based addressing is also synergistic with proposals for UDP-based
> transport protocols such as QUIC. In addition, the frequent change of IP
> source address also enhances the security and privacy of users by
> complicating the task of eavesdroppers who are attempting to track and
> correlate the activity of a host through its assigned network address.
> Flow-based addressing will also minimise the need for specialized routing
> and tunnelling protocols (e.g. PMIP, GTP) and for mobility-aware packet
> forwarding engines (e.g. SGW, PGW, SGSN) and will push mobility-based
> operations to the radio edge of the network (cf. DMM).
>