Autonomic SRv6 Network Fast Failover Using Bounce-back Strategy with GRASP
draft-du-anima-srv6-failover-grasp-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | 杜林潼 , Xirong Que , Fang Deng , Xiangyang Gong , Wendong Wang | ||
| Last updated | 2026-06-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-du-anima-srv6-failover-grasp-01
ANIMA L. Du, Ed.
Internet-Draft X. Que
Intended status: Standards Track F. Deng
Expires: 4 December 2026 X. Gong
W. Wang
BUPT
2 June 2026
Autonomic SRv6 Network Fast Failover Using Bounce-back Strategy with
GRASP
draft-du-anima-srv6-failover-grasp-01
Abstract
This document specifies an autonomic fast failover mechanism for SRv6
networks using a bounce-back strategy. It uses GRASP to distribute
failover protection information, enabling data plane fast reroute
without control plane reconvergence.
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 4 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Du, et al. Expires 4 December 2026 [Page 1]
Internet-Draft SRv6 Failover with GRASP June 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Failover Mechanism Overview . . . . . . . . . . . . . . . . . 5
3.1. Control Plane and Data Plane Separation . . . . . . . . . 5
3.2. Node Roles and Backup Path Requirements . . . . . . . . . 5
3.2.1. Anchor Node Definition . . . . . . . . . . . . . . . 5
3.2.2. Bouncer Node Definition . . . . . . . . . . . . . . . 5
3.2.3. Backup Path Requirements . . . . . . . . . . . . . . 5
3.3. Before Failure: Protection Information Distribution . . . 6
3.4. Failure Detection . . . . . . . . . . . . . . . . . . . . 6
3.5. After Failure: Bounce-back and Re-encapsulation . . . . . 6
4. GRASP Objective for Failover Path Management . . . . . . . . 7
4.1. Failover Path Manager Objective . . . . . . . . . . . . . 7
4.2. Objective Value Definition . . . . . . . . . . . . . . . 7
4.3. Objective Example . . . . . . . . . . . . . . . . . . . . 7
5. Failover Procedures and Scenarios . . . . . . . . . . . . . . 9
5.1. GRASP Procedures . . . . . . . . . . . . . . . . . . . . 9
5.2. Forwarding Behavior Requirements . . . . . . . . . . . . 9
5.3. Intra-domain Scenario . . . . . . . . . . . . . . . . . . 9
5.3.1. Topology and Configuration . . . . . . . . . . . . . 9
5.3.2. Failover Execution Example . . . . . . . . . . . . . 10
5.4. Inter-domain Scenario . . . . . . . . . . . . . . . . . . 11
6. Implementation Considerations . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. GRASP Objective Name . . . . . . . . . . . . . . . . . . 11
8.2. Node Role Registry . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Complete CDDL Definition . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Du, et al. Expires 4 December 2026 [Page 2]
Internet-Draft SRv6 Failover with GRASP June 2026
1. Introduction
Segment Routing over IPv6 (SRv6) [RFC8986] provides a flexible source
routing paradigm that enables explicit path specification for traffic
engineering and service chaining. This flexibility, however, comes
with a trade-off: when any node or link along an explicitly specified
SRv6 path fails, the entire path is disrupted. Traditional recovery
mechanisms rely on control plane reconvergence, which typically takes
seconds to complete.
Existing fast protection mechanisms such as Topology-Independent
Loop-Free Alternate (TI-LFA) provide local protection for IGP
segments. However, as noted in [RFC9256] Section 9, TI-LFA has
inherent limitations:
* SR Policies built with non-protected Adjacency SIDs do not benefit
from any local protection.
* Links that span multiple IGP domains cannot benefit from TI-LFA
automated local protection.
This document introduces a bounce-back strategy to address these
gaps. The strategy provides dual protection across the time
dimension:
* For in-flight packets at the moment of failure, the Bouncer node
bounces them back to the nearest upstream Anchor node, which re-
encapsulates the traffic with a pre-computed backup SRv6 segment
list.
* For new packets arriving after failure detection, the Anchor node
directly encapsulates them onto the backup path.
The mechanism uses GRASP [RFC8990] to autonomically distribute
failover protection information during path setup. The ACP [RFC8994]
and BRSKI [RFC8995] provide the security foundation.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Du, et al. Expires 4 December 2026 [Page 3]
Internet-Draft SRv6 Failover with GRASP June 2026
2. Terminology and Abbreviations
This document uses the terminology defined in [RFC7575] and
[RFC8986].
Anchor Node:
A node on the primary path that has a pre-computed backup path to
reach the destination. When receiving bounced-back traffic, it
re-encapsulates with the backup SRv6 segment list.
Bouncer Node:
A node on the primary path that does NOT have a backup path. It
can only bounce traffic upstream when detecting a downstream
failure.
Bounce-back:
The action of forwarding traffic toward the upstream direction
when a downstream link failure is detected.
FPM ASA:
Failover Path Manager Autonomic Service Agent. Manages the
computation, distribution, and installation of failover protection
information using GRASP.
Flow Identifier:
A value used to uniquely identify a communication flow. This
document uses the IPv6 Flow Label field for this purpose.
Primary Path:
The main forwarding path computed for normal traffic transmission.
Backup Path:
A pre-computed alternative path used when the primary path fails.
Cascading Bounce-back:
When a failure occurs, traffic bounces upstream through one or
more Bouncer nodes until reaching an Anchor node that can reroute
traffic via a backup path.
Path Initiator:
The entity responsible for computing paths and distributing
protection information via GRASP. Typically the Ingress Edge Node
or a centralized controller.
Path Responder:
A node on the primary path that receives protection information
from the Path Initiator via GRASP.
Du, et al. Expires 4 December 2026 [Page 4]
Internet-Draft SRv6 Failover with GRASP June 2026
3. Failover Mechanism Overview
The bounce-back failover mechanism operates in two distinct phases:
control plane setup using GRASP, and data plane failover execution.
3.1. Control Plane and Data Plane Separation
* Control Plane: Distributes failover protection information during
path setup. GRASP is NOT involved in failure detection or
failover execution.
* Data Plane: Performs failure detection, executes bounce-back
action, and performs backup path re-encapsulation. All failover
decisions are made locally based on pre-installed forwarding
state.
3.2. Node Roles and Backup Path Requirements
Each node on the primary path is assigned one of two roles:
3.2.1. Anchor Node Definition
An Anchor Node (role=0) has a valid backup path and can re-
encapsulate traffic. When receiving bounced-back traffic, it MUST
strip the original SRv6 encapsulation, re-encapsulate with its pre-
installed backup segment list, and forward toward the backup path
next-hop.
3.2.2. Bouncer Node Definition
A Bouncer Node (role=1) does NOT have a valid backup path. When
detecting downstream failure or receiving bounced-back traffic, it
MUST forward upstream without modification.
3.2.3. Backup Path Requirements
A valid backup path MUST satisfy: Reachability, Disjointness (MUST
NOT traverse any primary path link between Anchor and destination),
First-hop Difference, and SRv6 Expressibility.
Du, et al. Expires 4 December 2026 [Page 5]
Internet-Draft SRv6 Failover with GRASP June 2026
+----+ +----+ +----+
| b1 |-----| b2 |-----| b3 |
+----+ +----+ +----+
/ \
+----+ +----+ +----+ +----+ +----+ +----+
| h1 |-----| n1 |-----| n2 |-----| n3 |-----| n4 |-----| h2 |
+----+ +----+ +----+ +----+ +----+ +----+
Anchor Anchor Bouncer Bouncer
\ /
+----+ +----+
| b4 |-----| b5 |
+----+ +----+
Primary Path: h1 -> n1 -> n2 -> n3 -> n4 -> h2
Node Roles:
n1: Anchor (backup: n1 -> b1 -> b2 -> b3 -> h2)
n2: Anchor (backup: n2 -> b4 -> b5 -> h2)
n3: Bouncer (no backup path)
n4: Bouncer (no backup path)
Backup Path Validity:
A valid backup MUST NOT traverse any primary path link
downstream of the Anchor. For n2: backup via b4 -> b5 -> h2
is valid (avoids n2-n3, n3-n4, n4-h2 links)
Figure 1: Topology with Node Roles and Backup Paths
3.3. Before Failure: Protection Information Distribution
Before failure, protection information must be distributed to all
path nodes via GRASP, including node role, upstream/downstream
neighbor addresses, flow identifier, and backup segment list (for
Anchors).
3.4. Failure Detection
Failure detection is performed locally using link-layer detection,
BFD, or hardware port monitoring. To achieve sub-50ms failover,
hardware-assisted detection SHOULD be used.
3.5. After Failure: Bounce-back and Re-encapsulation
When failure occurs: (1) Node detects downstream interface failure,
(2) Immediately redirects traffic upstream, (3) Upstream nodes
identify bounced traffic by arrival interface and flow-id, (4)
Bouncer forwards upstream; Anchor re-encapsulates and forwards on
backup path.
Du, et al. Expires 4 December 2026 [Page 6]
Internet-Draft SRv6 Failover with GRASP June 2026
4. GRASP Objective for Failover Path Management
4.1. Failover Path Manager Objective
The objective name is "SRv6-Failover" conforming to [RFC8990].
Format in CDDL [RFC8610]:
objective = ["SRv6-Failover", objective-flags, loop-count, ?objective-value]
objective-name = "SRv6-Failover"
objective-flags = uint .bits objective-flag
loop-count = 0..255
objective-value = srv6-failover-value
Figure 2: GRASP Objective Format
4.2. Objective Value Definition
srv6-failover-value = [flow-info, primary-path-info, *node-protection-info]
flow-info = [flow-id, source-address, destination-address, lifetime]
flow-id = uint
source-address = bytes .size 16
destination-address = bytes .size 16
lifetime = uint
primary-path-info = [primary-segment-list, *anchor-backup-entry]
primary-segment-list = [*srv6-sid]
srv6-sid = bytes .size 16
anchor-backup-entry = [anchor-address, backup-segment-list]
node-protection-info = [node-address, node-role, upstream-neighbor, downstream-neighbor, ?backup-info]
node-role = &(anchor: 0, bouncer: 1)
backup-info = [backup-segment-list, backup-next-hop]
Figure 3: Flow and Path Information Structure
4.3. Objective Example
For the following topology and primary path:
Du, et al. Expires 4 December 2026 [Page 7]
Internet-Draft SRv6 Failover with GRASP June 2026
+----+ +----+ +----+
| b1 |-----| b2 |-----| b3 |
+----+ +----+ +----+
/ \
+----+ +----+ +----+ +----+ +----+ +----+
| h1 |-----| n1 |-----| n2 |-----| n3 |-----| n4 |-----| h2 |
+----+ +----+ +----+ +----+ +----+ +----+
Anchor Anchor Bouncer Bouncer
\ /
+----+ +----+
| b4 |-----| b5 |
+----+ +----+
Primary Path: h1 -> n1 -> n2 -> n3 -> n4 -> h2
Flow Identifier: 0x0000a
Figure 4: Example Topology
The GRASP objective value would contain:
srv6-failover-value = [
; flow-info
[0x0000a, h1-address, h2-address, 3600000],
; primary-path-info
[
[n1-sid, n2-sid, n3-sid, n4-sid, h2-sid], ; primary segment list
[n1-address, [b1-sid, b2-sid, b3-sid, h2-sid]], ; n1's backup
[n2-address, [b4-sid, b5-sid, h2-sid]] ; n2's backup
],
; node-protection-info for n1 (Anchor)
[n1-address, 0, h1-address, n2-address,
[[b1-sid, b2-sid, b3-sid, h2-sid], b1-address]],
; node-protection-info for n2 (Anchor)
[n2-address, 0, n1-address, n3-address,
[[b4-sid, b5-sid, h2-sid], b4-address]],
; node-protection-info for n3 (Bouncer)
[n3-address, 1, n2-address, n4-address],
; node-protection-info for n4 (Bouncer)
[n4-address, 1, n3-address, h2-address]
]
Figure 5: Objective Value Example
Du, et al. Expires 4 December 2026 [Page 8]
Internet-Draft SRv6 Failover with GRASP June 2026
5. Failover Procedures and Scenarios
5.1. GRASP Procedures
The FPM ASA on the Path Initiator discovers path nodes via GRASP
Discovery, then sends Request messages with node-protection-info.
Path Responders resolve addresses, install forwarding state, and
respond with Negotiation End (ACCEPT).
+------------------+ +------------------+
| FPM ASA | | FPM ASA |
| Path Initiator | | Path Responder |
+--------+---------+ +--------+---------+
| |
| M_DISCOVERY (SRv6-Failover) |
|---------------------------------------->|
| |
| M_RESPONSE (locator) |
|<----------------------------------------|
| |
| M_REQ_NEG (node-protection-info) |
|---------------------------------------->|
| |
| M_END (O_ACCEPT) |
|<----------------------------------------|
| |
Figure 6: GRASP Negotiation Procedure
5.2. Forwarding Behavior Requirements
Nodes MUST distinguish Normal Traffic (from upstream) and Bounced
Traffic (from downstream) based on arrival interface and flow
identifier. Anchor nodes re-encapsulate; Bouncer nodes forward
upstream.
5.3. Intra-domain Scenario
5.3.1. Topology and Configuration
Du, et al. Expires 4 December 2026 [Page 9]
Internet-Draft SRv6 Failover with GRASP June 2026
+----+ +----+ +----+
| b1 |-----| b2 |-----| b3 |
+----+ +----+ +----+
/ \
+----+ +----+ +----+ +----+ +----+ +----+
| h1 |-----| n1 |-----| n2 |-----| n3 |-----| n4 |-----| h2 |
+----+ +----+ +----+ +----+ +----+ +----+
Anchor Anchor Bouncer Bouncer
\ /
+----+ +----+
| b4 |-----| b5 |
+----+ +----+
Primary Path: h1 -> n1 -> n2 -> n3 -> n4 -> h2
Flow Identifier: 0x0000a
Protection Configuration:
n1: Anchor, upstream=h1, downstream=n2
backup=[b1-sid, b2-sid, b3-sid, h2-sid], next-hop=b1
n2: Anchor, upstream=n1, downstream=n3
backup=[b4-sid, b5-sid, h2-sid], next-hop=b4
n3: Bouncer, upstream=n2, downstream=n4
n4: Bouncer, upstream=n3, downstream=h2
Figure 7: Intra-domain Topology and Configuration
5.3.2. Failover Execution Example
When the n3-n4 link fails:
1. n3 detects the interface toward n4 is down.
2. n3 (Bouncer) bounces in-flight traffic toward n2.
3. n2 receives traffic from n3 direction with flow-id=0x0000a,
identifies it as bounced traffic.
4. n2 (Anchor) re-encapsulates traffic with backup segment list
[b4-sid, b5-sid, h2-sid] and forwards toward b4.
5. Traffic reaches h2 via the backup path n2 -> b4 -> b5 -> h2.
If b4-b5 link also fails, n2 bounces traffic to n1, which re-
encapsulates via its backup path n1 -> b1 -> b2 -> b3 -> h2
(cascading bounce-back).
Du, et al. Expires 4 December 2026 [Page 10]
Internet-Draft SRv6 Failover with GRASP June 2026
5.4. Inter-domain Scenario
Flow identifier is preserved across domain boundaries. Each domain
computes its own node roles for its portion of the path.
6. Implementation Considerations
OpenFlow implementations MAY use: in_port, eth_type, ipv6_dst,
ipv6_label match fields; fast-failover groups with watch_port.
P4 implementations MAY use: ingress metadata, tables keyed by
(ingress_port, flow_label, ipv6_dst), link status registers.
To achieve sub-50ms failover: use hardware-based detection, implement
bounce-back in hardware, pre-install forwarding state.
7. Security Considerations
This mechanism inherits security considerations of [RFC8990] and
[RFC8986].
* Authentication: All FPM ASA communication MUST occur over ACP
[RFC8994]. Nodes MUST be authenticated via BRSKI [RFC8995].
* Authorization: Only authorized nodes SHOULD initiate or modify
failover protection state.
* Integrity: GRASP messages MUST be integrity-protected.
* Flow Identifier Security: Ingress filtering SHOULD prevent flow
identifier spoofing.
* Resource Exhaustion: Rate limiting of GRASP requests SHOULD be
implemented.
8. IANA Considerations
8.1. GRASP Objective Name
IANA is requested to add "SRv6-Failover" to the "GRASP Objective
Names" registry. Reference: [this document]
8.2. Node Role Registry
IANA is requested to create "SRv6-Failover Node Role" registry with
initial values:
* 0: Anchor - A node with a pre-computed backup path
Du, et al. Expires 4 December 2026 [Page 11]
Internet-Draft SRv6 Failover with GRASP June 2026
* 1: Bouncer - A node that can only bounce traffic upstream
Values 2-255 are reserved. New values require Standards Action.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
Autonomic Signaling Protocol (GRASP)", RFC 8990,
DOI 10.17487/RFC8990, May 2021,
<https://www.rfc-editor.org/info/rfc8990>.
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
Autonomic Control Plane (ACP)", RFC 8994,
DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/info/rfc8994>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
9.2. Informative References
Du, et al. Expires 4 December 2026 [Page 12]
Internet-Draft SRv6 Failover with GRASP June 2026
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
Appendix A. Complete CDDL Definition
This appendix provides the complete CDDL definition for the
SRv6-Failover GRASP objective:
; SRv6-Failover GRASP Objective CDDL Definition
srv6-failover-objective = [
"SRv6-Failover",
objective-flags,
loop-count,
?srv6-failover-value
]
objective-flags = uint
loop-count = 0..255
srv6-failover-value = [
flow-info,
primary-path-info,
*node-protection-info
]
flow-info = [
flow-id: uint,
source-address: ipv6-address,
destination-address: ipv6-address,
lifetime: uint
]
ipv6-address = bytes .size 16
primary-path-info = [
primary-segment-list: [*srv6-sid],
*anchor-backup-entry
]
Du, et al. Expires 4 December 2026 [Page 13]
Internet-Draft SRv6 Failover with GRASP June 2026
srv6-sid = bytes .size 16
anchor-backup-entry = [
anchor-address: ipv6-address,
backup-segment-list: [*srv6-sid]
]
node-protection-info = [
node-address: ipv6-address,
node-role: 0..1,
upstream-neighbor: ipv6-address,
downstream-neighbor: ipv6-address,
?backup-info
]
backup-info = [
backup-segment-list: [*srv6-sid],
backup-next-hop: ipv6-address
]
Figure 8: Complete CDDL Definition
Acknowledgements
The authors thank the contributors of the ANIMA working group for
their valuable feedback on autonomic networking mechanisms.
Authors' Addresses
Lintong Du (editor)
Beijing University of Posts and Telecommunications
No.10 Xitucheng Road
Beijing
Hai-Dian District, 100876
China
Email: baronmail@bupt.edu.cn
Xirong Que
Beijing University of Posts and Telecommunications
No.10 Xitucheng Road
Beijing
Hai-Dian District, 100876
China
Email: rongqx@bupt.edu.cn
Du, et al. Expires 4 December 2026 [Page 14]
Internet-Draft SRv6 Failover with GRASP June 2026
Fang Deng
Beijing University of Posts and Telecommunications
No.10 Xitucheng Road
Beijing
Hai-Dian District, 100876
China
Email: dengfang@bupt.edu.cn
Xiangyang Gong
Beijing University of Posts and Telecommunications
No.10 Xitucheng Road
Beijing
Hai-Dian District, 100876
China
Email: xygong@bupt.edu.cn
Wendong Wang
Beijing University of Posts and Telecommunications
No.10 Xitucheng Road
Beijing
Hai-Dian District, 100876
China
Email: wdwang@bupt.edu.cn
Du, et al. Expires 4 December 2026 [Page 15]