PIM T. Eckert, Ed. Internet-Draft Futurewei Technologies USA Intended status: Experimental Y. Liu Expires: 7 January 2026 China Mobile 6 July 2025 The IPv6 Multicast Routing Headers (MRH) draft-eckert-pim-mrh-00 Abstract This document describes the IPv6 extensions to support an experiment in which new IPv6 Routing headers that support stateless replication are implemented and deployed for IPv6 Segment Routing Networks. Collectively, these headers are called Multicast Routing Header (MRH). One purpose of this experiment is to demonstrate that the MRH can be implemented and deployed in a production network. Another purpose is to encourage replication of the experiment. 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 7 January 2026. Copyright Notice Copyright (c) 2025 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 Eckert & Liu Expires 7 January 2026 [Page 1] Internet-Draft mrh July 2025 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Multicast Routing Header (MRH) . . . . . . . . . . . . . 3 3. MRH nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. MRH sub-type semantics . . . . . . . . . . . . . . . . . . . 6 4.1. Destination class MRH sub-type . . . . . . . . . . . . . 6 4.2. Steering class MRH sub-type . . . . . . . . . . . . . . . 6 5. MRH Packet processing . . . . . . . . . . . . . . . . . . . . 6 5.1. On Transit Nodes . . . . . . . . . . . . . . . . . . . . 6 5.2. On the MRH source node . . . . . . . . . . . . . . . . . 7 5.3. On Segment endpoint nodes . . . . . . . . . . . . . . . . 8 6. MRH sub-types . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. MRH-bitstring-destination (MRH-bd) Sub-Type format . . . 10 6.2. MRH-steering (MRH-s) Sub-Type format . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Longer MRH headers . . . . . . . . . . . . . . . . . 13 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Overview This document introduces IPv6 Routing headers that enable stateless replication of packets in IPv6 or SRv6 networks. These headers are collectively called Multicast Routing Headers (MRH). IPv6 Packets using these Routing headers can be IPv6 multicast packets or IPv6 (unicast) packets. When they are multicast packets, these mechanism can enable to avoid stateful multicast tree building protocols, such as PIM-SM, [RFC7761]. When they are unicast packets that need to be sent to more than one receiver, this mechanism allows to avoid either sender-side replication of these packets or the use of IPv6 multicast to achieve the replication. The mechanisms in this document are specifically targeted for SRv6 networks where stateless forwarding through ingres node steering of packets via SRH ([RFC8754])) already establishes a network preference to minimize the amount of state required in networks and/or the desire or need for advanced traffic steering, both of which is also possible for stateless replicated packets through the mechanisms in this memo. Eckert & Liu Expires 7 January 2026 [Page 2] Internet-Draft mrh July 2025 This document intends to support an experiment in which these new IPv6 Routing headers are implemented and deployed for IPv6 Segment Routing Networks or IPv6 network withoutt he desire for other forwarding planes. One purpose of this experiment is to demonstrate that the MRH can be implemented and deployed in a production network. Another purpose is to encourage replication of the experiment. This document only specifies the Routing headers and their semantics. The larger context of the experiment is (informationally) described in [I-D.eckert-pim-mrh-experiment]. This document is intended for 6MAN which is authoritative for IPv6 extension headers, but it is initially directed at review in PIM which is responsible for the overall experiment as the Multicast Routing expert group, including Multicast for Segment Routing/SRv6. 2. The Multicast Routing Header (MRH) The MRH header contains the following fields: * Next Header - Defined in [RFC8200]. * Hdr Ext Len - Defined in [RFC8200]. * Routing Type - Defined in [RFC8200]. Each MRH sub-type is allocated a new Routing Type by IANA. * Segments Left - Defined in [RFC8200]. * Type-specific Data - Described in [RFC8200]. In the MRH, the Type-specific Data field contains the elements as shown in Figure 1. Eckert & Liu Expires 7 January 2026 [Page 3] Internet-Draft mrh July 2025 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type |X| TLV offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MSER-Segment (128 bit IPv6 address) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MRH Sub-Type specific data | ... ... // ... // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // // Optional Type Length Value (TLV) objects (variable) // // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: MRH format The "MSER-Segment" ("Multicast Source Exit Router Segment") carries an IPv6 address. If it is an IPv6 address according to [RFC4291], then the packet is an IPv6 multicast packet. If the MSER-Segment is not an IPv6 address, then it is a SID according to [RFC8986], and the packet is called a stateless, directed replication, SRv6 (unicast) packet. MRH Sub-Type specific data contains a compressed encoding of SIDs that permits replication to a set of one or more destination SR nodes. Its encoding is determined by the MRH Sub-Type indicated by the Routing Type field. The data contained in MSER-Segment does not allow to determine on every Segment endpoint node a calculation of the actual number of segments left, nor would this value be useful. For this reasons, the MRH header field does not include a "Segments Left" field, but that space is instead used to indicate the offset to the optional TLV objects field in 32 bit units. This also makes it necessary for the MRH Sub-Type field to be multiple of 32 bit units in length - or be padded accordingly. If no TLV objects field is present, the value of TLV offset points to the first byte after the end of the MRH header. Note that the definition of TLV offset makes it never zero, which is necessary so that routers not supporting MRH extension headers will stop processing the packet and raise an ICMPv6 error according to [RFC8200], section 4.4. Eckert & Liu Expires 7 January 2026 [Page 4] Internet-Draft mrh July 2025 The X Flag is for future extensions, see Appendix A. It MUST be set to 0 Packets received with X set to 1 MUST, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized Routing Type. The length of the MRH Sub-Type may change during processing. TLV offset then needs to be updated accordingly. MTU discovery is not used for multicast packets and MRH headers are intended for use in controlled networks, so change in header size is something that can be managed. For example by never sending packets with more than the minimum MTU of 1280 as recommended for multicast packets in [RFC3542] and accordingly setting the MTU in the controlled network so the largest possible headersizes plus 1280 will fit. The Optional Type Length Value (TLV) objects field is as defined in [RFC8754]. As specified there, its length may change. Except for the aforementioned fixed value of the Segments left field, routing and forwarding for packets with an MRH routing extension header follows the rules of [RFC8200] as restated and refined by the following definitions. 3. MRH nodes There are different types of nodes that may be involved in MRH segment routing networks: * Source nodes: originate packets with an MRH segment address in the destination address of the IPv6 header * Transit nodes: forward packets destined to a remote MRH segment * Segment endpoint nodes: process a local segment in the destination address of an IPv6 header. * Egress nodes: a subset of the Segment endpoint node that act as IPv6/IPv6-Multicast host to the packet, passing it up to the next header protocol of the packet Note that SRv6 in [RFC8754] does not explicitly name egress nodes, although every SRH packet has exactly one such Egress node too. This document simply adds that additional terminology for convenience reasons. All other node types have exactly the same specification as in [RFC8754]. Eckert & Liu Expires 7 January 2026 [Page 5] Internet-Draft mrh July 2025 4. MRH sub-type semantics All MRH sub-types operate on the semantic that a packet is forwarded and replicated across a directed tree rooted in the source node of the MRH packet. All edges of the tree are segments, each vertex of the tree is a segment endpoint node. All leaves and a subset of the non-leaf are egress nodes, operating as IPv6 hosts processing the next header protocol of the packet. 4.1. Destination class MRH sub-type In a "destination" class MRH sub-type, the MRH sub-type specific data encodes only a list of egress node SIDs. All leaves of the tree are egress nodes. Non-egress edges/nodes of the tree are determined by forwarding/replication on segment endpoint nodes. Each segment endpoint node determines next segment endpoint nodes to replicate the packet to in order to reach the subset of egress nodes for the subtree rooted in this node. This is the replication mechanism used for example in [RFC8279]. 4.2. Steering class MRH sub-type In a "steering" class MRH sub-type, the MRH sub-type specific data encodes the complete directed tree with its segment endpoint nodes. Each non-leaf segment endpoint node determines the next segment endpoint nodes to which to replicate the packet to directly from the MRH sub-type specific data without having to examine the encoded tree beyond those next-hops. This is the replication mechanism used for example in [RFC9262]. In a "steering" class MRH sub-type, the non-leaf nodes of the tree are pre-determined by the MRH sub-type data and delivery of the packet to that node can thus be granted. Therefore, the actual property of a node being an egress node does not need to be encoded in the MRH sub-type but can instead be derived from membership of that node in the packets IPv6 multicast and/or future MSER segment SID semantic. This allows for more compact encoding of MRH sub-type data in this case because it eliminates the need to distinguish between a non-leaf segment endpoint node of the tree to be an egress node or not. 5. MRH Packet processing 5.1. On Transit Nodes Processing of MRH extension headers is as specified in [RFC8754], Section 4.2. with respect to [RFC8200] forwarding of IPv6 packets. Eckert & Liu Expires 7 January 2026 [Page 6] Internet-Draft mrh July 2025 However, additional packet processing in the forwarding plane that operate on IPv6 multicast packets for functions beyond those of IPv6 (unicast) packet forwarding MAY perform the same operation on an IPv6 packet with an MRH extension header which is an IPv6 multicast packet because its MSER-Segment contains an IPv6 multicast group address. In this case, the IPv6 multicast related function is performed as if the IPv6 multicast group address in the MSER-Segment was present in the IPv6 DA field of the packet, ignoring the IPv6 (unicast) Segment endpoint address in the IPv6 DA field, which is irrelevant to the IPv6 multicast semantic of the packet. Examples of such functions are statistics gathering of IPv6 multicast packets for IPFIX, attachment of QoS policies to the packet or "ACL" filtering of packet including firewall functions or filtering of scoped IPv6 multicast addresses ([RFC7346]). 5.2. On the MRH source node * A source node steers a packet into an MRH/SR policy that translates into one or more of the following set of data elements, each one required for one copy of the packet. - An MSR sub-type header representing in a compressed form a set of Egress node SIDs (destination sub-type) or a tree of segment endoint node SIDs with optional Egress nodes (steering sub- type) - An IPv6 source address belonging to the source node, which may be a SID, or which may need to be associated with semantics of the MSR sub-type header or the packet. For example, for an IPv6 multicast SSM packet as in[RFC3306], [RFC3569], the SA needs to be set according to the desired (S,G) channel. - An IPv6 destination address, which may be an IPv6 multicast group address (G) or a SID to be processed by all Egress nodes. - TLV (including HMAC). - Optionally an IPv6 destination address for the first Segment endpoint node. The MRH/SR policy needs more than one data element sets and hence packet copies when the desired list of egress nodes und/or representation of the tree of segment endpoint does not fit into a single MRH header. Eckert & Liu Expires 7 January 2026 [Page 7] Internet-Draft mrh July 2025 * The source node sets the IPv6 header and MRH extension header as follows - The SA of the packet is set to the IPv6 source address - The MSER-segment is set to the IPv6 destination address. - The Next Header and Hdr Ext Len fields are set as specified in [RFC8200]. The Routing Type field is set to the value assigned for the MSR sub-type. - The MSR sub-type header is inserted into its field. The Segments left field is set to the length of the MSR sub-type header plus 32 bits in units of 32 bits. - If the SR policy includes a first Segment endpoint node IPv6 address, then the packets DA is set to that address, and the packet is sent to it. - If the SR policy does not include such an IPv6 address, the packets DA is logically left unset and the packet is passed to the nodes MRH Segment endpoint processing steps. 5.3. On Segment endpoint nodes This document requires/uses only a single SRv6 SID for the reception of IPv6 packets with MRH type routing extension header. This SID can also be used for other purposes if the node can distinguish the semantic based on the routing header it contains - aka: for packets without an MRH type routing extension header. * If local processing requires TLV processing, perform TLV processing as described in in [RFC8754]. * Determine if this node is an egress node for the packet as follows. - If the MRH sub-type data explicitly encodes this node as an egress node. - If the node has membership for the IPv6 address in the MSER segment field. This can be the case when it is an IPv6 ASM multicast group that this node has joined to, or if the node has subscribed to the IP6 SSM channel indicated by (SA,MSER- segment), or if the MSER-segment indicates a non multicast SID that the node is subscribed to. The rules for subscription to non multicast SID are outside the scope of this document. Eckert & Liu Expires 7 January 2026 [Page 8] Internet-Draft mrh July 2025 * If the node is egress node for the packet, create a copy of the packet for which to proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. * Reduce the Hop-Count of the packet by 1. * If the hop count is <= 1, determine from the MSER segment SID whether ICMPv6 processing is desired. - If the MSER segment SID is IPv6 multicast, no ICMPv6 processing is desired. - Otherwise, the desire for ICMPv6 processing is defined by the SID. - If ICMPv6 processing is desired, Send an ICMP Time Exceeded -- Hop Limit Exceeded in Transit message to the Source Address - discard the packet, stop processing * Determine from the MRH sub-type data a list of 0 or more next-hop segments of the tree and perform the following processing for each of those next-hop segments - Create a copy of the packet - Change the DA of the packet to the Segment Endpoint SID for that next-hop node. - Rewrite the MRH sub-type data according to the processing rule of that MRH sub-type. Typically, in a destination MRH sub-type this consists in eliminating from the encoded Egress nodes set those that are not reachable via this next-hop segment, and for a steering MRH sub-type in adjusting offset pointers in the MRH sub-type data to point to the subtree rooted in the next-hop node. * Discard packet, terminate processing 6. MRH sub-types Eckert & Liu Expires 7 January 2026 [Page 9] Internet-Draft mrh July 2025 6.1. MRH-bitstring-destination (MRH-bd) Sub-Type format MRH-bd uses the packet forwarding data structures (BIFT) and forwarding rules of [RFC8279]. IPv6 packets with MRH-sd extension header are an [RFC8279] compliant encapsulation to support BIER architecture ([RFC8279] packet forwarding, and it uses all forwarding rules unmodified. [RFC8296] encapsulation is not used. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SD | SI |OAM| Entropy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitString (first 32 bits) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ BitString (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MRH-bd Sub-Type format Figure 2 shows the field of the MRH Sub-type specific data for the MRH * SD is the sub-domain as specified in [RFC8279] * SI is the Set Identifier as specified in [RFC8279] * Entropy is as specified in [RFC8279]. * BitString is as specified in [RFC8279]. * OAM is for future use with OAM procedures. The length of the BitString MUST be a multiple of 32 bits. It SHOULD be one of thefollowing value for compatibility with potentially pre- existing {RFC8279}} forwarding hardware: 64, 128, 256, 512, 1024, (2048, 4096) Nodes supporting MRH-sd MUST support a BSL of 256 bits. Note that the length of 2048 and 4096 are not possible in an MRH extension header due to the 255 byte size limit of IPv6 extension headers. See Appendix A. Eckert & Liu Expires 7 January 2026 [Page 10] Internet-Draft mrh July 2025 Population of the [RFC8279], section 6.4 forwarding tables (BIFT) is outside the scope of this specification. For the purpose of performing the rewriting of the IPv6 DA on Segment endpoint nodes, the BFR-NBR in the BIFT needs to be the MRH-sd SID of the next-hop MRH-sd node. 6.2. MRH-steering (MRH-s) Sub-Type format This sub-type is TBD. There are currently multiple competing proposals considered, including RTS ([I-D.eckert-pim-rts-forwarding] and [I-D.liu-pim-msr6-encapsulation-and-forwarding]. It should be noted, that [RFC9262] will explicitly not be considered, because that work was focussed on re-using the [RFC8279] forwarding plane as much as possible, and this lead to a lot of management and scalability issues which would make experimentation not with it not very useful. [RFC8279] can work fine in smaller scale deployments (networks and/or size of trees), but the purpose of this experiment is also to find better solutions for future hardware forwarding engines. 7. References 7.1. Normative References [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, August 2002, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, DOI 10.17487/RFC7346, August 2014, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, . Eckert & Liu Expires 7 January 2026 [Page 11] Internet-Draft mrh July 2025 [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, . [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, . 7.2. Informative References [I-D.eckert-pim-mrh-experiment] Eckert, T. T., "Proposal for experimentation with stateless IPv6 multicast source routing in IPv6-only SRv6 networks via new IPv6 Multicast Routing Headers (MRH)", Work in Progress, Internet-Draft, draft-eckert-pim-mrh- experiment-00, 3 March 2025, . [I-D.eckert-pim-rts-forwarding] Eckert, T. T., Menth, M., Lindner, S., and Y. Liu, "Stateless Multicast Replication with Segment Routed Recursive Tree Structures (RTS)", Work in Progress, Internet-Draft, draft-eckert-pim-rts-forwarding-03, 6 July 2025, . [I-D.liu-pim-msr6-encapsulation-and-forwarding] Liu, Y., Geng, X., and C. Lin, "Encapsulation and Forwarding Process for IPv6 Multicast Source Routing (MSR6) Data Plane", Work in Progress, Internet-Draft, draft-liu-pim-msr6-encapsulation-and-forwarding-01, 24 April 2025, . [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003, . [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 2003, . Eckert & Liu Expires 7 January 2026 [Page 12] Internet-Draft mrh July 2025 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, . [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non- MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018, . [RFC9262] Eckert, T., Ed., Menth, M., and G. Cauchie, "Tree Engineering for Bit Index Explicit Replication (BIER-TE)", RFC 9262, DOI 10.17487/RFC9262, October 2022, . Appendix A. Longer MRH headers Currently, IPv6 extension headers can only be up to 255 byte in size. It is also perceived common understanding that high-speed IPv6 routers, which are also targeted by this memo can not well support lookup into packets of more than 512 bytes, and that examining a long header may reduce packet throughput performance. For example, an [RFC8279] Bitstring has to be completely examined by a router, so longer Bitstrings run into this problem. However, with segment tree encoding in MRH sub-types, a single Segment endpoint nodes does not need to examine the whole header anymore, but only a consecutive smaller part of a potentially much larger header. Likewise, if each node removes its part of the MRH sub-type data for the copy sent to the next-hop node, then each node will also have its part of the header start near the start of MRH header, thus no look deep into the packet is necessary. Likewise, router forwarding engines become like general purpose CPU, the less problematic larger offsets into packet memory will be an issue, but only the total amoun of processing needed to be done on the memory accessed. Finally, is it worth to have a larger header instead of sending multiple packets ? Yes, for multicast packets it is. Consider that a 1024 byte long extension header could address for example 4 times as many destinations as a 256 byte extension header, so the bandwidth use near the source of the packet is significantly reduced by as much as a factor of 4. Eckert & Liu Expires 7 January 2026 [Page 13] Internet-Draft mrh July 2025 One possible option would be to use the X field in the MRH header to indicate that the Hdr Ext Len indicates the length of the extension header in 32 or 64 bits. Appendix B. Changelog 00: initial version. Authors' Addresses Toerless Eckert (editor) Futurewei Technologies USA United States of America Email: tte@cs.fau.de Yisong Liu China Mobile China Email: liuyisong@chinamobile.com Eckert & Liu Expires 7 January 2026 [Page 14]