Network Working Group M. Zhang Internet-Draft H. Ding Intended status: Informational YL. Zhao Expires: April 21, 2011 BUPT HY. Zhang YB. Xu CATR October 18, 2010 Performance Metric of Convergence Time of Information Flooding in Multi- Domain GMPLS Networks draft-zhangm-ccamp-metric-00 Abstract To keep the information of topology and links resource synchronized at each control node, massive messages are necessary to be flooded in the control plane of General Multi-Protocol Label Switching (GMPLS) based multi-domain networks. The convergence time of information flooding will have a significant impact on the performance of the networks. So measuring and analyzing the convergence time of information flooding in multi-domains becomes very important. A performance metric of convergence time of information flooding is proposed to characterize the ability of information synchronization in multi-domain networks. 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 http://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 21, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang, et al. Expires April 21, 2011 [Page 1] Internet-Draft convergence time of information flooding October 2010 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 1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in this Document . . . . . . . . . . . . . . 4 3. Overview of the Performance metric . . . . . . . . . . . . . . 4 4. convergence time of information flooding in single domain . . 4 4.1. Initial convergence time of information flooding . . . . . 4 4.1.1. Definition . . . . . . . . . . . . . . . . . . . . . . 4 4.1.2. Methodology . . . . . . . . . . . . . . . . . . . . . 4 4.1.3. Sample . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. convergence time of information flooding with LSPs . . . . 6 4.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Methodology . . . . . . . . . . . . . . . . . . . . . 6 4.2.3. Sample . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Convergence time of information flooding in multi-domain networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Initial convergence time of information flooding . . . . . 8 5.1.1. Definition . . . . . . . . . . . . . . . . . . . . . . 8 5.1.2. Methodology . . . . . . . . . . . . . . . . . . . . . 8 5.1.3. Sample . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Convergence time of information flooding with LSPs . . . . 10 5.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 10 5.2.2. Methodology . . . . . . . . . . . . . . . . . . . . . 11 5.2.3. Sample . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Protocol Extension Requirements . . . . . . . . . . . . . . . 14 6.1. OSPF-TE Extension Requirements . . . . . . . . . . . . . . 14 6.2. RSVP-TE Extension Requirements . . . . . . . . . . . . . . 14 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. author . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Zhang, et al. Expires April 21, 2011 [Page 2] Internet-Draft convergence time of information flooding October 2010 1. Introduction Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945], which can handle multiple switching technologies: packet switching (PSC), Layer 2 switching (L2SC), Time-Division Multiplexing (TDM) Switching, wavelength switching (LSC) and fiber switching (FSC), is a key technology for transport and service network. As the network varies from time to time, division of the network is a natural solution to cope with large scale network control and management. In order to keep the information of topology and links resource synchronized, which is necessary during the process of path computation, massive messages are necessary to be flooded in the control plane of multi- domain networks. So measuring and analyzing the convergence time of information flooding in multi-domain networks becomes very important. RFC 5814 has defined three metric to characterize the dynamic Label Switching Path (LSP) provisioning performance of signaling protocol. However, performance metric that concerns routing protocols, especially in multi-domain network are not specified in previous documents. In this document, we define a performance metric of convergence time of information flooding from the routing aspect to characterize the ability of information synchronization in multi-domain networks. The metric can be used to measure convergence time of information flooding in single domain, multi-domains, initial and with LSPs. Methodologies and samples of the testing procedure for different scenarios are also included in the following sections. 1.1. Motivations Convergence time of information flooding is useful for several reasons. o When a large scale network is deployed, a series of tests are to be conducted to evaluate the network performance, such as adding or deleting the clients, establishing or tearing the connections, and so on. The convergence time, which indicates the ability to synchronize the topology and link resource states, is also worth measuring and analyzing meantime, since it can further illustrate the reasonability of domain division. o During the operation, nodes or links failures MAY cause congestion due to both resource unavailability and a large amount of information flooding. Measuring and monitoring convergence time of information flooding is helpful for network failure detection. o After network updating and large scale reconfiguration, convergence time of information flooding should be measured, Zhang, et al. Expires April 21, 2011 [Page 3] Internet-Draft convergence time of information flooding October 2010 because it MAY reflect the reasonability of this updating by comparing the convergence time of information flooding with the LSP setup delay. 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 [RFC2119]. 3. Overview of the Performance metric To evaluate the convergence ability of a GMPLS-based network from routing aspect, we define a performance metric of convergence time of information flooding. The following sections specify the metric in different situations, initial or with LSPs, in single domain or multi-domains. The initial convergence time of information flooding measures the time that one network spends from its power-on to its full operation. The convergence time with LSPs measures the time needed to synchronize the information after several changes in link resource states. The convergence time in single domain is intra- domain time whereas the convergence time in multi-domains comprises intra-domain time and inter-domain time and the two kinds of convergence time need to compute separately. The convergence time of information flooding is either a real number of milliseconds or undefined. And in methodology "undefined" convergence time is defined. 4. convergence time of information flooding in single domain 4.1. Initial convergence time of information flooding 4.1.1. Definition The initial convergence time of information flooding describes a period of time, which starts at the moment when the first bit of the first Hello packet is sent and ends at the moment when all nodes database synchronized in this domain. 4.1.2. Methodology Generally, the convergence time of initial information flooding in single domain proceeds as follows, Zhang, et al. Expires April 21, 2011 [Page 4] Internet-Draft convergence time of information flooding October 2010 o All control nodes in this domain switch on normally; o Store a time structure, which records the first sending moment of Hello packets, in every control node. And the starting point (T1) of the convergence time is the earliest sending moment among all control nodes in this domain; o After the neighbor relationships are established, Database Description (DD) packets are sent and received to synchronize the information topology and links resource according to RFC 2328. Then all nodes in the domain are marked as full adjacency. Store a time structure, which records the latest receiving moment of DD packets, in every node. Choose the latest moment among all control nodes as end point (T2); o Initial convergence time of information flooding in single domain can be computed by subtracting the starting point from end point (T2-T1). 4.1.3. Sample . . . . . . . . . . . . . . . . . +-----+ +-----+ +-----+ . . |NODE1|--|NODE2|--|NODE3| . . +-----+ +-----+ +-----+ . . | / . . +-----+/ +-----+ . . |NODE4|-----|NODE5| . . +-----+ +-----+ . . . . domain . . . . . . . . . . . . . . . . . Figure 1: Initial information synchronization in single domain Control nodes are represented by vertices and physical links are represented by dashed lines. When all these control nodes switch on normally and their interfaces first become operational, Hello packets are flooded in this domain to establish neighbor relationships as described in Section 7, RFC1583. For a domain as shown in Figure 1, after the power-on, all five nodes begin to send and receive Hello packets. In most occasions, these nodes receive the message in a very short interval which is normally a few microseconds. So practically a structure of time is stored in every node to record the moment, which is the time when the node sends a Hello packet. The starting point of the initial convergence Zhang, et al. Expires April 21, 2011 [Page 5] Internet-Draft convergence time of information flooding October 2010 time of information flooding is the earliest sending moment of all the Hello packets. After the establishment of neighbor relationships, DD packets are sent and received to compare the nodes database so as to establish adjacency relationships. And the receiving moments of DD packets SHOULD be stored in another time structure in every node. Then choose the latest moment among all the receiving moments relating to DD packets as the end point of the convergence time of information flooding in this scenario. So the initial convergence time of information flooding in single domain can be computed by subtracting the starting point from the end point. 4.2. convergence time of information flooding with LSPs 4.2.1. Definition The convergence time of information flooding with LSPs describes a time period, that starts at the moment when the ingress node sends the first bit of a Link State Update (LSU) packet and ends at the moment when the last node in this domain receives the LSU packet. The undefined convergence time of information flooding with LSPs means ingress node fails to receive corresponding ResvConf message, which MAY indicates resource reservation failure or nodes breaking down along the LSP. 4.2.2. Methodology Generally, the methodology proceeds as follows, o All control nodes in this domain switch on normally; o Initial information synchronization is complete, which means all node Link State Database (LSDBs) are up-to-date; o Select an ingress node ID0 and an egress node ID1, and create a LSP path from ID0 to ID1. o Wait until ID0 receives the corresponding ResvConf message and updates its LSDB and forms a LSU packet LSU0. Store a timestamp (T1) at ID0 as soon as possible; o Another timestamp (T2) SHOULD be stored when the last node within this domain receives LSU0 at the exact last node; Zhang, et al. Expires April 21, 2011 [Page 6] Internet-Draft convergence time of information flooding October 2010 o The convergence time of information flooding with LSPs in single domain can be computed by subtracting the two timestamps (T2-T1); o If ID0 fails to receive the corresponding ResvConf message in a reasonable period of time, the convergence time is set to undefined. 4.2.3. Sample . . . . . . . . . . . . . . . . . +-----+ +-----+ +-----+ . . |NODE1|==|NODE2|==|NODE3| . . +-----+ +-----+ +-----+ . . || / . . +-----+/ +-----+ . . |NODE4|=====|NODE5| . . +-----+ +-----+ . . . . domain . . . . . . . . . . . . . . . . .} Figure 2: Convergence time of information flooding with LSPs in single domain Control nodes are represented by vertices and physical links are represented by dashed lines, LSPs are represented by equal signs. For a single domain as shown in Figure 2, NODE1->NODE2->NODE3 constitute LSP1 which already exists, and NODE1->NODE4->NODE5 constitute LSP2 which need to be measured. When NODE1, the ingress node of LSP2, receives a ResvConf message correspondingly with LSP2, it forms an LSU packet including changed LSAs and floods it within the domain. NODE2 and NODE4 receive the LSU and then NODE3 and NODE5 receive the message. A time structure is stored in every control node to record the earliest sending moment and latest receiving moment of LSU packets. The ingress node NODE1's sending moment can be the starting point and choose the latest moment among NODE2's, NODE3's, NODE4's, NODE5's receiving moments as the end point of the convergence time. So the convergence time of information flooding with LSPs in single domain as depicted in Figure 2 can be computed by subtracting the starting point from the end point. Zhang, et al. Expires April 21, 2011 [Page 7] Internet-Draft convergence time of information flooding October 2010 5. Convergence time of information flooding in multi-domain networks 5.1. Initial convergence time of information flooding 5.1.1. Definition Initial convergence time of information flooding in multi-domain network defines a time period, which starts at the moment when the first Hello packet is sent and ends at the moment when all nodes database synchronized in the network. 5.1.2. Methodology Generally, convergence time of information flooding in multi-domain network proceeds as follows, o All control nodes in multi-domains switch on normally; o Store a time structure, which records the first sending moment of Hello packets in every control node. And the starting point (T1) of the convergence time is the earliest sending moment among all control nodes in the multi-domain network; o After the neighbor relationships are established, Database Description (DD) packets are sent and received to synchronize the information topology and links resource according to RFC 2328. Then all nodes in the domain are marked as full adjacency. Store a time structure, which records latest receiving moment of DD packets, in every node. Choose the latest moment among all these structures as another timestamp (T2); o Initial convergence time of information flooding in the multi- domain network can be computed by subtracting the two timestamps (T2-T1). Zhang, et al. Expires April 21, 2011 [Page 8] Internet-Draft convergence time of information flooding October 2010 5.1.3. Sample . . . . . . . . . . . . . . . . . +-----+ +-----+ +-----+ . . |NODE1|--|NODE2|--|NODE3| . . +-----+ +-----+ +-----+ . . | / | . . +-----+/ +-----+ | . . |NODE4|-----|NODE5| | . . +-----+ +-----+ | . . | . . Domain1 | . . . . . . . . . . . .+-----+. . |NODE6| +-----+ | +-----+ |NODE7| . . . . . . . . . . .+-----+. . . | . . +-----+ +-----+ . . |NODE8|------------|NODE9| . . +-----+ +-----+ . . | . .Domain2 +------+ . . ---------------|NODE10| . . | +------+ . . +------+. . . . . . . . . . . |NODE11| +------+ | +------+ |NODE12| . +------+. . . . . . . . . . . . | . . +------+ +------+ . . |NODE14|-----|NODE15| . . +------+ +------+ . . \ | . . +------+ . . |NODE13| Domain3 . . +------+ . . . . . . . . . . . . . . . . . Figure 3: Initial convergence time of information flooding in multi- domain networks Zhang, et al. Expires April 21, 2011 [Page 9] Internet-Draft convergence time of information flooding October 2010 Control nodes are represented by vertices and physical links are represented by dashed lines. Border nodes NODE6, NODE7, NODE11 and NODE12 connect Domain1, Domain2 and Domain3. When all these nodes switch on normally and their interfaces first become operational, Hello packets are flooded in the multi-domain network to establish neighbor relationships. For the three domains in the network as depicted in Figure 3, all these nodes are switched on more or less simultaneously, so store the same time structure in every node is necessary to record the first sending moment of Hello packets. The earliest sending moment is the starting point of the convergence time. After the establishment of neighbor relationships, DD packets are sent and received to compare the nodes database so as to establish adjacency relationships. And the receiving moments of DD packets SHOULD be stored in another time structure in every node. Then choose the latest moment among all receiving moments relating to DD packets as the end point of the convergence time of information flooding in this scenario. So the initial convergence time of information flooding in the multi- domain network can be computed by subtracting the starting point from the end point. 5.2. Convergence time of information flooding with LSPs 5.2.1. Definition Convergence time of information flooding with LSPs in multi-domain networks comprises two parts: intra-domain convergence time of information flooding and inter-domain convergence time of information flooding. While intra-domain convergence time of information flooding is further divided into several single domain convergence time of information flooding according to the domains the cross- domain-LSP traversed through. And inter-domain convergence time of information flooding refers to a time period during which the domain border nodes synchronize their information according to RFC1583. Every single domain convergence time of information flooding can refer to section 4.2. Note that for source domain the convergence time starts at the moment when the LSP ingress node updates its information. Otherwise, for intermediate domains, as well as destination domain, the convergence time starts at the moment when the ingress node of that domain updates its information with respect to the LSP. All the convergence time end with the last node!_s receipt of the updating information. Zhang, et al. Expires April 21, 2011 [Page 10] Internet-Draft convergence time of information flooding October 2010 Setting the convergence time of information flooding with LSPs as undefined means the ingress node fails to receive the corresponding ResvConf message, which MAY indicate resource reservation failures or nodes breaking down along the cross-domain LSP. 5.2.2. Methodology The procedure of convergence time of information flooding in multi- domain network, as mentioned above, comprises two parts: intra-domain convergence time of information flooding and inter-domain convergence time of information flooding. Methodology for convergence time of information flooding in single domain has been specified in Section 4.2.2; and the methodology for inter-domain convergence time of information flooding proceeds as follows, o All control nodes in all domains switch on normally; o Initial information synchronization is complete, which means all nodes!_ LSDB are up-to-date; o Select an ingress node ID0 and an egress node ID1 in a different domain, and create a cross-domain LSP from ID0 to ID1; o Wait until ID0 receives all the corresponding ResvConf messages that confirm the completion of resource reservation, ID0 updates its LSDB and forms a LSU packet LSU0. Store a timestamp (T1) at ID0 as soon as the LSU packet is sent; o Then the source domain border node receives the LSU packet and summarizes the source domain information into an advertisement. Then the border node distributes the advertisement to backbone area. Store a timestamp (T2) at the border node as soon as the advertisement is distributed; o Another timestamp (T3) SHOULD be stored locally as soon as the border node in destination domain receives an advertisement from backbone area; o Inter-domain convergence time of information flooding can be computed by subtracting two timestamps (T3-T2); o The convergence time of information flooding of the network can also be computed by subtracting two timestamps (T3-T1); o If ID0 fails to receive the corresponding ResvConf message in a reasonable period of time, the inter-domain convergence time of information flooding is set to undefined. Zhang, et al. Expires April 21, 2011 [Page 11] Internet-Draft convergence time of information flooding October 2010 5.2.3. Sample . . . . . . . . . . . . . . . . . +-----+ +-----+ +-----+ . . |NODE1|--|NODE2|==|NODE3| . . +-----+ +-----+ +-----+ . . | / || . . +-----+/ +-----+ || . . |NODE4|-----|NODE5| || . . +-----+ +-----+ || . . || . . Domain1 || . . . . . . . . . . . .+-----+. . |NODE6| +-----+ || +-----+ |NODE7| . . . . . . . . . . .+-----+. . . || . . +-----+ +-----+ . . |NODE8|------------|NODE9| . . +-----+ +-----+ . . || . .Domain2 +------+ . . ===============|NODE10| . . || +------+ . . +------+. . . . . . . . . . . |NODE11| +------+ || +------+ |NODE12| . +------+. . . . . . . . . . . . || . . +------+ +------+ . . |NODE14|=====|NODE15| . . +------+ +------+ . . \ | . . +------+ . . |NODE13| Domain3 . . +------+ . . . . . . . . . . . . . . . . . Figure 4: Convergence time of information flooding with LSPs in multi-domain networks Zhang, et al. Expires April 21, 2011 [Page 12] Internet-Draft convergence time of information flooding October 2010 Control nodes are represented by vertices and physical links are represented by dashed lines and LSPs are represented by equal signs. Border nodes are NODE6, NODE7, NODE11 and NODE12 which connect Domain1, Domain2 and Domain3, as shown in Figure 4. The cross-domain LSP is NODE2->NODE3->NODE6->NODE7->NODE9->NODE10->NO DE11->NODE12->NODE14->NODE15. When ResvConf message is received from every node along this LSP, meaning the resource reservation is complete, LSAs flooding begins from the source domain, Domain1. NODE2 sends out a LSU packet LSU1 which contains link states changes in Domain1, and LSU1 is then flooded in Domain1. When Domain1's border node NODE6 receives LSU1, it not only updates its own database but also forms an inter-domain LSU packet LSU12 summarizing Domain1's states changes and sends it to Domain2's border node NODE7. As ingress node of partial LSP in Domain2, NODE7 also sends out a LSU packet LSU2 which includes link states changes in Domain2 and then LSU2 is flooded in Domain2. Similarly, NODE11 forms an inter-domain LSU packet LSU 23 and sends it to NODE12. NODE12, as ingress node of partial LSP in Domain3, forms LSU3 which is then flooded in Domain3. LSU1, LSU2 and LSU3 are intra-domain LSU packets while LSU12, LSU23 are inter-domain LSU packets. Time structures are stored in every node along the sending and receiving of LSU packets. Moments related to different LSU packets are recorded in different time structures. Intra-domain convergence time of information flooding in Domain1 can be computed by subtracting the end point, which can be obtain by choosing the latest receiving moment in Domain1, from NODE2s sending moment. Similarly, the starting point and end point of the intra- domain convergence time of information flooding in Domain2 are NODE7s LSU2 sending moment and the latest receiving moment among NODE8, NODE9, NODE10 and NODE11. For Domain3 the starting point and end point are NODE11s LSU3 sending moment and the latest receiving moment among NODE12, NODE13, NODE14 and NODE15. Inter-domain convergence time of information flooding reflects the time required to synchronize information among border nodes: NODE6, NODE7, NODE11 and NODE12. So the starting point is NODE6s LSU12 sending moment while the endpoint is the latest inter-domain LSU packets receiving moment. By subtracting the two moments, inter- domain convergence time of information flooding for Domain1, Domain2 and Domain3 is computed. Note that in Figure 4, there is only one entrance border node and one exit border node between two domains. As for Domain1, NODE6 is the only exit node, so the starting point of inter-domain convergence time of information flooding is the moment Zhang, et al. Expires April 21, 2011 [Page 13] Internet-Draft convergence time of information flooding October 2010 when NODE6 sends LSU12. In the topology where there are more than one exit nodes in the source domain, the starting moment will be the earliest LSU12 sending moments among the exit border nodes. The convergence time of information flooding in the network can be computed by subtracting the following two moments, one is the NODE2s sending moment in Domain1, the other is the latest LSU23 receiving moment. 6. Protocol Extension Requirements 6.1. OSPF-TE Extension Requirements The measurement procedure of the initial convergence time of information flooding requires the extensions in OSPF-TE protocol. During the procedure, sending and receiving moments of Hello packets and DD packets need to be recorded. Corresponding timestamps are needed to symbolize the sending and receiving of Hello packets and DD packets in every node. 6.2. RSVP-TE Extension Requirements 7. Discussion The following issues are likely to come up in practice. o The accuracy of convergence time of information flooding depends largely on the clock resolution in every node, where time structures are stored; so synchronization among all nodes in the network is crucial. o Whether a convergence time of information flooding is a real number or undefined largely depends on the choosing of the reasonable waiting time before the ResvConf is received. However, choosing the waiting time is complicated. If the time is set too short, there will be too much "undefined" convergence time and the result does not reflect the network performance properly. However, if the time is set too long, time is wasted waiting when there are resource reservation failures or breaking down nodes. Choose the appropriate waiting time is also depending on the network status, if the network is light loaded, the waiting time can be set shorter than it is set when the network is heavy loaded. Zhang, et al. Expires April 21, 2011 [Page 14] Internet-Draft convergence time of information flooding October 2010 8. Security Considerations 9. Acknowledgement We wish to thank Shengwei Meng, and Koubo Wu in the Key Laboratory of Information Photonics and Optical Communications (BUPT), Ministry of Education, for their valuable comments. We also wish to thank the support from National 863 program. 10. Normative References [RFC1583] Moy, J., "OSPF Version 2", March 1994. [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", September 2003. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", October 2004. [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", February 2008. [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", February 2008. Appendix A. author Jie Zhang Beijing University of Post and Telecommunication No.10,Xitucheng Road,Haidian District Beijing 100876 Zhang, et al. Expires April 21, 2011 [Page 15] Internet-Draft convergence time of information flooding October 2010 China Phone: +8613911060930 Email: lgr24@bupt.edu.cn Authors' Addresses Min Zhang Beijing University of Post and Telecommunication No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613910621756 Email: mzhang@bupt.edu.cn Hui Ding Beijing University of Post and Telecommunication No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613426082796 Email: dinghui.ei@gmail.com Yongli Zhao Beijing University of Post and Telecommunication No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613811761857 Email: yufengx386@gmail.com Haiyi Zhang China Academy of Telecommunication Research, MIIT, China. No.52 Hua Yuan Bei Lu,Haidian District Beijing 100083 P.R.China Phone: +861062300100 Email: zhanghaiyi@mail.ritt.com.cn Zhang, et al. Expires April 21, 2011 [Page 16] Internet-Draft convergence time of information flooding October 2010 Yunbin Xu China Academy of Telecommunication Research, MIIT, China. No.52 Hua Yuan Bei Lu,Haidian District Beijing 100083 P.R.China Phone: +8613681485428 Email: xuyunbin@mail.ritt.com.cn Zhang, et al. Expires April 21, 2011 [Page 17]