[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

INTERNET-DRAFT                                                    J. Lan
Intended Status: Experimental                                      Y. Hu
Expires: April 12, 2018                                          G. Cheng
                                                                 P. Wang
                                                                 L. Tian
                                                                 T. Duan
                                                         NDSC P.R. China
                                                         October 12, 2017


                  Service Function Path Establishment
                     draft-lan-sfp-establishment-04


Abstract

   Service Function Chain architecture leads to more adaptive network
   nodes. It allows splitting the network function into fine-grained
   build blocks --- service function, and combining the network
   functions into service function chain to formulate complicated
   services. Further, the service function chain should be instantiated
   by selecting the optimal instance from the candidates for each
   service function in it. This document discusses the required
   components during the instantiation of service function chain in the
   network.


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





Lan, et al              Expires April 12, 2018                   [Page 1]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


Copyright and License Notice

   Copyright (c) 2014 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
   (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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
   3.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  3
     3.1.  The Terminology  . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  Acronyms and Abbreviations . . . . . . . . . . . . . . . .  4
   4.  Core components for SFP  . . . . . . . . . . . . . . . . . . .  5
     4.1.  Framework  . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  SIB structure  . . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  TIB structure  . . . . . . . . . . . . . . . . . . . . . .  7
   5.  SFP management . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  SFP establishment  . . . . . . . . . . . . . . . . . . . .  9
     5.2.  SFP deletion . . . . . . . . . . . . . . . . . . . . . . . 11
     5.3.  SFP update . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15













Lan, et al              Expires April 12, 2018                   [Page 2]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


1.  Introduction

   The end-to-end services delivery often present various demands for
   different functions including the traditional functions and
   diversified novel ones such as application-specific features.
   However, the rigidly fixed model of service function in the legacy
   network chain lacks in adaptability for that circumstance. It cannot
   fulfill the current various requirements of end users or
   applications, such as cross layer in the wireless network.

   Accordingly, service function chain is provided to enhance the
   network flexibility and adaptability. It consists of several service
   functions in a special order that the corresponding packets or flows
   should drill through them. The network administrative entity could
   "insert" or "disable" a service function in the service function
   chain based on the new dynamic demands.

   Service function chain architecture splits the network functions into
   finer-grained service functions. It then decouples the service
   functions from the underlying physical topology, and enables the new
   placement and combination of service functions viable. In the SFC-
   enabled domain, many service function instances will co-exist
   provided by different vendors. Before SFC deploys to delivery packets
   or flows, it must be instantiated by selecting instances distributed
   in the network for each service functions.

   This document outlines the required components regarding to the
   service function path including the establishment, deletion,
   modification/update based on the policy.


2.  Conventions used in this document

   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].


3.  Terminology and Abbreviations

3.1.  The Terminology
   This document uses the terminology defined in the SFC Problem
   Statement [I-D.quinn-sfc-problem-statement] and the SFC Framework &
   Architecture [I-D.boucadair-sfc-framework]. Additional terminology is
   defined below:

   Service Function Instance: A Service Function Instance locating in a
   service node deals with the specific packets based on the function



Lan, et al              Expires April 12, 2018                   [Page 3]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


   logic declared.

   Service Function Path: The Service Function Path is the instantiation
   of a service function chain in the network. It consists of the
   service function instances in the service function chain.

   Service Information Base: A Service Information Base is a data
   structure tracking the information about the service functions. It
   must include the location of service functions, service type (e.g.,
   load balancer, firewall), and managed information such as the load,
   capacity and current status of service function. SIBs may be
   configured and managed by the administrative entity that operates the
   SFC-enabled domain. SIBs also may be automatically updated by the
   service function discover. In the distributed mode, SIB's replicas
   could be distributed over the SFC-enabled domain.

   Topology Information Base: A Topology Information Base stores the
   Physical network infrastructure topology. Its replicas can be placed
   in the same network node with SIB, or in a separate one. In the
   distributed mode, TIB's replicas could be distributed over the SFC-
   enabled domain.

   SFP-enabled Management Entity: SFP-enabled Management Entity is
   responsible for the establishment, deletion, modification/update of
   SFPs for various SFC.

3.2.  Acronyms and Abbreviations

      SFI               Service Function Instance
      SFP               Service Function Path
      SIB               Service Information Base
      TIB               Topology Information Base
      SFP-ME            SFP-enabled Management Entity
      SFPS              Service Function Pre-Selection
      SFPC              Service Function Path Calculation
      SCPB              Service Chain-Path Base















Lan, et al              Expires April 12, 2018                   [Page 4]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


4.  Core components for SFP

      The establishment of a SFP which consists of multiple service
      functions (SFs), needs to select one service function instance
      (SFI) from multiple SFIs distributed in the network for each
      service function. To make decision, service function (SF) node
      information and underlying topology information need to be
      collected automatically and periodily. The following sections
      describe the framework and data structures to store SF information
      and topology information for the establishment of SFP.
4.1.  Framework


                  policy      +----------------------------------------+
                     |        |    +-------+   +-------+     +-------+ |
                     |        |    |       |   |       |     |       | |
                     |        |--->| SF1_1 |-->| SF1_2 | ... | SF1_n | |
                     |        |    |       |   |       |     |       | |
                     V        |    +-------+   +-------+     +-------+ |
                 +-------+    |                                        |
                 |       |    |                                        |
             +-->|  PDP  |--->|                                        |
             |   |       |    |    +-------+   +-------+     +-------+ |
             |   +-------+    |    |       |   |       |     |       | |
             |                |--->| SF2_1 |-->| SF2_2 | ... | SF2_m | |
 +-------+   |                |    |       |   |       |     |       | |
 |       |   |                |    +-------+   +-------+     +-------+ |
 |  NIB  |-->|                +--------+-----------+-------------+-----+
 |       |   |                         |           |             |
 +-------+   |                         |           |             |
             |   +-------+    +----------------------------------------+
             |   |       |    |              +-----------+     +-----+ |
             |-->|SFP-ME |--->|  +-------+   |    SN2    |     | SNi | |
             |   |       |    |  |  SN1  |-->+-----------+     +-----+ |
 +-------+   |   +-------+    |  +-------+   |SF1_2 SF1_3| ... |SF1_n| |
 |       |   |                |  | SF1_1 |   +-----------+     +-----+ |
 |  TIB  |---+                |  | SF2_1 |-->+-----------+     +-----+ |
 |       |                    |  +-------+   |    SN2    | ... | SNk | |
 +-------+                    |              +-----------+     +-----+ |
                              |              |   SF2_2   |     |SF2_m| |
                              |              +-----------+     +-----+ |
                              +----------------------------------------+
                                       physical infrastructure

             Figure 1 Core components for SFP establishment

   As shown in figure 1, the core components of SFP include PDP, SFP-ME,
   SF information base (SIB), and topology information base (TIB). As



Lan, et al              Expires April 12, 2018                   [Page 5]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


   defined in [I.D- boucadair-sfc-framework], the PDP is the central
   entity which is responsible for maintaining SFC policy Tables, and
   enforcing appropriate policies in SF nodes and SFC Boundary Nodes. In
   addition, the PDP in this document is also responsible for creating
   SFCs according to the requirements of applications or profits of
   vendors. The SIB stores the SF information which includes SF
   identity, SF locator, SF type, SF capacity, SF load and SF status. SF
   information can be collected from SFC-enabled domain by using IGP or
   BGP-LS [I.D-draft-idr-ls-distribution]. The TIB is used to store
   underlying physical network infrastructure topology information which
   can be collected form network by using IGP or BGP-LS [I.D-draft-idr-
   ls-distribution]. The SFP-ME is responsible for establishing,
   deleting, and modified SFP according to SFC made by PDP, SF
   information, and topology information. The SFP-ME is also responsible
   for SFP management.
4.2.  SIB structure

   The SF information stored by SIB is used to establish or update SFP
   by SFP-ME. The SIB structure is defined in Fig.2. The following
   entries are defined in the SIB.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Index|SF identity|SF locator|SF type|SF capacity|SF load|SF status|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 2 SIB structure


   Index: denotes the sequence that a SF entry locates in the SIB. The
   index can be used to lookup the SF entry quickly.

   SF identity: is used to identify the SF and is unique in SFP-ME
   enabled domain. Each SF has an unique identity. The service function
   server is responsible for the SF identity management and allocation.

   SF locator: represents the SF node where the SF locates. The SF
   locator is non-exclusive. Multiple SFs could locate in one SF node or
   multiple different SF nodes.

   SF type: denotes the type of a SF. SFs can be classified into
   different classes which include firewall, DPI (Deep Packet
   Inspection), load balancer, etc. The definition of SF can refer to
   [I.D- boucadair-sfc-framework]. In this document, the SFs may be
   service functions in layer 3 or service functions in layer 4-7.

   SF capacity: represents the capacity to process the traffic. The same
   service function may have multiple service functions in different
   capacities.



Lan, et al              Expires April 12, 2018                   [Page 6]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


   SF load: denotes the current traffic load steering a SF. The SFP-ME
   can establish or update SFP according to SF load.

   SF status: denotes the current status of a SF. The SF status includes
   available, congestion, unavailable, etc. The exact definition of SF
   status is application-specific.

4.3.  TIB structure

   The underlying physical network topology information is used to
   deploy SFs for establishing or updating SFP according some optimal
   criterions or the profit of vendors. The TIB is used to store network
   topology information. The structure of TIB can be defined in
   different formats, e.g. routing information table etc. Fig. 3 shows a
   definition of the TIB structure. The following entries are defined in
   the TIB.

       +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+--+   +-+-+-+-+-+--+
       | SF node |  number | Neighbor 1 | Neighbor 1 |...| Neighbor N |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+--+   +-+-+-+-+-+--+

                         Figure 3 TIB structure

   SF node: denotes the SF node which reports the information. The
   identifier of SF node can be flat identifier or hierarchical
   identifier, e.g. IP address.

   Number: denotes the number of neighbor nodes.

   Neighbor: denotes the neighbor node of the current SF node. A SF node
   may have multiple neighbor nodes.


5.  SFP management

   SFP aims to provide SFC an optimal/near-optimal path on underlying
   physical network, ensuring network function represented by the
   specific SFC can be implemented with required or even higher
   performance. Operations of SPF refer to establishment, deletion and
   update and are conducted by SFP-ME.

   The SFP-ME in this document includes a service function pre-selection
   (SFPS), classifier, service function path calculation (SFPC) and
   service chain-path base (SCPB), as shown in Figure 4. The SFPS is
   used to select candidate nodes for SFP establishment. The classifier
   is used to determine which cost function is taken for SFP
   establishment and transfer SFP deletion and update information to
   SFPC. The SFPC is used to fulfill SFP establishment, deletion and



Lan, et al              Expires April 12, 2018                   [Page 7]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


   update. The SCPB stores service function chain-path mapping
   information and is used for SFP deletion.

   A service function path header should be added to encapsulated
   packets or frames to represent service function paths. The service
   function path header should be independent of the underlying
   transport and can be encapsulated inside any transport mechanism.
   There are several approaches to encapsulate service function path
   header as described in Metadata Considerations [I-D.rijsman-sfc-
   metadata-considerations], Service Chain Header [I-D.zhang-sfc-sch],
   Network Service Header[I-D.quinn-sfc-nsh] and so on.

   To implement SPF establishment, deletion and update, SFP-ME need to
   interact with NIB, TIB, PDP by using a variety of protocols, such as
   NETCONF [RFC6241],PCEP[I-D.wu-pce-traffic-steering-sfc], etc.




































Lan, et al              Expires April 12, 2018                   [Page 8]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


                                  +------------+
                                  |            |
                                  |    PDP     |
                                  |            |
                                  +-----+------+
                                        |
   +-----------+        +---------------|------------------------+
   |           |        |               |                        |
   |    NIB    <----+   |        +------+--------+               |
   |           |    |   |        |               |               |
   +-----------|    |   |    +---v---+     +-----v------+        |
                    |   |    |       |     |            |        |
                    +---+-+--> SNPS  |     | CLASSIFIER |        |
                    |   | |  |       |     |            |        |
   +-----------+    |   | |  +---v---+     +-----v------+        |
   |           |    |   | |      |               |               |
   |   TIB     <----+   | |      |               |               |
   |           |        | |      +------+--------+               |
   +---------- +        | |             |                        |
                        | |             |                        |
                        | |         +---V---+         +------+   |
                        | |         |       |         |      |   |
                        | +----- -->| SFPC  <-------- > SCPB |   |
                        |           |       |         |      |   |
                        |           +---+---+         +------+   |
                        |               |                        |
                        +---------------+------------------------+
                                        |
                                        V

                    Figure 4   Framework of SFP-ME

5.1.  SFP establishment

   SFP establishment refers to determining the optimal/near-optimal
   service node for each service function on SFC and finding the
   optimal/near-optimal path for the instantiated service nodes of a
   given SFC such that the required service functions are executed in
   sequence required by SFC with minimal costs.

   The term of cost is user-defined and can be end-to-end delay,
   resource consumption and so on. There may exist only one cost
   definition which can be applied to all SFC in the same domain, or may
   co-exist several different cost definitions with each one targeting
   at different types of SFC. Cost must be expressed as a function, i.e.
   cost function. Trying to minimize the cost, several algorithms can be
   applied based on different cases.




Lan, et al              Expires April 12, 2018                   [Page 9]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


   When SFC is generated based on policy in PDP, SFP-ME receives SFC
   information and start to execute SFP establishment. The SFP
   establishment processes in three steps, as shown in Figure 5.

   Firstly, SNPS selects several service nodes as candidates, these
   service nodes must include one or more service function Instance of
   the given SFC and are currently available. Concurrently, classifier
   selects the appropriate cost function according to the type of the
   given SFC, this step can be omitted if there is only one cost
   function applied to all SFC in the same domain.

   Secondly, with the aim to minimize cost, SFPC applies algorithms to
   selects one service node for each service function of the given SFC
   from the candidates and builds a path making the service functions
   strictly executed with the ordered sequence. Thus an optimal/near-
   optimal SFP for SFC is established.

   Lastly, Information of the established SFP is send to SFC entrance,
   meanwhile SCPB is updated.
































Lan, et al              Expires April 12, 2018                  [Page 10]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


                                  +------------+
                                  |            |
                                  |    PDP     |
                                  |            |
                                  +------------+
                                        |
                        +---------------|------------------------+
                        |               |                        |
                        |        +------+--------+               |
                        |        |  1            | 1             |
                        |    +---v---+     +-----v------+        |
                        |    |       |     |            |        |
                        |    | SNPS  |     | CLASSIFIER |        |
                        |    |       |     |            |        |
                        |    +-------+     +------------+        |
                        |       |                |               |
                        |       |                |               |
                        |       +------+---------+               |
                        |              | 2                       |
                        |              |                         |
                        |          +---V---+         +------+    |
                        |          |       |    3    |      |    |
                        |          | SFPC  |-------- > SCPB |    |
                        |          |       |         |      |    |
                        |          +---+---+         +------+    |
                        |              |                         |
                        +--------------+-------------------------+
                                       | 3
                                       V

                 Figure 5   SFP Establishment Process

5.2.  SFP deletion

   SFP deletion refers to releasing the overall service function
   Instantiations of the established SFP, thus the released service
   function Instantiations can be used for other SFP's establishment.

   SFP-ME starts to execute SFP deletion once PDP notifies that SFC has
   been deleted. Information of the to be deleted SFC is send to SFPC
   through classifier and match against the restored SFC in SCPB to find
   SFP for the given SFC, then SFPC notify SFC entrance that this
   specific SFP is invalid, meanwhile update SCPB.  The SFP deletion
   process is shown in Figure 6.







Lan, et al              Expires April 12, 2018                  [Page 11]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


                             +------------+
                             |            |
                             |    PDP     |
                             |            |
                             +------------+
                                   |
                        +----------+---------------------+
                        |          | 1                   |
                        |    +-----v------+              |
                        |    |            |              |
                        |    | CLASSIFIER |              |
                        |    |            |              |
                        |    +------------+              |
                        |          | 2                   |
                        |          |                     |
                        |      +---V---+       +------+  |
                        |      |       |   3   |      |  |
                        |      | SFPC  <------ > SCPB |  |
                        |      |       |       |      |  |
                        |      +---+---+       +------+  |
                        |          |                     |
                        +----------+---------------------+
                                   | 4
                                   V

                    Figure 6   SFP deletion process

5.3.  SFP update

   SFP update refers to changing partial service function Instantiations
    or path of the established SFP, due to breakdown of partial service
   function nodes or physical links.

   Breakdown of service function nodes or physical links can lead the
   established SFP to work improperly, re-establishment of SFP can be
   executed to guarantee function of the corresponding SFC is still
   implemented with optimal/near-optimal performance. SFP update is an
   alternative way. The updated SFP may perform worse than the re-
   establishment one, however, the update process takes up less time
   which can be very attractive to time-sensitive function.

   SFP-ME starts to execute SFP update once PDP notifies that SFP need
   to be updated. Information of the to be updated SFC is send to SFPC
   through classifier, SFPC selects adjacent service nodes or path to
   replace the ones which has been breakdown. Thus the given SFP is
   undated, Information of the undated SFP is send to SFC entrance. The
   SFP update process is shown in Figure 7.




Lan, et al              Expires April 12, 2018                  [Page 12]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


                             +------------+
                             |            |
                             |    PDP     |
                             |            |
                             +------------+
                                   |
                        +----------+-----------+
                        |          | 1         |
                        |    +-----v------+    |
                        |    |            |    |
                        |    | CLASSIFIER |    |
                        |    |            |    |
                        |    +------------+    |
                        |          | 2         |
                        |          |           |
                        |      +---V---+       |
                        |      |       |       |
                        |      | SFPC  |       |
                        |      |       |       |
                        |      +---+---+       |
                        |          |           |
                        +----------+-----------+
                                   | 3
                                   V

                     Figure 7   SFP update process

























Lan, et al              Expires April 12, 2018                  [Page 13]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


6.  Security Considerations

   It will be considered in a future revision.


7.  IANA Considerations

   No IANA action is needed for this document.


8.  References


8.1.  Normative References

   [RFC2753]  Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
              for Policy-based Admission Control", RFC 2753, January
              2000.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


8.2.  Informative References


   [I-D.quinn-sfc-problem-statement] Quinn, P., "Service Function
              Chaining Problem Statement", draft-quinn-sfc-problem-
              statement-02 (work in progress), December 2013.

   [I-D. boucadair-sfc-framework] M. Boucadair, "Service Function
              Chaining: Framework & Architecture",draft-boucadair-sfc-
              framework-02 (work in progress),February 2014.

   [I-D.rijsman-sfc-metadata-considerations] B. Rijsman, J. Moisand,
              "Metadata Considerations", draft-rijsman-sfc-metadata-
              considerations-00 (work in progress),February 2014.

   [I-D.zhang-sfc-sch] H. Zhang, L. Fourie, R. Parker, M. Zarny,
              "Service Chain Header", draft-zhang-sfc-sch-01  (work in
              progress), May 2014.

   [I-D.quinn-sfc-nsh] P. Quinn, J. Guichard, R. Fernando, S. Kumar, et
              al. "Network Service Header",draft-quinn-sfc-nsh-02 (work
              in progress), February 2014.

   [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.Bierman,
              "Network Configuration Protocol (NETCONF)", RFC 6241, June



Lan, et al              Expires April 12, 2018                  [Page 14]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


              2011.


Authors' Addresses


              Julong Lan
              National Digital Switching System Engineering and Technological
              Research Center
              NDSC
              Jianxue Ave. No. 7
              Zhengzhou  450002
              China

              EMail: ndscljl@163.com


              Yuxiang Hu
              National Digital Switching System Engineering and Technological
              Research Center
              NDSC
              Jianxue Ave. No. 7
              Zhengzhou  450002
              China

              EMail: chxachxa@126.com


              Guozhen Cheng
              National Digital Switching System Engineering and Technological
              Research Center
              NDSC
              Jianxue Ave. No. 7
              Zhengzhou  450002
              China

              EMail: chengguozhen1986@163.com


              Peng Wang
              National Digital Switching System Engineering and Technological
              Research Center
              NDSC
              Jianxue Ave. No. 7
              Zhengzhou  450002
              China

              EMail: wangpeng.ndsc@gmail.com



Lan, et al              Expires April 12, 2018                  [Page 15]


INTERNET DRAFT    Service Function Path Establishment     October 12, 2017


              Le Tian
              NDSC
              Jianxue Ave. No. 7
              Zhengzhou  450002
              China

              EMail: xxgctianle@163.com

              Tong Duan
              NDSC
              Jianxue Ave. No. 7
              Zhengzhou  450002
              China

              EMail: duantong21@126.com































Lan, et al              Expires April 12, 2018                  [Page 16]

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/