SPRING F. Yang
Internet-Draft X. Duan
Intended status: Informational China Mobile
Expires: 13 April 2027 C. Lin
New H3C Technologies
G. Mishra
Verizon Inc.
10 October 2026
SID as source address in SRv6
draft-ietf-spring-sid-as-source-address-01
Abstract
Segment Routing over IPv6 (SRv6) is deployed in backbone networks
within trusted domains to provide end-to-end services in carrier and
enterprise networks. However, a stateful firewall on an SRv6
forwarding path may discard legitimate SRv6 packets and ICMP error
messages generated by SRv6 transit nodes because packets in the two
directions may have different flow tuples.
This document specifies a mechanism that uses an SRv6 Segment
Identifier (SID) as the source address in the outer IPv6 header. A
distinct source SID can be assigned to each Customer Edge (CE) or
Virtual Routing and Forwarding (VRF) instance, enabling a firewall to
perform per-flow stateful filtering of TCP traffic without requiring
SRv6 support in the firewall or the deployment of an SRv6 proxy.
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 April 2027.
Yang, et al. Expires 13 April 2027 [Page 1]
Internet-Draft SID as source address October 2026
Copyright Notice
Copyright (c) 2026 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Using SRv6 SID as Source Address . . . . . . . . . . . . . . 4
2.1. User Traffic . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. IP VPN over SRv6 . . . . . . . . . . . . . . . . . . 4
2.1.2. Global IP over SRv6 . . . . . . . . . . . . . . . . . 5
2.2. ICMP Traffic . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Control and Management Traffic . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. SRv6 Network with SR-aware Stateful Firewall . . . . . . 5
3.1.1. Problem Statement . . . . . . . . . . . . . . . . . . 5
3.1.2. Solution for SRv6 Traffic Pass Thru SR-aware Stateful
Firewall . . . . . . . . . . . . . . . . . . . . . . 8
4. Considerations on SRv6 Compression . . . . . . . . . . . . . 9
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
5.1. New H3C Technologies . . . . . . . . . . . . . . . . . . 9
6. Operational Considerations . . . . . . . . . . . . . . . . . 10
6.1. Locator and SID Planning . . . . . . . . . . . . . . . . 10
6.2. Coexistence with SRv6 Compression . . . . . . . . . . . . 10
6.3. Incremental Deployment and Rollback . . . . . . . . . . . 10
6.4. Stateful Middle-box Considerations . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Yang, et al. Expires 13 April 2027 [Page 2]
Internet-Draft SID as source address October 2026
1. Introduction
Segment Routing over IPv6 (SRv6) is commonly deployed in trusted
backbone domains to provide end-to-end services in carrier and
enterprise networks. However, when a stateful firewall is located on
an SRv6 forwarding path, it may discard legitimate SRv6 packets,
including ICMP error messages generated by SRv6 transit nodes,
because packets in the two directions may have different flow tuples.
As described in Section 8.1 of [I-D.ietf-spring-srv6-security], an
SRv6 ingress Provider Edge (PE) router may use its loopback IPv6
address as the source address in the outer IPv6 header.
Consequently, packets in the two directions of the same communication
may have different outer-header flow tuples. A stateful firewall on
the SRv6 forwarding path may therefore be unable to associate
reverse-direction packets or ICMP error messages with an existing
session and may discard those packets.
To avoid such packet loss, operators may deploy an additional layer
of tunneling, such as IPsec, to traverse the firewall. This
additional encapsulation increases header overhead and reduces the
benefits of native SRv6 programmability.
This document specifies a mechanism that uses an SRv6 Segment
Identifier (SID) as the source address of the outer IPv6 header. A
distinct source SID can be assigned to each Customer Edge (CE) or
Virtual Routing and Forwarding (VRF) instance. This mechanism
enables a firewall to perform per-flow, TCP stateful filtering
without requiring the firewall to support SRv6 or requiring the
deployment of an SRv6 proxy.
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.
1.2. Terminology
AC: attachment circuit.
PE: Provider Edge.
SID: Segment Identifier, defined in [RFC8402].
SRv6: SR over IPv6, defined in [RFC8402].
Yang, et al. Expires 13 April 2027 [Page 3]
Internet-Draft SID as source address October 2026
SRH: Segment Routing Header, defined in [RFC8754]
VPN: Virtual Private Network.
2. Using SRv6 SID as Source Address
Only unicast traffic is eligible for using SID as source address, and
multicast is out of scope for this document. Two cases should be
considered for using SRv6 SID as source address when there is
firewall in middle.
* User traffic. This includes IP VPN over SRv6 and Global IP over
SRv6.
* ICMP traffic. This is mainly for SRv6 Ping in SRv6 OAM [RFC9259]
scenario.
2.1. User Traffic
2.1.1. IP VPN over SRv6
The user traffic MUST use the SRv6 service SID as the source address
of the outer IPv6 header. All those End.DX* and End.DT* SIDs except
End.DT2M can be used for source address. Service SIDs in SRv6 VPN
deployments may be allocated per-AC, per-VRF, or per-prefix, and
these three granularities can coexist within the same network and
even within the same VRF.
There are 3 options:
* Option A: Use the VRF-bound SID as source address.
* Option B: Use the AC-bound SID as source address.
* Option C: Use the prefix SID as source address, and perform a
source-IP-based lookup in the VRF to select the SID associated
with the route matching the source address.
Option A requires zero additional lookup, as the VRF is identified
from the incoming AC. This is operationally simple and sufficient
for many deployments. However, all CEs in the same VRF will appear
to the firewall as originating from the same source SID, which may
limit per-CE state tracking. Option B provides the symmetry at the
AC level, and with zero additional lookup. Option C introduces
significant additional lookup cost, as the PE must perform a separate
lookup on the source IP address of the customer packet. This is
operationally expensive and may impact forwarding performance.
Yang, et al. Expires 13 April 2027 [Page 4]
Internet-Draft SID as source address October 2026
The selection of the source service SID on the ingress PE is
dependent on and MUST mirror the service SID that the egress PE
expects to receive for the corresponding VPN flow; the most granular
available SID that matches the incoming context MUST be chosen, which
typically means using the per-prefix SID when available, falling back
to the per-AC SID, and last is per VPN SID.
2.1.2. Global IP over SRv6
Sections 5.3 and 5.4 of [RFC9252] specify the SRv6 Service SIDs to be
used for Global IP over SRv6 Core (both IPv4 and IPv6). Accordingly,
for the IPv4 over SRv6 Core scenario, End.DX4, End.DT4, or End.DT46
SHOULD be selected as the source address; for the IPv6 over SRv6 Core
scenario, End.DX6, End.DT6, or End.DT46 SHOULD be selected as the
source address.
2.2. ICMP Traffic
For SRv6 ping, the ICMP Echo Request MUST use an End SID as the outer
IPv6 source address to verify the reachability of the return path.
When an SRv6 transit node generates an ICMP error response, using its
own SID (the one from the segment list that caused the processing
error) as the source address offers a clear operational benefit: the
head-end can immediately pinpoint exact SID and node on which the
error occurred. When the ICMP error is triggered by VPN traffic, the
ingress PE, upon receiving the ICMP error response, MUST process the
upper-Layer header of the embedded packet as specified in
Section 4.1.1 of [RFC8986]. This ensures that the inner ICMP can be
forwarded to the CE.
2.3. Control and Management Traffic
Control and Management Traffic will not be terminated by VPN, thus
will not be impacted.
3. Use Cases
3.1. SRv6 Network with SR-aware Stateful Firewall
3.1.1. Problem Statement
To provide VPN service in an SRv6 network [RFC9252], the ingress PE
encapsulates the payload in an outer IPv6 header with the SRH
carrying the SR Policy segment list along with the VPN Service SID.
If the VPN service provides best-effort connectivity, the destination
address of the outer IPv6 header carries the VPN service SID and the
SRH is omitted.
Yang, et al. Expires 13 April 2027 [Page 5]
Internet-Draft SID as source address October 2026
Along the forwarding path in the SRv6 network, firewalls may be
deployed to filter the traffic. If a firewall is SR-aware, it will
retrieve the final destination of an SRv6 packet from the last entry
in the SRH rather than the destination address field of the IPv6
header [I-D.ietf-spring-srv6-service-programming].
A stateful firewall keeps a track of the state of the network
connections traveling across it. Whenever a packet arrives to seek
permission to pass through it, the firewall checks from its state
table if there is an active connection between identified by 3-tuple
or 5-tuple. Thus only legitimate packets are allowed to be
transmitted across it.
Figure 1 and Figure 2 show the bidirectional VPN traffic packets
passing through a firewall in an SRv6 network.
The source address of the outer IPv6 header is the IPv6 address of
ingress PE. The final destination address of the outer IPv6 header
is the VPN Service SID of egress PE. In the SR-Policy-based way, the
final destination address is encapsulated in the last entry in the
SRH, Segment[0]. In the best-effort way, the SRH is omitted.
+---+ +---+ +--------+ +---+ +---+
|CE1|---|PE1|--...--|Firewall|--...--|PE2|---|CE2|
+---+ +---+ +--------+ +---+ +---+
Packet (PE1 ---> PE2): Packet (PE1 <--- PE2):
********************** **********************
* IPv6 * * IPv6 *
* SA=PE1-IP-ADDR * * SA=PE2-IP-ADDR *
* DA=NextSegment * * DA=NextSegment *
********************** **********************
* SRH * * SRH *
* Seg[0]=PE2-VPN-SID * * Seg[0]=PE1-VPN-SID *
* Seg[...] * * Seg[...] *
********************** **********************
* Eth/IPv4/IPv6 * * Eth/IPv4/IPv6 *
* Source=CE1 * * Source=CE2 *
* Destination=CE2 * * Destination=CE1 *
********************** **********************
* Payload * * Payload *
********************** **********************
Figure 1: SR-Policy-based VPN Traffic across Firewall
Yang, et al. Expires 13 April 2027 [Page 6]
Internet-Draft SID as source address October 2026
+---+ +---+ +--------+ +---+ +---+
|CE1|---|PE1|--...--|Firewall|--...--|PE2|---|CE2|
+---+ +---+ +--------+ +---+ +---+
Packet (PE1 ---> PE2): Packet (PE1 <--- PE2):
********************** **********************
* IPv6 * * IPv6 *
* SA=PE1-IP-ADDR * * SA=PE2-IP-ADDR *
* DA=PE2-VPN-SID * * DA=PE1-VPN-SID *
********************** **********************
* Eth/IPv4/IPv6 * * Eth/IPv4/IPv6 *
* Source=CE1 * * Source=CE2 *
* Destination=CE2 * * Destination=CE1 *
********************** **********************
* Payload * * Payload *
********************** **********************
Figure 2: Best-Effort VPN Traffic across Firewall
The stateful firewall will check the association relationships of the
bidirectional VPN traffic packets. A common implementation may
record the key information of the packets in the forward way(internal
to external), such as source address and destination address. When
receiving a packet on backward way(external to internal), it checks
the state table if there is an existing forward packet flow. For
example, the firewall may require that the source address of packet
on backward way matches the destination address of packet on forward
way, and destination address will be checked in the similar way. If
not matched, the packet on the backward path will be regarded as
illegal and thus dropped.
An SR-aware firewall is able to retrieve the final destination of an
SRv6 packet from the last entry in the SRH. The <source,
destination> tuple of the packet from PE1 to PE2 is <PE1-IP-ADDR,
PE2-VPN-SID>, and the other direction is <PE2-IP-ADDR, PE1-VPN-SID>.
However, the source address of the outer IPv6 packet is usually a
loopback interface of the ingress PE. Consequently, the source
address and destination address of the forward and backward VPN
traffic are regarded as different flows, and they may be blocked by
the firewall.
Yang, et al. Expires 13 April 2027 [Page 7]
Internet-Draft SID as source address October 2026
3.1.2. Solution for SRv6 Traffic Pass Thru SR-aware Stateful Firewall
In the SRv6-based VPN service, the final destination of the outer
IPv6 header is the VPN-SID of the egress PE, which is associated with
that VPN service. But the source address of the outer IPv6 header is
usually unrelated to the VPN service. So, it can be difficult for a
stateful firewall to establish the association relationship between
the bidirectional traffic flows.
The solution described in this document is to unify the semantic of
the source and and destination address thus ensure the symmetry of
the bidirectional flow.
When an ingress PE receives the client packet from CE, it checks
which L3 VPN service it belongs to, and uses the VPN-SID associated
with that L3 VPN service as the source address when encapsulating the
outer IPv6 header with the optional SRH.
Outer IPv6 Header of SR-Policy-based VPN Traffic:
********************** **********************
* IPv6 * * IPv6 *
* SA=PE1-VPN-SID * * SA=PE2-VPN-SID *
* DA=NextSegment * * DA=NextSegment *
********************** **********************
* SRH * * SRH *
* Seg[0]=PE2-VPN-SID * * Seg[0]=PE1-VPN-SID *
* Seg[...] * * Seg[...] *
********************** **********************
Outer IPv6 Header of Best-effort VPN Traffic:
********************** **********************
* IPv6 * * IPv6 *
* SA=PE1-VPN-SID * * SA=PE2-VPN-SID *
* DA=PE2-VPN-SID * * DA=PE1-VPN-SID *
********************** **********************
Figure 3: Outer IPv6 Header in the Proposed Solution
According to [RFC8402] and [RFC8986], an SRv6 VPN Service SID is an
IPv6 address, and it is routable by its Locator prefix in the SRv6
network. In the proposed solution, when an SRv6 VPN Service SID is
used as the source address of the outer IPv6 header in the SRv6
network, it is treated as a normal IPv6 address and does not perform
any special behavior.
Yang, et al. Expires 13 April 2027 [Page 8]
Internet-Draft SID as source address October 2026
4. Considerations on SRv6 Compression
When an SRv6 packet is forwarded in the SRv6 domain, its IPv6
destination address is modified in each segment, and the final
destination address is not available in the IPv6 header. It is
therefore possible to retrieve the final destination of an SRv6
packet from the last entry in the SRH.
When compressed segment lists [RFC9800] are used, the last element of
the Routing Header may be different from the destination address as
received by the final destination. Furthermore, compressed segment
lists can be used in the destination address without the presence of
a Routing Header, and in this case the IPv6 destination address can
be modified along the path. To ensure proper operation of the
stateful firewall, it is RECOMMENDED that during the deployment of
[RFC9800], the last destination address remains uncompressed and be
carried as the last element in the SRH.
5. Implementation Status
[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to [RFC7942]. This section records the
status of known implementations of the protocol defined by this
specification at the time of posting of this Internet-Draft, and is
based on a proposal described in [RFC7942]. The description of
implementations in this section is intended to assist the IETF in its
decision processes in progressing drafts to RFCs. Please note that
the listing of any individual implementation here does not imply
endorsement by the IETF. Furthermore, no effort has been spent to
verify the information presented here that was supplied by IETF
contributors. This is not intended as, and must not be construed to
be, a catalog of available implementations or their features.
Readers are advised to note that other implementations may exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
5.1. New H3C Technologies
* Organization: New H3C Technologies.
* Implementation: H3C CR16000 and CR19000 series routers implement
SID as source address in SRv6.
Yang, et al. Expires 13 April 2027 [Page 9]
Internet-Draft SID as source address October 2026
* Description: All sections including all the "MUST" and "SHOULD"
clauses have been implemented in the above-mentioned New H3C
products(running version 7.1.119 and above).
* Maturity Level: Production
* Coverage: All sections.
* Version: Draft-13
* Licensing: N/A
* Implementation experience: Nothing specific.
* Contact: linchangwang.04414@h3c.com
* Last updated: June 30, 2026
6. Operational Considerations
This document does not introduce additional extension headers, so
existing SRv6 MTU operational rules apply unchanged.
6.1. Locator and SID Planning
Service SIDs used as source addresses MUST be routable in the global
routing table. SIDs confined to a single VRF MUST NOT be used as
outer source addresses, as this breaks return-path reachability for
ICMP and reverse user traffic.
6.2. Coexistence with SRv6 Compression
When SRv6 compressed segment lists [RFC9800] are enabled, operators
are RECOMMENDED to keep the final destination SID uncompressed and
present as the last segment in the SRH. This preserves bidirectional
flow tuple symmetry required by stateful firewalls.
6.3. Incremental Deployment and Rollback
The mechanism supports incremental deployment. Operators MAY enable
SID-as-source for selected VRFs, attachment circuits, or services
while keeping traditional PE loopback outer source addresses for the
rest of the network.
Yang, et al. Expires 13 April 2027 [Page 10]
Internet-Draft SID as source address October 2026
6.4. Stateful Middle-box Considerations
For SRv6 Policy, firewalls along the forwarding path MUST be SR-aware
and extract the final destination from the last entry in the SRH
rather than the outer IPv6 destination address. Using per-prefix
SIDs as source addresses increases session table cardinality.
Operators MUST evaluate session table sizing, aging timers, and
overflow alarms before enabling this feature at scale.
7. Security Considerations
This document is subject to the same security considerations
discussed in [RFC8402], [RFC8754], and [RFC8986].
The proposed use of an SRv6 SID as the IPv6 source address introduces
specific considerations:
* Source Accountability: Using an SRv6 SID as the source address may
impair traceability mechanisms that rely on source address
validation, reducing the trustworthiness of the source identity
within the domain.
* Access Control Bypass: Since SRv6 Locator prefixes are typically
advertised throughout the routing domain, any node can originate
traffic with a spoofed source address matching an internal SID
prefix. This could allow attackers to bypass intra-domain access
control policies by masquerading as trusted internal traffic.
* Stateful Device Impact: The dynamic and programmable nature of
SRv6 SIDs, when used as source addresses, can lead to rapid churn
in the session tables of stateful devices like firewalls. This
may cause excessive resource consumption, abnormal session aging,
and potential session table overflow, impacting device performance
and stability.
* Operational Requirement: Deployment of this mechanism requires
strict operational controls to govern which service flows are
permitted to use an SRv6 SID as a source address. Unrestricted
use amplifies the associated risks.
8. IANA Considerations
This document has no IANA actions.
9. References
9.1. Normative References
Yang, et al. Expires 13 April 2027 [Page 11]
Internet-Draft SID as source address October 2026
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/rfc/rfc8754>.
[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/rfc/rfc8986>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/rfc/rfc9252>.
[RFC9259] Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M.
Chen, "Operations, Administration, and Maintenance (OAM)
in Segment Routing over IPv6 (SRv6)", RFC 9259,
DOI 10.17487/RFC9259, June 2022,
<https://www.rfc-editor.org/rfc/rfc9259>.
[RFC9800] Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, Ed., "Compressed SRv6 Segment List Encoding",
RFC 9800, DOI 10.17487/RFC9800, June 2025,
<https://www.rfc-editor.org/rfc/rfc9800>.
[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/rfc/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/rfc/rfc8174>.
9.2. Informative References
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
Yang, et al. Expires 13 April 2027 [Page 12]
Internet-Draft SID as source address October 2026
[I-D.ietf-spring-srv6-service-programming]
Abdelsalam, A., Filsfils, C., Bernier, D., Li, C., and B.
Decraene, "SRv6 Service Programming", Work in Progress,
Internet-Draft, draft-ietf-spring-srv6-service-
programming-00, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-service-programming-00>.
[I-D.ietf-spring-srv6-security]
Buraglio, N., Mizrahi, T., tongtian, Contreras, L. M., and
F. Gont, "Segment Routing IPv6 Security Considerations",
Work in Progress, Internet-Draft, draft-ietf-spring-srv6-
security-17, 2 October 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-security-17>.
Acknowledgements
The authors would like to thank Bruno Decraene in the SPRING Working
Group for his detailed review and constructive comments on this
document.
Authors' Addresses
Feng Yang
China Mobile
China
Email: yangfeng@chinamobile.com
Xiaodong Duan
China Mobile
China
Email: duanxiaodong@chinamobile.com
Changwang Lin
New H3C Technologies
China
Email: linchangwang.04414@h3c.com
Gyan Mishra
Verizon Inc.
United States of America
Email: gyan.s.mishra@verizon.com
Yang, et al. Expires 13 April 2027 [Page 13]
