LSR D. Li Internet-Draft Tsinghua University Intended status: Standards Track L. Qin Expires: 28 April 2025 Zhongguancun Laboratory X. Song ZTE Corporation C. Lin New H3C Technologies S. Yue China Mobile 20 October 2024 IGP-based Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) draft-li-lsr-igp-based-intra-domain-savnet-03 Abstract This document proposes a new IGP-based intra-domain source address validation (SAV) solution, called IGP-SAVNET, which improves the accuracy upon current intra-domain SAV solutions. It allows intra- domain routers to communicate SAV-specific information using the intra-domain routing protocol or an extension to the intra-domain routing protocol. By using SAV-specific information, intra-domain routers can generate and update accurate SAV rules in an automatic way. 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 April 20, 2025. Li, et al. Expires April 28, 2025 [Page 1] Internet-Draft IGP-SAVNET October 2024 Copyright Notice 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. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................3 2. Terminology....................................................3 3. Goals of Intra-domain SAV......................................4 4. Description of the Method......................................5 4.1. SAV procedure on customer-facing or host-facing routers...5 4.2. SAV procedure on AS border routers........................7 5. SAV-specific Information Communication Using IGP...............8 5.1. Approach #1: Using the existing Administrative Tag Sub-TLV9 5.1.1. Administrative Tag Sub-TLV of IS-IS..................9 5.1.2. Administrative Tag Sub-TLV of OSPF..................10 5.1.3. Administrative Tag Sub-TLV of OSPFv3................10 5.1.4. Considerations of using Administrative Tag Sub-TLV..10 5.2. Approach #2: Defining a new SAVNET Tag Sub-TLV...........10 5.2.1. SAVNET Tag Sub-TLV of IS-IS.........................10 5.2.2. SAVNET Tag Sub-TLV of OSPF and OSPFv3...............11 6. Security Considerations.......................................11 7. IANA Considerations...........................................12 8. References....................................................12 8.1. Normative References.....................................12 8.2. Informative References...................................13 Authors' Addresses...............................................14 1. Introduction The purpose of intra-domain SAV is to prevent outgoing data packets from an intra-domain subnet (e.g., a host network or a customer network) from forging source addresses of other intra-domain subnets or other ASes, and to prevent incoming data packets from external ASes from forging source addresses of the local AS. To this end, Li, et al. Expires April 28, 2025 [Page 2] Internet-Draft IGP-SAVNET October 2024 intra-domain SAV should focus on SAV on host-facing routers, customer-facing routers, and AS border routers (see [I-D.ietf- savnet-intra-domain-architecture]). Specifically, host-facing routers or customer-facing routers should block data packets from the connected host network or customer network with a spoofed source IP address not belonging to that network. AS border routers should block data packets from other ASes with a spoofed source IP address belonging to the local AS. However, existing intra-domain SAV solutions (e.g., BCP38 [RFC2827] and BCP84 [RFC3704]) have problems of high operational overhead or inaccurate validation (see [I-D.ietf-savnet-intra-domain-problem- statement]). ACL-based ingress filtering requires manual operations to configure and update the SAV rules, while uRPF-based solutions may improperly block legitimate data packets in the scenario of routing asymmetry. To address these problems and guide the design of new intra-domain SAV solutions, [I-D.ietf-savnet-intra-domain- architecture] proposes the architecture of intra-domain SAVNET and introduces the use of SAV-specific information in intra-domain networks. Following the intra-domain SAVNET architecture, this document proposes a new IGP-based intra-domain SAV solution, called IGP- SAVNET, which improves the accuracy upon current intra-domain SAV solutions. It allows host-facing routers, customer-facing routers, and AS border routers to communicate SAV-specific information using the intra-domain routing protocol or an extension to the intra- domain routing protocol. By using SAV-specific information, these routers can generate and update accurate SAV rules in an automatic way. The reader is encouraged to be familiar with [I-D.ietf-savnet-intra- domain-problem-statement] and [I-D.ietf-savnet-intra-domain- architecture]. 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. 2. Terminology SAV Rule: The rule in a router that describes the mapping relationship between a source address (prefix) and the valid incoming interface(s). It is used by a router to make SAV decisions and is inferred from the SAV Information Base. Li, et al. Expires April 28, 2025 [Page 3] Internet-Draft IGP-SAVNET October 2024 Host-facing Router: An intra-domain router of an AS which is connected to an intra-domain host network (i.e., a layer-2 network). Customer-facing Router: An intra-domain router of an AS which is connected to an intra-domain customer network running the routing protocol (i.e., a layer-3 network). AS Border Router: An intra-domain router of an AS which is connected to other ASes. 3. Goals of Intra-domain SAV Goal 1: The host-facing router or customer-facing router should identify source prefixes belonging to its host network or customer etwork and block data packets from its host network or customer network using source addresses not belonging to the network.For example, in Figure 1, Routers A and B should generate SAV rules at the interface '#' and block data packets from Network 1 using source ddresses not belonging to Network 1. Router C should generate SAV rules at interfaces '#' and block data packets from Network 2 using source addresses not belonging to Network 2. Goal 2: The AS border router should identify source prefixes belonging to the local AS and block data packets from other ASes using source addresses belonging to the local AS. For example, in Figure 1, Routers D and E should generate SAV rules at interface '#' and block data packets from other ASes using source addresses belonging to the local AS. Li, et al. Expires April 28, 2025 [Page 4] Internet-Draft IGP-SAVNET October 2024 +----------------------------------+ | Other ASes | +----------------------------------+ | | +---------------|----------------------------|--------------+ | Intra-domain | | | | | | | | +-----#----+ +-----#----+ | | | Router D | | Router E | | | +----------+ +----------+ | | | | | | | | | | +----------------------------------------+ | | | Other intra-domain routers | | | +----------------------------------------+ | | / \ | | | / \ | | | +----------+ +----------+ +----------+ | | | Router A | | Router B | | Router C | | | +----#-----+ +-------#--+ +-----#----+ | | \ / | | +--------+\------------/---------------------|--------------+ \ / | +------------------+ +------------------+ | Customer or Host | | Customer or Host | | Network 1 | | Network 2 | +------------------+ +------------------+ Figure 1: Goals of Intra-domain SAV 4. Description of the Method To achieve the above two goals, IGP-SAVNET allows host-facing routers, customer-facing routers, and AS border routers to communicate SAV-specific information between each other through IGP. These routers will not communicate SAV-specific information with routers/devices in host networks, customer networks, and other ASes. In the following, this document describes how IGP-SAVNET works to meet the goals. 4.1. SAV procedure on customer-facing or host-facing routers SAV on a customer-facing (or host-facing) router aims to identify source prefixes belonging to the customer (or host) network. After that, the customer-facing (or host-facing) router can perform accurate SAV filtering by only accepting data packets from its customer (or host) network with source addresses belonging to that network. If the customer (or host) network is single-homed, the Li, et al. Expires April 28, 2025 [Page 5] Internet-Draft IGP-SAVNET October 2024 customer-facing (or host-facing) router can directly identify source prefixes through its local routes to that network. If the customer (or host) network is multi-homed, the customer-facing (or host- facing) router may fail to identify all source prefixes of that network through its local routes to that network in the scenario of routing asymmetry (see[I-D.ietf-savnet-intra-domain-problem- statement]). For example, in Figure 2, due to traffic engineering, Router A only learns the route to sub prefix 10.1.0.0/16 from Network N, while Router B only learns the route to the other sub prefix 10.0.0.0/16 from Network N. In this case, as described in [I-D.ietf-savnet-intra-domain-problem-statement], strict uRPF on Router A will block data packets from the customer (or host) network with legitimate source addresses in prefix 10.0.0.0/16, and strict uRPF on Router B will block data packets from the customer (or host) network with legitimate source addresses in prefix 10.1.0.0/16. To achieve accurate SAV on routers facing the multi-homed customer (or host) network, IGP-SAVNET allows routers facing the same customer (or host) network to identify source prefixes of the network through SAV-specific information communication. +-----------------------------------------------------+ | AS | | [10.1.0.0/16]+[tag n] | | +----------+ +---------------------> +----------+ | | | Router A | SAV-specific info | Router B | | | +-------#--+ <---------------------+ +--#-------+ | | | [10.0.0.0/16]+[tag n] | | | | | | | | | | | | +--------------------+ | | | | | Customer or Host | | | | +----| Network N |-----+ | | +--------------------+ | | (10.0.0.0/15 ) | +-----------------------------------------------------+ Figure 2: SAV-specific information communication between Routers A and B A detailed description of SAV procedure is as follows: 1. Tag Assignment: Each single-homed or multi-homed customer (or host) network is assigned a unique tag value. For example, in Figure 2, Network N is assigned tag n. The tag value for can be configured and updated manually. Specifically, the tag n is configured on the interface of the customer-facing router corresponding to this customer network, that is, tag n is Li, et al. Expires April 28, 2025 [Page 6] Internet-Draft IGP-SAVNET October 2024 configured on interface # of Router A and also on interface # of Router B. 2. SAV-specific Information Communication: Each customer-facing (or host-facing) router provides its SAV-specific information of its customer (or host) networks to other intra-domain routers. The SAV-specific information of a customer (or host) network contains the prefixes learned through the router's local routes to the network and the tag value of the network. For example, Router A can provide its SAV-specific information, which contains prefix 10.1.0.0/16 and tag n, to other intra-domain routers. This procedure can be implemented by using IGP or extensions to IGP,which will be elaborated in Section 5. 3. SAV-specific Information Processing: When a router receives SAV-specific information containing the same tag value as the one configured on its local customer-facing interface, it considers that the prefixes contained in the SAV-specific information also belong to its customer (or host) network corresponding to the customer-facing interface. For example, Router B, after receiving the SAV-specific information provided by Router A, finds that the tag n is the same as the tag n configured on its local interface #, and therefore will identify prefix 10.1.0.0/16 as a source prefix of Network N. 4. Source Prefix Identification: By integrating prefixes learned through SAV-specific information provided by other routers with prefixes learned through its local routes, the customer-facing(or host-facing) router can identify complete source prefixes of its customer (or host) network. For example, Router B will identify that both prefix 10.1.0.0/16 and prefix 10.0.0.0/16 belong to Network N after processing SAV-specific information provided by Router A. Similarly, Router A will also identify complete source prefixes of Network N after processing SAV-specific information provided by Router B. 5. SAV Rule Generation: Each customer-facing (or host-facing)router generates an allowlist containing source prefixes of its customer (or host) network at the interface facing that network. Only data packets using source addresses covered in the allowlist will be accepted at this interface. 4.2. SAV procedure on AS border routers SAV on an AS border router aims to identify source prefixes belonging to the local AS. After receiving SAV-specific information or routing information originating from host-facing and customer- facing routers through IGP, AS border routers can identify source prefixes of the local AS accordingly and generate a blocklist containing these source prefixes. After that, data packets arriving Li, et al. Expires April 28, 2025 [Page 7] Internet-Draft IGP-SAVNET October 2024 from other ASes with source addresses belonging to the local AS will be blocked on the AS border router. Blocklists can be generated on specific interfaces, typically those connected to external ASes. These interfaces can be manually configured to generate the blocklist. The source prefixes that need to be included in the blocklist can be filtered through specific routing policies or flagged to control their inclusion. This approach helps manage the source prefixes that contribute to the blocklist, preventing the creation of an excessive number of blocklist entries. 5. SAV-specific Information Communication Using IGP The key idea is to add the tag value into the prefix information when the customer-facing (or host-facing) router distributes the prefix information of its customer (or host) network. As shown in Figure 3,the SAVNET Agent of a Sender Router provides its SAV- specific information to other SAVNET routers via IGP. After receiving SAV-specific information from other SAVNET routers, the SAVNET Agent of the Receiver Router generates SAV rules by using SAV-specific information from other SAVNET routers and/or its own SAV-specific information. The Sender Router can be a customer- facing router or a host-facing router. The Receiver Router can be a customer-facing router, a host-facing router, or an AS border router. +---------------------+ +---------------------+ | Sender Router | SAV-specific | Receiver Router | | +------------+ | Information | +------------+ | | | IGP LSDB +------------------------->+ IGP LSDB | | | +-----^------+ | | +-----+------+ | | | | | | | | +-------+---------+ | | +--------v--------+ | | | SAVNET Agent | | | | SAVNET Agent | | | | +-------------+ | | | | +-------------+ | | | | | Information | | | | | | Information | | | | | | Provider | | | | | | Receiver | | | | | +-------------+ | | | | +-------------+ | | | +-----------------+ | | +-----------------+ | | | | | +---------------------+ +---------------------+ Figure 3: Overview of SAV-specific information communication Li, et al. Expires April 28, 2025 [Page 8] Internet-Draft IGP-SAVNET October 2024 The overall procedure of SAV-specific information communication is as follows: * At the Sender Router: Carry its SAV-specific information (e.g., the tag information of the customer or host network) through the Link State Database (LSDB) of IGP. The IGP will synchronize the LSDB, including node information, link information, prefix information, and tag information. * At the Receiver Router: After receiving SAV-specific information carried in the LSDB, its SAVNET Agent extracts SAV-specific information from the LSDB of IGP and then generates SAV rules as described in Section 4. In the following, this document presents two approaches to implement SAV-specific information communication among intra-domain routers. 5.1. Approach #1: Using the existing Administrative Tag Sub-TLV When a router distributes IP prefix information of the customer or host network, it can carry the tag of that network in the Administrative Tag Sub-TLV. When a router receives IP prefix information, it checks if there is a locally configured interface with the same tag as the Administrative Tag information carried in the prefix. If such an interface exists, SAVNET rules will be added, with the prefix being the received prefix and the interface being the locally configured interface with this tag. As shown in Figure 2, assume Network N is assigned tag n, meaning tag n is configured on both router A's interface # and router B's interface #. In the prefix information of 10.1.0.0/16 published by Router A, tag n is carried via the Administrative Tag Sub-TLV. Similarly, in the prefix information of 10.0.0.0/16 published by Router B, tag n is carried via the Administrative Tag Sub-TLV. When Router A receives the prefix information of 10.0.0.0/16, it checks that the carried tag n matches the tag on interface #, and since interface # connects to Network N, Router A determines that prefix 10.0.0.0/16 also belongs to Network N.. Similarly, Router B determines that prefix 10.1.0.0/16 also belongs to Network N using the same process. 5.1.1. Administrative Tag Sub-TLV of IS-IS For routers running IS-IS, they can carry the tag in the Administrative Tag Sub-TLV (defined in [RFC5130]), which can be included in: SRv6 Locator TLV (27), IPv4 Algorithm Prefix Reachability TLV (126), IPv6 Algorithm Prefix Reachability (127), Extended IP Reachability TLV (135), Multi-Topology Reachable IPv4 Li, et al. Expires April 28, 2025 [Page 9] Internet-Draft IGP-SAVNET October 2024 Prefixes TLV (235), IPv6 Reachability TLV (236), Multi-Topology Reachable IPv6 Prefixes TLV (237). 5.1.2. Administrative Tag Sub-TLV of OSPF For routers running OSPF, they can carry the tag in the Administrative Tag Sub-TLV [I-D.ietf-lsr-ospf-admin-tags] within the OSPF Extended Prefix TLV Sub-TLV [RFC7684]. 5.1.3. Administrative Tag Sub-TLV of OSPFv3 For routers running OSPFv3, they can include the tag in the Administrative Tag Sub-TLV [I-D.ietf-lsr-ospf-admin-tags] within the OSPFv3 Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External- Prefix TLV [RFC8362]. 5.1.4. Considerations of using Administrative Tag Sub-TLV In practice, intra-domain routers may also use the Administrative Tag Sub-TLV for other purposes (e.g., route filtering), and multiple Administrative Tag Sub-TLVs may be carried in the IP prefix information simultaneously. Therefore, using the existing Administrative Tag Sub-TLV for SAV-specific information communication may conflict with other routing policies that also use Administrative Tags as filtering criteria. To address this issue, this document proposes Approach #2 in the following. 5.2. Approach #2: Defining a new SAVNET Tag Sub-TLV To avoid possible conflicts and facilitate operation and management, it is more recommended to define and use a dedicated SAVNET Tag Sub- TLV to tranmit SAV-specific information. 5.2.1. SAVNET Tag Sub-TLV of IS-IS Figure 4 shows the structure of SAVNET Tag Sub-TLV of IS-IS. It can be included in the following TLVs: SRv6 Locator TLV (27), IPv4 Algorithm Prefix Reachability TLV (126), IPv6 Algorithm Prefix Reachability (127), Extended IP Reachability TLV (135), Multi- Topology Reachable IPv4 Prefixes TLV (235), IPv6 Reachability TLV (236), Multi-Topology Reachable IPv6 Prefixes TLV (237). 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAVNET Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Li, et al. Expires April 28, 2025 [Page 10] Internet-Draft IGP-SAVNET October 2024 Type: A 8-bit field set to TBD. Length: 4 octets. SAVNET Tag: The tag of the customer or host network. Figure 4: SAVNET Tag Sub-TLV of IS-IS 5.2.2. SAVNET Tag Sub-TLV of OSPF and OSPFv3 Figure 5 shows the structure of SAVNET Tag Sub-TLV of OSPF and OSPFv3.The SAVNET Tag Sub-TLV of OSPF specified herein will be valid as a sub-TLV of the following TLVs specified in [RFC7684]: 1. Extended Prefix TLV advertised in the OSPFv2 Extended Prefix LSA. The SAVNET Tag Sub-TLV of OSPFv3 specified herein will be valid as a sub-TLV of the following TLVs specified in [RFC8362]: 1. Inter-Area-Prefix TLV advertised in the E-Inter-Area-Prefix-LSA. 2. Intra-Area-Prefix TLV advertised in the E-Intra-Area-Prefix-LSA. 3. External-Prefix TLV advertised in the E-AS-External-LSA and the E-NSSA-LSA. 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 | Sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAVNET Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: A 16-bit field set to TBD. Length: 4 octets. SAVNET Tag: The tag of the customer or host network. Figure 5: SAVNET Tag Sub-TLV of OSPF and OSPFv3 6. Security Considerations The security considerations described in Li, et al. Expires April 28, 2025 [Page 11] Internet-Draft IGP-SAVNET October 2024 [I-D.ietf-savnet-intra-domain-problem-statement] and [I-D.ietf-savnet-intra-domain-architecture] also applies to this document. 7. IANA Considerations This document adds the following new sub-TLV to the "IS-IS Sub-TLVs for TLVs Advertising Prefix Information" registry. +------+---------------------+--+---+---+----+----+----+---+ | Type | Description |27|126|127| 135| 235| 236|237| +======+=====================+======+===+====+====+====+===+ | TBA | SAVNET Tag Sub-TLV |y | y | y | y | y | y | y | +------+---------------------+--+---+---+----+----+----+---+ The following values should be allocated from the OSPFv2 Extended Prefix TLV Sub-TLV Registry [RFC7684]: * TBD - 32-bit SAVNET Tag TLV The following values should be allocated from the OSPFv3 Extended- LSA Sub-TLV Registry [RFC8362]: * TBD - 32-bit SAVNET Tag TLV 8. References 8.1. Normative References [I-D.ietf-savnet-intra-domain-problem-statement] Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source Address Validation in Intra-domain Networks Gap Analysis,Problem Statement, and Requirements", Work in Progress,Internet- Draft, draft-ietf-savnet-intra-domain-problem-statement- 03, 13 February 2024, . [I-D.ietf-savnet-intra-domain-architecture] Li, D., Wu, J., Qin, L., Geng, N., and L. Chen, "Intra-domain Source Address Validation (SAVNET) Architecture", Work in Progress, Internet-Draft, draft-ietf-savnet-intra-domain- architecture-00, 12 April 2024, . Li, et al. Expires April 28, 2025 [Page 12] Internet-Draft IGP-SAVNET October 2024 [I-D.ietf-lsr-ospf-admin-tags] Lindem, A., Psenak, P., and Y. Qu, "Extensions to OSPF for Advertising Prefix Administrative Tags", Work in Progress,Internet-Draft, draft-ietf-lsr- ospf-admin-tags-19, 3 June 2024, . [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy Control Mechanism in IS-IS Using Administrative Tags",RFC 5130, DOI 10.17487/RFC5130, February 2008, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . Li, et al. Expires April 28, 2025 [Page 13] Internet-Draft IGP-SAVNET October 2024 Authors' Addresses Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Lancheng Qin Zhongguancun Laboratory Beijing China Email: qinlc@mail.zgclab.edu.cn Xueyan Song ZTE Corporation Nanjing China Email: song.xueyan2@zte.com.cn Changwang Lin New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com Shengnan Yue China Mobile Beijing China Email: yueshengnan@chinamobile.com Li, et al. Expires April 28, 2025 [Page 14]