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]