Internet DRAFT - draft-bernardos-raw-mobility
draft-bernardos-raw-mobility
RAW WG CJ. Bernardos
Internet-Draft UC3M
Intended status: Standards Track A. Mourad
Expires: 13 September 2023 InterDigital
12 March 2023
MIPv6 RAW mobility
draft-bernardos-raw-mobility-00
Abstract
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.
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 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 Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bernardos & Mourad Expires 13 September 2023 [Page 1]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
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.
Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. RAW control plane extensions for UE mobility . . . . . . . . 5
3.1. UE-controlled RAW-enabled mobility . . . . . . . . . . . 5
3.2. Network-controlled RAW-enabled mobility . . . . . . . . . 8
3.3. Proxy Mobile IPv6 extensions . . . . . . . . . . . . . . 8
3.3.1. RAW HO Initiate . . . . . . . . . . . . . . . . . . . 9
3.3.2. RAW HO ACK . . . . . . . . . . . . . . . . . . . . . 10
3.3.3. New mobility options . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
7. Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction and Problem Statement
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.
Bernardos & Mourad Expires 13 September 2023 [Page 2]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
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.
Bernardos & Mourad Expires 13 September 2023 [Page 3]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
-----------
| PCE |
-----+-----
|
_____________________+________________________________
| |
| RAW * ( ( o ) ) * |
| network * ^ * |
| * / \ * |
| * / \ * |
| * ------+------ ( ( o ) ) |
| o | RAW | PSE | * ^ |
| ----/- * |node | | * / \ |
| | UE | * ------+------ * / \ |
| ------ * * ------+------ |
| || ( ( o ) ) * * * * * | RAW | PSE | |
| \||/ ^ |node | | |
| \/ / \ ---+--+------ |
| (moving) / \ | |
| ------+------ | |
| | RAW | PSE | | |
| |node | | | |
| ------+------ | |
|________________________________________+___________|
|
----+---
| XR |
|server|
--------
Figure 1: Exemplary scenario depicting RAW mobility
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.
Bernardos & Mourad Expires 13 September 2023 [Page 4]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
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.
2. Terminology
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.
3. RAW control plane extensions for UE mobility
3.1. UE-controlled RAW-enabled mobility
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.
1. (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
Bernardos & Mourad Expires 13 September 2023 [Page 5]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
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.
2. 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.
3. 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
Bernardos & Mourad Expires 13 September 2023 [Page 6]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
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.
4. 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.
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.
Bernardos & Mourad Expires 13 September 2023 [Page 7]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
* 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.
6. 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.
7. 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.
8. RAW signaling is used to set-up the new forwarding status
/subtracks).
9. Once all the required RAW forwarding state is in place, bicasting
is stopped (in case this feature was initiated).
Figure showing the signalling TBD.
3.2. Network-controlled RAW-enabled mobility
TBD.
3.3. Proxy Mobile IPv6 extensions
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.
Bernardos & Mourad Expires 13 September 2023 [Page 8]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
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].
3.3.1. RAW HO Initiate
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:
Source Address: the IP address of the oPoA.
Destination Address: the IP address of the nPoA.
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.
Bernardos & Mourad Expires 13 September 2023 [Page 9]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
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.
3.3.2. RAW HO ACK
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.
Bernardos & Mourad Expires 13 September 2023 [Page 10]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
'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.
3.3.3. New mobility options
3.3.3.1. RAW_ID mobility option
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.
Bernardos & Mourad Expires 13 September 2023 [Page 11]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
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.
3.3.3.2. PoA_ID mobility option
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.
Bernardos & Mourad Expires 13 September 2023 [Page 12]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
PoA ID: variable length field that identifies the PoA.
3.3.3.3. RAW QoS mobility option
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.
Bernardos & Mourad Expires 13 September 2023 [Page 13]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
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".
4. IANA Considerations
TBD.
5. Security Considerations
TBD.
6. Acknowledgments
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.
7. Informative References
[I-D.ietf-raw-architecture]
Thubert, P., "Reliable and Available Wireless
Architecture", Work in Progress, Internet-Draft, draft-
ietf-raw-architecture-11, 7 December 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-
architecture-11>.
[I-D.ietf-raw-use-cases]
Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F.
Theoleyre, "RAW Use-Cases", Work in Progress, Internet-
Draft, draft-ietf-raw-use-cases-08, 22 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
cases-08>.
Bernardos & Mourad Expires 13 September 2023 [Page 14]
Internet-Draft Mobile IPv6-based RAW-enabled mobility March 2023
[RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568,
DOI 10.17487/RFC5568, July 2009,
<https://www.rfc-editor.org/info/rfc5568>.
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
DOI 10.17487/RFC5949, September 2010,
<https://www.rfc-editor.org/info/rfc5949>.
Authors' Addresses
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Leganes, Madrid
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Alain Mourad
InterDigital Europe
Email: Alain.Mourad@InterDigital.com
URI: http://www.InterDigital.com/
Bernardos & Mourad Expires 13 September 2023 [Page 15]
