| Internet-Draft | Mobile IPv6-based RAW-enabled mobility | March 2023 |
| Bernardos & Mourad | Expires 13 September 2023 | [Page] |
There are several use cases where reliability and availability are key requirements for wireless heterogeneous networks in which connected devices might be mobile, such as eXtended Reality (XR). This document discusses and specifies control plane solutions to cope with mobility, by proactively preparing the network for the change of point of attachment of a connected mobile node. It also defines Mobile IPv6 extensions implementing these control plane solutions.¶
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 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 13 September 2023.¶
Copyright (c) 2023 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Wireless operates on a shared medium, and transmissions cannot be fully deterministic due to uncontrolled interferences, including self-induced multipath fading. RAW (Reliable and Available Wireless) is an effort to provide Deterministic Networking on across a path that include a wireless interface. RAW provides for high reliability and availability for IP connectivity over a wireless medium. The wireless medium presents significant challenges to achieve deterministic properties such as low packet error rate, bounded consecutive losses, and bounded latency. RAW extends the DetNet Working Group concepts to provide for high reliability and availability for an IP network utilizing scheduled wireless segments and other media, e.g., frequency/time-sharing physical media resources with stochastic traffic: IEEE Std. 802.15.4 timeslotted channel hopping (TSCH), 3GPP 5G ultra-reliable low latency communications (URLLC), IEEE 802.11ax/be, and L-band Digital Aeronautical Communications System (LDACS), etc. Similar to DetNet, RAW technologies aim at staying abstract to the radio layers underneath, addressing the Layer 3 aspects in support of applications requiring high reliability and availability.¶
As introduced in [I-D.ietf-raw-architecture], RAW separates the path computation time scale at which a complex path is recomputed from the path selection time scale at which the forwarding decision is taken for one or a few packets. RAW operates at the path selection time scale. The RAW problem is to decide, amongst the redundant solutions that are proposed by the Patch Computation Element (PCE), which one will be used for each packet to provide a Reliable and Available service while minimizing the waste of constrained resources. To that effect, RAW defines the Path Selection Engine (PSE) that is the counter-part of the PCE to perform rapid local adjustments of the forwarding tables within the diversity that the PCE has selected for the Track. The PSE enables to exploit the richer forwarding capabilities with Packet (hybrid) ARQ, Replication, Elimination and Ordering (PAREO), and scheduled transmissions at a faster time scale.¶
There are several use cases [I-D.ietf-raw-use-cases] where reliability and availability are key requirements for wireless heterogeneous networks. One example is eXtended Reality (XR) applications, such as for example immersive gaming, digital twinning, etc. In these environments, UEs demand strict and predictable behavior, in terms of latency and/or resilience and/or availability and/or throughput, while they move and might change its point of attachment.¶
Figure 1 shows an example of communication involving a RAW domain, a mobile UE running an XR application (which requires connectivity with strict QoS to an XR server). As opposed to static scenarios, where possible “tracks” (and therefore “subtracks”) do not change due to mobility, mobility scenarios pose additional complexity that has not been tackled yet.¶
-----------
| PCE |
-----+-----
|
_____________________+________________________________
| |
| RAW * ( ( o ) ) * |
| network * ^ * |
| * / \ * |
| * / \ * |
| * ------+------ ( ( o ) ) |
| o | RAW | PSE | * ^ |
| ----/- * |node | | * / \ |
| | UE | * ------+------ * / \ |
| ------ * * ------+------ |
| || ( ( o ) ) * * * * * | RAW | PSE | |
| \||/ ^ |node | | |
| \/ / \ ---+--+------ |
| (moving) / \ | |
| ------+------ | |
| | RAW | PSE | | |
| |node | | | |
| ------+------ | |
|________________________________________+___________|
|
----+---
| XR |
|server|
--------
Control plane solutions need to cope with mobility, by proactively preparing the network for the change of point of attachment of the UE, and the impact that this has in terms of new subtracks used for the traffic. This requires inter-PSE coordination for the preparation of the handover.¶
L2-specific extensions can be used to aid the UE determine where to roam to if stringent conditions need to be maintained (requiring RAW support).¶
Current RAW and DETNET solutions are limited to static scenarios, where neither the end nodes/UEs or the internal/local network nodes move.¶
This document proposes new RAW specific UE-PSE and inter-PSE interactions. These interactions enable a UE to move within a RAW domain while maintaining the required QoS of the flow(s) of the UE. These interactions are aimed at (i) enabling the network to react prior to UE mobility, by computing the tracks and subtracks required by the UE at its future location; (ii) supporting temporal bicasting while the L2 handover takes place, to maximize resilience.¶
The following terms used in this document are defined by the IETF:¶
We describe below an example of operation and signaling (Figure TBD) where a UE moves from one Point of Attachment (PoA) within a RAW domain (node1-1) to another PoA (node1-2). Signaling extensions between the UE and the RAW domain, and inter-PSE are shown. The different steps are elaborated below. We assume that the UE is running an XR application demanding stringent QoS, thus requiring from DETNET/RAW solutions. This generates a flow between the UE and an external node, in this example an XR server. A single RAW domain is considered. The mechanisms (from state of the art) to set-up this flow have already taken place and are out of the scope of this document.¶
(optional) The different PoAs of the RAW domain might advertise, using L2 extensions, RAW-specific information, This information might be obtain for example using IEEE 802.11 Neighbor report extensions, or other mechanisms. This information could aid the UE to decide whether to move and where (e.g., taking into account local policies and the advertised capabilities of each available PoA). Exemplary, non-limited, information elements that these advertisements (beacons) might include are, per available PoA in the region:¶
The UE detects or decides (depending on whether only pure radio conditions or also other factors are considered) that a handover is imminent and sends a message to the network, e.g., to its current PoA. This message includes:¶
Note that some of these parameters might have been learned through the optional beacons mentioned in the previous step, or by any other means. Note as well that those beacons can also be used to help the UE filtering or ranking potential target PoAs, based on their support of RAW and the domain they belong to.¶
The current PoA sends a RAW handover initiate (RAW_HO_initiate) message to the target new PoA. It is considered that the UE is the entity making the PoA selection. The focus of this document is not on how the selection is done, but rather on the enablement mechanism for mobility in RAW networks. Hence, the selection process can be considered done using radio measurements, required throughput from the UE side, available throughput from the RAW node side, etc. Hence, the UE also indicates the target PoA in this message. This message contains:¶
Note that the nPoA would be generally obtained from message #2, but if the UE does not provide that information, the network might perform a selection based on the QoS demanded, the current location of the UE and additional information it might have. In that case, the target nPoA would be communicated to the UE in the step #6.¶
The nPoA sends an acknowledgement message (RAW_HO_ACK) to the old PoA, containing:¶
Figure showing the signalling TBD.¶
The control plane extensions introduced in the previous section can be implemented over different protocols. This section specifies extensions to Proxy Mobile IPv6 and Fast Handovers for Proxy Mobile IPv6.¶
The RAW HO Initiate and RAW HO ACK messages can be implemented by extending Handover Initiate and Handover Acknowledgement mobility headers RFC 5568 [RFC5568], RFC 5949 [RFC5949].¶
This section defines extensions to the HI message in RFC 5568 and RFC 5949. The format of the Message Data field in the Mobility Header 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
+-------------------------------+
| Sequence # |
+-+-+-+-+-------+---------------+-------------------------------+
|S|U|P|F|Resv'd | Code | |
+-+-+-+-+-------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
¶
IP Fields:¶
Message Data:¶
Mobility options:¶
This section defines extensions to the HAck message in RFC 5568. The format of the Message Data field in the Mobility Header 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
+-------------------------------+
| Sequence # |
+-+-+-+---------+---------------+-------------------------------+
|U|P|F|Reserved | Code | |
+-+-+-+---------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
¶
IP Fields:¶
Message Data: The usages of Sequence # and Reserved fields are exactly the same as those in RFC 5568.¶
Code: RFC 5568 defines this field and its values, 0 (Handover Accepted or Successful) to 4 and 128 to 130. Values 131 and 132 are defined in RFC 5949. For RAW mobility purposes the following new values are defined:¶
Mobility options:¶
The RAW_ID option has the following format:¶
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 = TBA | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RAW ID Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ RAW ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
Option Type: TBA by IANA.¶
Option Length: 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields.¶
RAW ID Length: 8-bit unsigned integer. Length of the RAW ID field, in octets.¶
RAW ID: variable length field that identifies the RAW domain.¶
The PoA_ID option has the following format:¶
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 = TBA | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PoA ID Length | PoA ID Format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ PoA ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
Option Type: TBA by IANA.¶
Option Length: 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields.¶
PoA ID Length: 8-bit unsigned integer. Length of the PoA ID field, in octets.¶
PoA ID Format: 8-bit unsigned integer. Identifies the format of the PoA ID. Possibles values:¶
PoA ID: variable length field that identifies the PoA.¶
The RAW QoS option has the following format:¶
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 = TBA | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ MinBandwidth +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxLatency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxLatencyVariation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxLoss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxConsecutiveLossTolerance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxMisordering |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
Option Type: TBA by IANA.¶
Option Length: 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. Set to 24.¶
MinBandwidth: 32-bit unsigned integer. MinBandwidth is the minimum bandwidth that has to be guaranteed for the flow. MinBandwidth is specified in octets per second.¶
MaxLatency: 32-bit unsigned integer. MaxLatency is the maximum latency from Ingress to Egress(es) for a single packet of the flow. MaxLatency is specified as an integer number of nanoseconds.¶
MaxLatencyVariation: 32-bit unsigned integer. MaxLatencyVariation is the difference between the minimum and the maximum end-to-end, one-way latency. MaxLatencyVariation is specified as an integer number of nanoseconds.¶
MaxLoss: 32-bit unsigned integer. MaxLoss defines the maximum Packet Loss Rate (PLR) requirement for the flow between the Ingress and Egress(es) and the loss measurement interval.¶
MaxConsecutiveLossTolerance: 32-bit unsigned integer. Some applications have special loss requirements, such as MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance parameter describes the maximum number of consecutive packets whose loss can be tolerated. The maximum consecutive loss tolerance can be measured, for example, based on sequence number.¶
MaxMisordering: 32-bit unsigned integer. MaxMisordering describes the tolerable maximum number of packets that can be received out of order. The value zero for the maximum allowed misordering indicates that in-order delivery is required; misordering cannot be tolerated. The maximum allowed misordering can be measured, for example, based on sequence numbers. When a packet arrives at the egress after a packet with a higher sequence number, the difference between the sequence number values cannot be bigger than "MaxMisordering + 1".¶
TBD.¶
The work of Carlos J. Bernardos in this document has been partially supported by the Horizon Europe PREDICT-6G (Grant 101095890) and UNICO I+D 6G-DATADRIVEN-04 project.¶