Network Working Group J. Dai INTERNET-DRAFT CICT and PCL Intended Status: standard S. Yu Expires: December 28, 2024 PCL X. Wang Fiberhome D. Deng Fiberhome June 28, 2024 Protocol extension and mechanism for fused service function chain draft-dai-sfc-fused-protocol-and-procedure-03 Abstract This document discusses the protocol extension and procedure that are used to implement the fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane and control plane. Fused service function chain is a extension for service function chain. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Dai, et al. Expires December 28, 2024 [Page 1] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of the Architecture of Fused Service Function Chain. . 3 3 Protocol Extention for Network Service Header . . . . . . . . 5 3.1. The original formation of Network Service Header . . . . . 5 3.2. Extension for NSH . . . . . . . . . . . . . . . . . . . . 6 3.3. SPI in NSH . . . . . . . . . . . . . . . . . . . . . . . . 6 4 Additional Requirements for Fused Service Function Chain. . . . 7 4.1 Candidate solutions for information exchanging . . . . . . 7 4.2 Central controller based solution . . . . . . . . . . . 7 4.3 BGP based solution . . . . . . . . . . . . . . . . . . 8 5. Actions for SFC components. . . . . . . . . . . . . . . . . . 8 6. Transport layer envelopment for F-SFC . . . . . . . . . . . . 10 7. Some candidate mechanisms appropriate for fusing member SFCs . 10 7.1 Overview of fusing member SFCs . . . . . . . . . . . . . . 10 7.2 VPN . . . . . . . . . . . . . . . . . . . . . . . . 10 7.3 NVO3 . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Extension for management/control plane . . . . . . . . . . . . 12 9 Security Considerations . . . . . . . . . . . . . . . . . . . 12 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 12 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1 Normative References . . . . . . . . . . . . . . . . . . 13 12.2 Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction The delivery of end-to-end services often requires various service functions. These include traditional network service functions such as firewalls and traditional IP Network Address Translators (NATs), Dai, et al. Expires December 28, 2024 [Page 2] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 as well as application-specific functions. The definition and instantiation of an ordered set of service functions and subsequent "steering" of traffic through them is termed Service Function Chaining (SFC).[RFC7665]. [RFC7498] describes the motive for service function chain. o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . +--------------+ +------------------~~~ . | Service | SFC | Service +---+ +---+ . |Classification| Encapsulation | Function |sf1|...|sfn| +---->| Function |+---------------->| Path +---+ +---+ . +--------------+ +------------------~~~ . SFC-enabled Domain o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 1: Architecture of service function chain There are many application scenarios that can use technologies or methods related to service function chain (see RFC 7665). However, some application scenarios have not yet been covered by RFC 7665. For example, RFC 8459 illustrates an application scenario corresponding to large, geographically dispersed network and SFC for that application scenario is called Hierarchical service function chain. Hierarchical service function chain described in RFC 8459 is only one of the application scenarios that have not been covered by RFC 7665. Many other application scenarios that can be enhanced by service function chain can't yet be covered by RFC 8459. I_D_fused- architecture-and-scenario has illustrated some of the afore-mentioned. application scenarios. However, in order to carry out the fused service function chain, extension for the relevant protocol and new methods or procedure are necessary, and it is the target of this draft. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Overview of the Architecture of Fused Service Function Chain As is described in clause 1, there is a need to fuse two or more service fucntion chain to form a single service chain when service Dai, et al. Expires December 28, 2024 [Page 3] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 function chain is applied in some application scenarios. the afore- mentioned single service function chain is called fused service function chain (F-SFC). The detailed description about arthitecture for fused service function chain can be seen in [I-D.ietf-sfc-arch -fused-sfc].The following is brief introdution for the afore-mentioned architecture. At first, a F-SFC is composed of two or more service function chains that are logically independent each other and possibly seperate physically. Secondly, a F-SFC can be thought as a single service function chain from the view of data plane and management plane. That is to say, data packet can be steered through all selected SFs within the F-SFC according to preset configuration. moreover, a F-SFC can be managed by a management entity and the management entity can think the F-SFC as an ordinary service function chain. Thirdly, all service function chains within a F-SFC can still work as an independent service function chain. In other words, if a F-SFC consists of SFC A, SFC B and SFC C, SFCs with the F-SFC such as SFC A can also be used as an independent if it is needed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . +--------------+ +---------------------~~~ . | Service | SFC | Service +----+ +----+ . |Classification| Encapsulation| Function |sf11|...|sf1n| +--->| Function |+------------>| Path +----+ +----+ . +--------------+ +---------------------~~~ . . . +--------------+ +---------------------~~~ . | Service | SFC | Service +----+ +----+ . |Classification| Encapsulation| Function |sf21|...|sf2m| +--->| Function |+-----^------>| Path +----+ +----+ |. +--------------+ | +---------------------~~~ | Bypass | +------------------------+ +--->...... . +--------------+ +---------------------~~~ . | Service | SFC | Service +----+ +----+ . |Classification| Encapsulation| Function |sfk1|...|sfkl| +--->| Function |+-----^------>| Path +----+ +----+ |. +--------------+ | +---------------------~~~ | Bypass | +------------------------+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2: General architecture for fused service function chain Dai, et al. Expires December 28, 2024 [Page 4] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 Figure 2 describes a general architecture of F-SFC. From the figure, it can be learned that the F-SFC is composed of SFC1, SFC2 ... and SFCj. SFC1 consists SF11, SF12 ... and SF1n. SFC2 consists SF21, SF22 ... and SF2m. ... SFCk consists SFk1, SFk2 ... and SFkl. This figure can also be seen in [I-D.ietf-sfc-arch-fused-sfc]. All SFs within SFC1, SFC2 ... and SFCj can be used by F-SFC. On the one hand, SFs within SFC(i+1) should be used after SFs within SFC(i) in order to keep the logical order of SFCs. On the other hand, SFs within the same SFC should take action based on logical order of the SFC. It is noted that all CFs (Classification Function) in SFC2 ... SFCk can be configurated to work in By-pass mode in order that SFC2 ... SFCk can action based on the result of the CF in SFC1. It is sure all CFs can also work in normal mode. 3 Protocol Extention for Network Service Header 3.1 The original formation of Network Service Header [RFC 8300] specifies the detailed information of Network Service Header (NSH). A typical NSH is composed of the following three parts: Base Header: Provides information about the service header and the payload protocol. Service Path Header: Provides path identification and location within a service path. Context Header: Carries metadata (i.e., context data) along a service path. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path Identifier | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Context Header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: structure for Network Service Header Dai, et al. Expires December 28, 2024 [Page 5] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 Figure 2 describes the formation of the NSH. The first Row is used to describe 'Base Header' meanwhie the second row is used to specify 'Service Path Header'. The third row is 'Context Header'. There five bits marked 'U' in the Base Header of NSH are not defined in [RFC 8300]. 3.2 Extension for NSH At first, in order to carry out a fused service function chain, a certain mechanism should be used to tell components within a SFC whether the packet is bound to a common SFC or a fused SFC. Because all inforamtion related to a SFC is enveloped in the NSH, some modification should be taken on the NSH when it is needed to classify packets of a Fused SFC from packets of a common SFC. There are the following two solutions to implement the afore- mentioned classification funciton: .Using one of the five unused bits as the F-SFC bit, and the bit is defined as follows: 0: the packet is related to a common SFC. 1: the packet is related to a fused SFC. .Encoding 'Service Path Identifier'. some numbers are used for F-SFC meanwhile other numbers are used to represent common SFCs. For example, the packet is bound to a F-SFC when the most significant bit of 'Service Path Identifier' is set, and the other packets are related to a common SFC. It is recommended that the first solution should be used to classify the packets of a F-SFC from the packets of a common SFC. And the third bit of the 'Base Header ' is recommended to be used. 3.3 SPI in NSH When a packet related to a F-SFC is sent out from the classifier of the first SFC that belongs to the F-SFC, a NSH will be inserted into the packet and the SPI is related to the F-SFC rather than a common SFC within the F-SFC. A common SFC in the F-SFC is called a member SFC of the F-SFC. Dai, et al. Expires December 28, 2024 [Page 6] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 On the other hand, every member SFC of the F-SFC also has a corresonding SPI and the SPI of the member SFC is different from SPI of the F-SFC. That will bring some problems to forwarding functions of the SFC components. Generally, within every member SFC of a F-SFC, the packet forwarding action is based on SPI of the member SFC, though the NSH of the forarded packet envelops the SPI of the F-SFC. So, it is needed that some mechnism to be used to realize the function to map from SPI of the F-SFC to SPI of the member SFC. The mapping mechanism of SPI is specified in clause 4. 4 Mapping of SPI 4.1 Candidate solutions for information exchanging If a functional component of SFC wants to map a SPI A to another SPI B, it needs to know the SPI pairs(for example, A and B is a SPI pair) in advance. Then, the functional component can map SPI A to SPI B or map SPI B to SPI A. There are two solutions for the functional component to get the informaton of SPI pairs: .Using one central controller to configurate the information about SPI pairs. .Exchange the information about SPI pairs among functional components based on BGP. 4.2 Central controller based solution When a central controller can exchange information with all functional components of the SFC that needs the information about the SPI paiirs, it is recommended to exchange information about SPI pairs based on the central controller. In this mode, the information of SPI pairs can be encoded with other configuarion information and sent to those relevant functional components. Dai, et al. Expires December 28, 2024 [Page 7] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 Many management protocol or mechanism such as SNMP and Netconf can be used to dispatch the configuration information. 4.3 BGP based solution When there is not a proper central controller that can configurate the SPI pairs to all functional components of the SFC that needs the information about the SPI paiirs, it is better to use the BGP based method to exchange information about SPI pairs. This section specifies how to use BGP extensions to exchange SPI pairs among functional components of the SFC. One feasible solution is using 'BGP Extended Communities Attribute' to envelop the inforamtion of SPI pairs. a new type of BGP extended community called SPI-Pairs Extended Community. It is a transitive extended community with type 0x01 and sub-type TBD. The format of this extended community is shown in Figure 3. 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 (0x01) |Sub-Type (TBD) | SPI of the F-SFC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | SPI of the current member SFC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI of the neighbouring member SFC | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. SPI-Pairs Extended Community 5. Actions for SFC components Because some changes occur to the protocol, the processing actions of the functional components become different from the common SFC. There are three aspects related to the afore-mentioned change of actions that need to be executed by the functional components. The following are those aspects. . SPI mapping: two kinds of mapping are as follows: . Mapping SPI of the F-SFC to SPI of a member SFC when a F-SFC packet enter the member SFC.(A10) Dai, et al. Expires December 28, 2024 [Page 8] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 . Mapping SPI of a member SFC to SPI of the F-SFC when a F-SFC packet leave the member SFC and will enter another member SFC.(A11). . F-SFC bit processing: . Clearing F-SFC bit when a F-SFC packet enter the member SFC. (A20) . Setting F-SFC bit when a F-SFC packet leave the member SFC and will enter another member SFC.(A11).(A21) . SI processing: . Re-initiate SI when a F-SFC packet enter the member SFC.(A30) . Restore and re-calculate SI when a F-SFC packet leave the member SFC and will enter another member SFC.(A31) . Decrementing the SI.(A32) . Restore and re-calculate SI when a F-SFC packet leave the member SFC and will enter another member SFC.(A31) . Decrementing the SI.(A32) Figure 4 illustrates the actions possibly executed by the functional components of the member SFC. +--------------------+----------------+-------------+---------------+ |Component | SPI processing | F-SFC bit | SI processing | | | | processing | | +--------------------+----------------+-------------+---------------+ |Classifier | A10 | A20 | A30 | +--------------------+----------------+-------------+---------------+ |Service Function | A10&A11 | A20&A21 | A30&A31 | |Forwarder (SFF) | | | | +--------------------+----------------+-------------+---------------+ |Service Function | - | - | A32 | | (SF) | | | | +--------------------+----------------+-------------+---------------+ | SFC Proxy | - | - | A30 | +--------------------+----------------+-------------+---------------+ Figure 4. Actions for SFC components related extended field for F-SFC Dai, et al. Expires December 28, 2024 [Page 9] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 6. Transport layer envelopment for F-SFC According to [RFC 8300], an outer transport encapsulation is used to forward the packet with a NSH header. And the service header is independent of the transport encapsulation used. Because F-SFC is usually applied in cross-domain scenarios, the outer transport layer envelopment should meet the requirement that the packet with the outer transport layer envelopment can be exchange among the domains in which the member SFCs are deployed. 7. Some candidate mechanisms appropriate for fusing member SFCs 7.1 Overview of fusing member SFCs For F-SFC, it is a critical issue to steering the packet from one member SFC to another member SFC. Because network traffic related to F-SFC needs to be forwarded domain by domain, problems including security will be brought about when network traffic is transported from a domain to another domain. Some mature technologies can help to steer network traffic domain by domain and avoid possible problems. the next two sections will introduce two candidate mechanisms that can be used for F-SFC. It is noted that the other feasible methods are also proper for F-SFC. 7.2 VPN VPN (Virtual Private Network ) is a good solution to connect different member SFCs when member SFCs are set up in different network domains. detailed information of VPN can be seen in [RFC 4110] and [RFC 4664]. For example, L2 VPN can provide two fundamentally different kinds of Layer 2 VPN service that a service provider could offer to a customer: . Virtual Private Wire Service (VPWS). . Virtual Private LAN Service (VPLS). A VPWS is a VPN service that supplies an L2 point-to-point service. Then A VPWS is appropriate for F-SFC. Dai, et al. Expires December 28, 2024 [Page 10] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 Figure 5 illustrate the scene that two member SFCs are connected by a VPN. ............ ...................... ............... . . . . . . . +---+ +-------+ +----+ +-------+ +---+ +----+ . . | | | | | | | |----|CF |-|SFF | . . | | | | | | | | +---+ +----+ . . +---+ |SFF|----| PE1 |--| P | -- | PE2 | : . . | CF|..| | | | | | | | +---+ . . +---+ | | | | | | | |----|SFF| . . +---+ +-------+ +----+ +-------+ +---+ . . Domain . . Service . . Domain . . 1 . . provider(s) . . 2 . ............ ..................... ................ Figure 5. VPN connects two member SFCs 7.3 NVO3 Another example for mechanisms that can be used to connect two independent member SFCs is NVO3. and Figure 6 illustartes such a scene. Detail description about NVO3 can be seen in [RFC 7365] and [RFC 8014]. ............ ................ ................ . . . . . . . . . . +---+ +---+ . . +---+ +---+ . . |CF |-|SFF| . . |CF |-| | +-+--+ . . +--+-+---+---+ +---+ . . +---+ |SFF|--- | NVE|--. L3 Overlay .--| NVE| . . . | | | | . . | | +---+ . . +---+ +-+--+ . Network . +--+-+---|SFF| . .Domain . . . +---+ Domain . . 1 . . . . 2 . ............ ................ ............... Figure 6. NVO3 connects two member SFCs Dai, et al. Expires December 28, 2024 [Page 11] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 8. Extension for management/control plane Functional components in a F-SFC are possibly deployed in different Domains, then multi-controllers are possibly needed, figure 7 depicts the logical structure for multi-controllers to cooperate in F-SFC context. There is possibly a need for information to be exchanged among the controllers. It is a feasible solution to use BGP extensions to realize the information exchange functions. +----------+ +---------------+ +------------+ | SFC | | Non SFC | | SFC | |Controller|.........| Controller |........|Controller | | 1 | | | | 2 | +----------+ +---------------+ +------------+ | | | ............ ..................... ............... . . . . . . . +---+ . . +----+ +----+ . . | | . . ----|CF |-|SFF | . . | | . Non SFC . +---+ +----+ . . +---+ |SFF|---- . . . . . | CF|..| | . . +---+ . . +---+ | | . Domain . ----|SFF| . . +---+ . . +---+ . . Domain . . . . Domain . . 1 . . . . 2 . ............ ..................... ............... Figure 7. logical structure for multi-controllers in F-SFC 9. Security Considerations The security considerations described throughout [RFC7665] and [RFC8300] apply here as well. Additionally, when a data packet is forwarded from SFC(i) to SFC(i+1), the path between SFC(i) to SFC(i+1) should provide mechanism to guarantee security of the data packet. Moreever, when the CF in SFC(i) is by-passed, it should be assured that the bu-passed path has the same security support as the CF. 10. IANA Considerations The IANA is requested to make the assignments for SPI-Pairs Extended Community: Dai, et al. Expires December 28, 2024 [Page 12] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 +-------+-------------------------------------------+---------------+ | Value | Description | Reference | +-------+-------------------------------------------+---------------+ | TBA1 | IPv4-Address-Specific IFIT Tail Community | This document | +-------+-------------------------------------------+---------------+ 11 Acknowledgements This document is written by referring to [RFC7665] authored by J. Halpern and C, Pignataro and [RFC8924] authored by S. Aldrin, C. Pignataro, N. Kumar, R. Krishnan and A. Ghanwani. Many thanks to all the afore-mentioned editors and authors. 12 References 12.1 Normative References [RFC4360] S. Sangli, D. Tappan and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC4760] T. Bates, R. Chandra, D. Katz and Y. Rekhter, "Multiprotocol Extensions for BGP-4 ", RFC 4760, Jenuary 2007. [RFC7665] J. Halpern and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, October 2015. [RFC8300] P. Quinn, U. Elzur and C. Pignataro, "Network Service Header (NSH)", RFC 8300, January 2018. [RFC8459] D. Dolson, S. Homma, D. Lopez and M. Boucadair "Hierarchical Service Function Chaining (hSFC)", RFC 8459, September 2018. [RFC8924] S. Aldrin, C. Pignataro, N. Kumar, R. Krishnan and A. Ghanwani, "Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework", RFC 8924, October 2020. 12.2 Informative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Dai, et al. Expires December 28, 2024 [Page 13] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005. [RFC4664] L. Andersson and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs) ", RFC 4664, September 2006. [RFC7365] M. Lasserre, T. Morin, N. Bitar and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization ", RFC 7365, October 2014. [RFC7498] P. Quinn and T. Nadeau, "Problem Statement for Service Function Chaining", RFC 7468, April 2015. [RFC8014] D. Black, J. Hudson, L. Kreeger, M. Lasserre and T. Narten, "An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3) ", RFC 8014, December 2016. [RFC8393] A. Farrel and J. Drake, "Operating the Network Service Header (NSH) with Next Protocol 'None'", RFC 8393, May 2018. [I-D.ietf-sfc-multi-layer-oam] G. Mirsky, W. Meng, B. Khasnabish and C. Wang, "Active OAM for Service Function Chains in Networks", draft-ietf-sfc-multi-layer-oam-07, December 2020. Authors' Addresses Jinyou Dai China Information Communication Technologies Group. Gaoxin 4th Road 6# Wuhan, Hubei 430079 China Email: djy@fiberhome.com Shaohua Yu Shaohua Yu PCL., Nanshan Shenzhen China Email: yush@cae.cn Dai, et al. Expires December 28, 2024 [Page 14] INTERNET DRAFT Protocol extension for fused SFC June 28, 2024 Xueshun Wang China Information Communication Technologies Group. Gaoxin 4th Road 6# Wuhan, Hubei 430079 China Email: xswang@fiberhome.com Dongping Deng China Information Communication Technologies Group. Gaoxin 4th Road 6# Wuhan, Hubei 430079 China Email: dzb@fiberhome.com Dai, et al. Expires December 28, 2024 [Page 15]