| Internet-Draft | Mobile IPv6-based RAW-enabled mobility | April 2024 |
| Bernardos & Mourad | Expires 9 October 2024 | [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 9 October 2024.¶
Copyright (c) 2024 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 [RFC9450] 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:¶
PAREO. Packet (hybrid) ARQ, Replication, Elimination and Ordering. PAREO is a superset Of DetNet's PREOF that includes radio-specific techniques such as short range broadcast, MUMIMO, constructive interference and overhearing, which can be leveraged separately or combined to increase the reliability.¶
PSE. The Path Selection Engine (PSE) 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 PAREO and scheduled transmissions at a faster time scale over the smaller domain that is the Track, in either a loose or a strict fashion.¶
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:¶
PoA_ID: unique identifier (within the RAW domain) of the PoA. It might have the form of L2/L3 address or any other ID.¶
PSE_ID: unique identifier (within the RAW domain) of the PSE associated with the PoA. In most cases, there will be a PSE instance collocated with every RAW node. It might have the form of L2/L3 address or any other ID.¶
RAW_ID: unique identifier of the RAW domain.¶
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:¶
UE_ID: an identifier of the UE.¶
nPoA_ID: the identifier of the new PoA to which the UE is most likely to attach to. It might have the form of L2/L3 address or any other ID.¶
nRAW_ID: unique identifier of the RAW domain the nPoA belongs to. It is only in the scope of this document the case of mobility within the same RAW domain.¶
QoS: a description of the QoS parameters demanded by the flow. It might be a set of one of several parameters, such as: latency, resiliency, throughput, etc.¶
Bicasting requested (Y/N): whether the UE requests bicasting of traffic during the handover for extra resilience. If not requested, the network can still perform it as deemed necessary to grant the required QoS.¶
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:¶
UE_ID: an identifier of the UE that is about to perform a handover.¶
oPoA_ID: the identifier of the current (old) PoA to which the UE is currently attached to. It might have the form of L2/L3 address or any other ID.¶
oRAW_ID: unique identifier of the RAW domain the oPoA belongs to. It is only in the scope of this document the case of mobility within the same RAW domain.¶
QoS: a description of the QoS parameters demanded by the flow. It might be a set of one of several parameters, such as: latency, resiliency, throughput, etc. For the purpose of this document, these parameters consider basis QoS metrics and are described at high level and immediate single values. Addressing these in detail requires further work as their extensions and expansions result in further enhancements to the mobility process that are out of the scope of this document due to the complexity involved, and that provides solutions to other problems.¶
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.¶
With the information provided in the previous step, the nPoA computes the tracks and subtracks required to support the QoS of the flow, by using RAW mechanisms. Note that if it is not possible to support the required QoS, the nPoA can propose a lower QoS in step #5.¶
The nPoA sends an acknowledgement message (RAW_HO_ACK) to the old PoA, containing:¶
UE_ID: an identifier of the UE that is about to perform a handover.¶
QoS: a description of the QoS parameters that can be granted to the flow. It might be a set of one of several parameters, such as: latency, resiliency, throughput, etc. Note that it might be equal or lower than the QoS requested in step #3. For the purpose of this document, these parameters consider basis QoS metrics and are described at high level and immediate single values. Addressing these in detail requires further work as their extensions and expansions result in further enhancements to the mobility process that are out of the scope of this document due to the complexity involved, and that provides solutions to other problems.¶
The old PoA sends a command message to the UE, indicating that it can perform now the L2 handover, and providing the granted QoS and the target PoA.¶
In parallel to message #6, and as an optional feature decided by the network, a bicasting procedure can be initiated so downlink (DL) traffic received by the oPoA are duplicated and also sent to the nPoA, to minimize packet losses during the actual L2 handover. This bicasting procedure can be implemented by using the Packet Replication, Elimination, and Ordering Functions (PREOF) defined by IETF DETNET. The UE performs the L2 handover. Upon UE attachment detection by the nPoA, RAW mechanisms are used to activate the subtracks required for the UE’s flow at its new location.¶
RAW signaling is used to set-up the new forwarding status /subtracks).¶
Once all the required RAW forwarding state is in place, bicasting is stopped (in case this feature was initiated).¶
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:¶
Sequence #: Same as defined in RFC 5568.¶
'S' flag: Defined in RFC 5568, and MUST be set to zero in this specification.¶
'U' flag: Buffer flag. Same as defined in RFC 5568.¶
'P' flag: Proxy flag. Used to distinguish the message from that defined in RFC 5568, and MUST be set.¶
'F' flag: Forwarding flag. Used to request to setup bicasting for this flow.¶
Reserved: Same as defined in RFC 5568.¶
Code: RFC 5568 defines this field and its values, 0 and 1. This MUST be set to zero.¶
Mobility options:¶
This field contains one or more mobility options, whose encoding and formats are defined in RFC 6275.¶
In order to uniquely identify the target UE, the UE identifier MUST be contained in the Mobile Node Identifier option. This option is used to carry the UE_ID parameter described in this document.¶
The following new options can be used in this message: RAW_ID, PoA_ID, RAW QoS.¶
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:¶
Source Address: Copied from the destination address of the Handover Initiate message to which this message is a response.¶
Destination Address: Copied from the source address of the Handover Initiate message to which this message is a response.¶
Message Data: The usages of Sequence # and Reserved fields are exactly the same as those in RFC 5568.¶
U' flag: Buffer flag. Same as defined in RFC 5568.¶
'P' flag: Proxy flag. Used to distinguish the message from that defined in defined RFC 5568, and MUST be set.¶
'F' flag: Forwarding flag. Used to request to setup bicasting for this flow.¶
Reserved: Same as defined 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:¶
133: not possible to grant requested QoS, lower QoS proposed.¶
Mobility options:¶
This field contains one or more mobility options, whose encoding and formats are defined in RFC 6275. The mobility option that uniquely identifies the target mobile node MUST be copied from the corresponding RAW HO Initiate message.¶
The following new options can be used in this message: RAW_ID, PoA_ID, RAW QoS.¶
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:¶
0: Reserved.¶
1: IP address (v4 or v6, determined by PoA ID Length).¶
2: L2 address (48 or 64 bit, determined by PoA ID Length).¶
3: URI.¶
4-255: reserved for future use.¶
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), Hexa-X-II (101095759) and UNICO I+D 6G-DATADRIVEN-04 project (TSI-063000-2021-132).¶