Internet DRAFT - draft-huang-gmpls-recovery-resource-sharing
draft-huang-gmpls-recovery-resource-sharing
CCAMP Working Group Qing Huang (Editor)
Internet Draft G.S. Kuo (Editor)
Expiration Date: January 2005
July 2004
Generalized MPLS Recovery Resource Sharing
draft-huang-gmpls-recovery-resource-sharing-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC-2026].
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
Abstract
Many protection and restoration (P&R) techniques are proposed to
protect LSP in Generalized Multi-Protocol Label Switching (GMPLS)
networks. Provisioning better P&R capability requires that much
recovery resources be allocated on protection LSP, which may lead
to resource waste in GMPLS networks.
This draft presents a scheme of recovery resource sharing with
traffic balancing for GMPLS LSP based P&R. Its focus is on the
discussions of working and protection LSPs selection and the shared
resource allocation and release.
Internet Draft - Expires January 2005 [page 1]
draft-gmpls-recovery-resource-sharing-00.txt July 2004
Table of Contents
1. Introduction...................................................2
2. Notions........................................................3
3. Recovery Resource Sharing With Traffic Balancing...............4
4. Signaling Procedure............................................5
5. PROTECTION Object..............................................6
6. Resource Allocation and Release................................7
6.1 Resource Allocation............................................8
6.2 Resource Release...............................................8
6.3 Illustration of Resource Allocation and Release................9
7. Performance Evaluation........................................10
8. LSP Segment P&R...............................................10
9. Conclusions...................................................11
10. IANA Considerations...........................................11
11. Intellectual Property Considerations..........................11
12. References....................................................11
12.1 Normative References ........................................11
12.2 Informative References ......................................12
13. Authors' Addresses............................................12
Full Copyright Statement..........................................13
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].
In addition, the reader is assumed to be familiar with the
terminology used in [GMPLS-ARCH], [RFC-3471], [RFC-3473] and
referenced as well as [TERM] and [FUNCT].
1. Introduction
As the real-time and multimedia-oriented services are rapidly
increasing on Internet, a small link or node failure is unacceptable
to customers. Service continuity is becoming much more important
than before. P&R (see [TERM]) is the key technique to improve
service continuity by establishing protection path for working path.
Obviously, recovery resources reserved on protection path are idle
at most time, which is unreasonable from the viewpoint of resource
utilization.
An efficient way to improve recovery resource utilization is to have
protection LSPs, whose working LSPs are physically disjoint, share
bandwidth resources. This mechanism was coined as shared mesh
restoration and described in [GMPLS-ANAL]. Clearly, not all GMPLS
recovery mechanisms can provide shared mesh restoration. For
example, in the 1+1 protection mechanism, the traffic is transmitted
simultaneously on both the working and protection LSPs. The selector
at the egress will decide which path to use according to the quality
of signal. Obviously, no recovery resource can be shared in 1+1
protection, while other recovery mechanisms such as M:N recovery aim
to provision shared mesh restoration.
Internet Draft - Expires January 2005 [page 2]
draft-gmpls-recovery-resource-sharing-00.txt July 2004
To share the recovery resources can save bandwidth in networks,
thus, rejected session setup requests can be decreased in a certain
degree. Moreover, maximum recovery resource sharing with traffic
balancing can further decrease rejected session setup requests in
GMPLS networks. We will discuss the scheme to optimize recovery
resource sharing with traffic balancing and the signaling implement-
ation of the scheme.
Section 2 introduces the notions used in the draft. Section 3
describes the scheme to optimize recovery resource sharing with
traffic balancing. Section 4 provides the signaling implementation
of the scheme. Section 5 discusses resource allocation and release.
Section 6 evaluates the performance of the proposed scheme. Section
7 presents the application of the scheme in LSP segment P&R. And,
Section 8 concludes this draft.
2. Notions
We model arbitary GMPLS network as G=(V, E), where V is the set of
nodes and E is the set of all links in networks. A LSP is defined as
LSP={s, r1, ..., rn, d}, where s and d denote source and destination
nodes respectively, and rk denotes the k-th intermediate LSR along
the LSP. In addition, to identify a LSP in GMPLS networks, either a
global identifier (ID) or a triple <s, d, local_ID> must be used.
To simplify the presentation, the global identifier (ID) is used in
this draft. Furthermore, the following notations are defined:
l(i, j): The link from nodes i to j.
Cij: The cost of l(i, j).
Bij: Total amount of bandwidth reserved for protection LSPs on
l(i, j).
Rij: Total amount of residual bandwidth on l(i, j).
PLij: Set of protection LSPs that traverse l(i, j).
PLij={PLij[1], PLij[2], ..., PLij[N]}, where PLij[k] is
the ID of the k-th protection LSP and N is the total number
of protection LSPs on l(i, j).
WLij: Set of LSPs which are protected by l(i, j).
WLij={WLij[1], WLij[2], ..., WLij[N]}, where WLij[k] is
the ID of the LSP protected by PLij[k].
fij[k]: The bandwidth demand of PLij[k](WLij[k]).
t[k][m]: The bandwidth that PLij[k] shares with PLij[m]. So, the
actual recovery bandwidth allocated to PLij[k] is
fij[k] - sum {m=1}^N [tij[k][m]].
Sij[k]: Set of all links and intermediate nodes along WLij[k].
Internet Draft - Expires January 2005 [page 3]
draft-gmpls-recovery-resource-sharing-00.txt July 2004
Inf(Wlsp): Set of all links and intermediate nodes along Wlsp, where
Wlsp denotes the selected working LSP.
WT[i,j]: Weight of l(i, j) used in computing route.
In this draft, we assume node i is the dominating node of l(i, j),
that is, the information about PLij, WLij, fij[k], Sij[k] and
tij[k][m] are held in node i locally. Thus, PLij, WLij, fij[k],
Sij[k] and tij[k][m] can be refreshed on node i when any protection
LSP traversing l(i, j) is set up.
3. Recovery Resource Sharing With Traffic Balancing
In the proposed scheme, only information of Bij and Rij is required
for computing a route, that is, only Bij and Rij are flooded in
networks. The flooding of Bij and Rij can be easily implemented by
route protocol extensions OSPF [GMPLS-OSPF] / IS-IS [OSPF-ISIS] in
GMPLS. The current solutions for recovery resource sharing are the
two approaches mentioned in [GMPLS-ANAL]: Full Information and
Partial Information approaches. We coin the scheme in this draft as
Proper Information approach.
Let b be the bandwidth demand of a LSP setup request. When
computing the route of working LSP, the Proper Information approach
computes the weight of l(i, j) as follows,
_ _ Cij / Rij (Rij >= b)
|
WT[i,j]=|
|_ _ infinity (otherwise)
After the working LSP is selected, when protection LSP is being
selected, WT[i,j] should be computed as follows,
---- Cij (Bij >= b)
|
WT[i,j]=|---- Cij+Cij*(1-Bij/b) (Bij<b, Rij>=b-Bij)
|
---- infinity (otherwise)
The weight computation of l(i, j) above has two advantages:
a) It can provision more probability of recovery resource sharing
in GMPLS networks. b) It can balance the traffic in GMPLS networks.
When computing working LSP, it is obvious that the WT(i, j) will be
less if l(i, j) has more residual bandwidth. When protection LSP is
selected, WT(i, j) will be less if l(i, j) has reserved more
bandwidth. Thus, links with more reserved bandwidth will be more
possible to be selected as the segments of protection LSP.
Suppose Plsp is selected as protection LSP. Let Bw(i,j) represent
the recovery resources that should be allocated for Plsp on
l(i, j). The computation of Bw(i, j) is conducted on node i as
follows.
Internet Draft - Expires January 2005 [page 4]
draft-gmpls-recovery-resource-sharing-00.txt July 2004
w = Bij - sum{k} [fij[k]];
where k must satify: (Inf(Wlsp) AND Sij[k]) is not an empty set;
---- 0 (b <= w)
|
Bw(i,j)=|---- b - w (Rij >= b-w, b>w)
|
---- infinity (otherwise)
Note that Bw(i,j) may be set to infinity as above, which means
recovery resource reserving action may fail on l(i, j). The reason
of this is the bandwidth estimation in computing protection LSP
is inaccurate. Two conditions in computing WT[i,j] for protection
LSP may cause the failure of Plsp setup:
a)Even if Bij>=b is satisfied, only x bandwidth units can be shared
due to the restriction that the protected LSPs must be physically
disjoint, where x<b. However, Rij<(b-x), which means no enough
residual resources can be allocated for recovery purpose. So,
recovery resource allocation may fail on l(i, j).
b)When Bij<b and Rij>=(b-Bij) are satisfied, b-Bij bandwidth units
need to be allocated at least as recovery resources. But, only x
bandwidth units can be shared due to the restriction that the
protected LSPs must be physically disjoint, where x<Bij. Thus,
more bandwidth than b-Bij should be allocated as recovery
resources now. As a result, no enough residual resources can be
allocated if Rij<(b-x).
However, the probability of conditions a) and b) occurrence is
very small in practical networks. Thus, it has little affect on the
performance of rejected LSP setup requests in the scheme. In fact,
the Proper Information approach performs very well in decreasing
rejected LSP setup requests in Section 7.
4. Signaling Procedure
In this draft, we describe the signaling procedure for Proper
Information approach based on RSVP-TE developed in [RFC-3473].
No additional signaling procedure is required in the Proper
Information approach though all nodes along the selected protection
LSP must be informed Inf(Wlsp). As assumed in Section II, node i
is the dominating node for any l(i, j), and the information about
PLij, WLij, fij[k], Sij[k] and tij[k][m] will be obtained on node i.
Internet Draft - Expires January 2005 [page 5]
draft-gmpls-recovery-resource-sharing-00.txt July 2004
We assume the information of Bij and Rij have been advertised to all
nodes in networks by routing protocol extension. When receiving the
LSP setup request, the source node uses Dijkstra's algorithm to
select the working LSP with WT[i,j] computed as above. When the
working LSP Wlsp is selected, the information of Inf(Wlsp) is held
on the source node. A Path message is sent from the source to the
destination node along Wlsp to setup the LSP. After receiving the
Path message, the destination node sends a Resv message back to the
source node. All intermediate nodes along Wlsp will allocate the
resources for Wlsp when receiving the Resv message. When Resv
message reaches the source, the establishment of Wlsp is finished.
Then, protection LSP Plsp is selected by source node in terms of
WT[i,j] computed in Section 3. Similar to the establishment of Wlsp,
a Path message is sent from source to destination node along Plsp.
Here, the information of Inf(Wlsp) and the ID of established
working LSP can be transmitted to all intermediate nodes along Plsp
with Path message. Any node receiving the Path message will utilize
Inf(Wlsp) to compute Bw(i,j).
If the computation result of Bw(i,j) is infinity, the node will ter-
minate the propagation of Path message and send a PathErr message
back to the source node to notify the failure of Plsp establishment.
Otherwise, the Path message will be forwarded to the next hop till
it reaches the destination node. Then, the destination sends a Resv
message back to the source node along Plsp. Upon receiving the
Resv message, the intermediate nodes allocate recovery resources
according to previous computed Bw(i,j). The establishment of Plsp is
completed when source node receives the Resv message.
As shown above, no additional signaling procedure is required for
working and protection LSPs setup in the Proper Information
approach. But additional information (e.g., information of
Inf(Wlsp)) must be transmitted during the signaling procedure.
The signaling procedure of LSP release will not be discussed in this
section due to two facts: 1) The signaling procedure for LSP release
in the Proper Information approach is the same as that in standard
GMPLS. 2) No additional information will be transmitted when
releasing working and protection LSPs in the Proper Information
approach.
5. PROTECTION Object
In this section, we describe the extensions to the PROTECTION object
in Path message to broaden it to transmit the information of
Inf(Wlsp).
Internet Draft - Expires January 2005 [page 6]
draft-gmpls-recovery-resource-sharing-00.txt July 2004
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(37) | C-Type (TBA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Protected LSP ID | Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR ID 1 | LSR ID 2 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR ID N-1 | LSR ID N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Secondary (S): 1 bit
When set to 1, this bit indicates that the requested LSP is a
protection LSP. When set to 0 (default), it indicates that the
requested LSP is a working LSP.
Protected LSP ID: 16 bits
When S is set to 0, this field MUST be set to zero on
transmission and MUST be ignored on receipt. When S is set to
1, this field identifies the LSP protected by this LSP. If
unknown, this value is set to 0 (default).
Reserved: 9 bits
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt. These bits SHOULD be pass
through unmodified by transit nodes.
Link Flags: 6 bits
Indicates the desired link protection type (see [RFC-3471]).
LSR ID: 16 bits
When S is set to 0, this field MUST be set to zero on
transmission and MUST be ignored on receipt. When S is set to
1, this field indicates all nodes along the associated
protected LSP.
6. Resource Allocation and Release
Internet Draft - Expires January 2005 [page 7]
draft-gmpls-recovery-resource-sharing-00.txt July 2004
In this section, we introduce how to assign and release resources
correctly and effectively. Clearly, recovery resource release is
an opposite procedure of recovery resource allocation. RSVP-TE is
still used as signaling protocol in this section.
6.1 Resource Allocation
The resource allocation consists of two procedures: resource alloc-
ation for working LSP and resource allocation for protection LSP.
The resource allocation procedures are as follows:
Proc.1) A new working LSP Wlsp is being established. The bandwidth
demand is b units. For any link l(i, j) along Wlsp, when
node i receives Resv message:
- Update Rij in terms of b.
Proc.2) A new protection LSP Plsp is being established. LSP ID of
Plsp is Y and bandwidth demand is b units. The ID of working
LSP that Plsp protects is X. For any link l(i, j)
along Plsp, when node i receives Resv message:
- Update Rij, Bij according to Bw(i,j), which has been
computed when node i received the associated Path message.
Add Y to set PLij and X to set WLij.
- The value of fij[k] is set to b.
- A set T, which contains the protection LSP IDs with which
the new protection LSP Plsp may share bandwidth, is
obtained.
- Some protection LSPs in T are selected to share bandwidth
with Plsp. Then, the amount of shared bandwidth for each
selected protection LSP is computed. Finally, both
tij[k][m] and tij[m][k] are updated.
6.2 Resource Release
The resource release also consists of two procedures: resource
release for working LSP and resource release for protection LSP.
The resource release procedures are as follows:
Proc.1) A working LSP Wlsp is being released. The bandwidth demand
is b units. For any link l(i, j) along Wlsp, when node i
receives ResvTear message:
- Update Rij according to b.
Internet Draft - Expires January 2005 [page 8]
draft-gmpls-recovery-resource-sharing-00.txt July 2004
Proc.2) A new protection LSP Plsp is being released. LSP ID of Plsp
is Y and bandwidth demand is b units. The ID of working
LSP that Plsp protects is X. For any link l(i, j) along
Plsp, when node i receives ResvTear message:
- Remove Y from set PLij and X from set WLij.
- When Plsp was setup, it may share some recovery resources
with others. Also, some resources allocated for Plsp may
be shared by other protection LSPs during the holding time
of Plsp. These shared resources should not be released
when Plsp is released. Let C denote the bandwidth that
will be actually released. C can be computed according to
fij[k] and tij[k][m].
- Update Rij, Bij in terms of C.
6.3 Illustration of Resource Allocation and Release
The resource allocation and release procedures can be illustrated
using the following network topology:
======X(3)=======
a-----------------b
|======Y(5)=======|
|* * * *| working LSP
|* * * *| ==========
|* ****Y'(5)**** *|
|******X'(3)******| Protection LSP
c-----------------d **********
|******Z'(7)******|
|* *|
|* *|
|* *|
e-----------------f
======Z(7)=======
In the initial state, two working LSPs X and Y are established
between nodes a and b. The bandwidth demands of X and Y are 3 and 5
units respectively. The protection LSPs for X and Y are X'={a,c,d,b}
and Y'={a,c,d,b}. Note that X' and Y' can not share recovery
resources since X and Y are not physical disjoint. Thus, we can
obtain Bcd=8, PLcd={X', Y'}, WLcd={X, Y}, fcd[1]=3, fcd[2]=5,
tcd[1][2]=0 and tcd[2][1]=0. Now, a new LSP Z is setup between nodes
e and f with 7 units of bandwidth demand. The protection LSP for Z
is Z'={e,c,d,f}. Clearly, no resources require to be allocated on
l(c, d) because Z' can share resources with X' and Y' due to the
fact that LSP Z is disjoint with LSPs X and Y.
Internet Draft - Expires January 2005 [page 9]
draft-gmpls-recovery-resource-sharing-00.txt July 2004
In terms of resource allocation procedures above, we can get Bcd=8,
PLcd={X', Y', Z'}, WLcd={X, Y, Z}, fcd[1]=3, fcd[2]=5, fcd[3]=7,
tcd[1][3]=3, tcd[2][3]=4, tcd[3][1]=3 and tcd[3][2]=4 after Z' is
established. Next, we give the examples of shared resource release
on l(c,d). Three situations will be considered, which are releasing
Z' first, releasing X' first and releasing Y' first.
i) Releasing Z' first: In this situation, LSP Z expires before X and
Y. According to the resource release procedures, the bandwidth
released for Z' on l(c,d) is computed as
fcd[3]-tcd[3][1]-tcd[3][2]=0. So, no resource should be released
when releasing Z'. Thus, the refreshed information is Bcd=8,
PLcd={X', Y'}, WLcd={X, Y}, fcd[1]=3, fcd[2]=5, tcd[1][2]=0 and
tcd[2][1]=0, which is the same as that in the initial state.
ii) Releasing X' first: On l(c,d), the recovery resources for X' are
all shared by Z'. Thus, the bandwidth released for X' is
fcd[1]-tcd[1][3]=0. After X' is released, the refreshed
information is Bcd=8, PLcd={Y', Z'}, WLcd={Y,Z}, fcd[1]=5,
fcd[2]=7, tcd[1][2]=4 and tcd[2][1]=4.
iii) Releasing Y' first: When releasing Y', only part of recovery
resources for it should be released because some recovery
resource is being shared by Z'. Here, the bandwidth released
is fcd[2]-tcd[2][3]=1. In terms of resource release
procedures, we obtain the refreshed information on l(c,d),
which is Bcd=7, PLcd={X', Z'}, WLcd={X, Z}, fcd[1]=3,
fcd[2]=7, tcd[1][2]=3 and tcd[2][1]=3.
7. Performance Evaluation
We evaluate the performance of Proper Information approach in diffe-
rent tested networks by simulations. Two metrics are examined,
1) recovery overhead, which is the rate of the total bandwidth
allocated for protection LSPs to the total bandwidth reserved for
working LSPs in networks. 2) rejected session setup requests.
The proposed approach is compared to the Full Information Flooding
approach (see [GLI]), which has optimal performance in recovery
overhead. The results show that the proposed scheme gives a
performance difference of less than 3% in recovery overhead
compared to [GLI]. When it comes to rejected requests, the number
of rejected requests in [GLI] is almost the double of the proposed
scheme. Clearly, Proper Information approach decreases rejected
requests in GMPLS networks significantly due to its capability of
traffic balancing.
8. LSP Segments P&R
The Proper Information approach can be applied to LSP segments P&R
without any modification. But the performance needs further study.
Internet Draft - Expires January 2005 [page 10]
draft-gmpls-recovery-resource-sharing-00.txt July 2004
9. Conclusions
This draft discussed the issue of recovery resource sharing with
traffic balancing in GMPLS networks. We propose the Proper Informat-
ion approach to provision the capability of recovery resource
sharing and traffic balancing. The Proper Information approach
needs less bandwidth information than other approaches. Moreover,
no additional signaling procedure is required. We highlight the
signaling implementation of it, including resource allocation and
release procedures. We conclude that the proposed scheme indeed
improves resource utilization and decreases rejected requests in
GMPLS networks.
10. IANA Considerations
IANA assigns values to RSVP protocol parameters. Within the current
document a PROTECTION object (new C-Type) are defined.
- PROTECTION object: Class-Num = 37, C-Type = 3 (suggested)
11. Intellectual Property Considerations
This section is taken from Section 10.4 of RFC2026 [RFC-2026].
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights, which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
12. References
12.1 Normative References
[GMPLS-ARCH] E. Mannie (Editor) et al., "Generalized MPLS
Architecture," Work in progress, draft-ietf-ccamp-
gmpls-architecture-07.txt, May 2003.
Internet Draft - Expires January 2005 [page 11]
draft-gmpls-recovery-resource-sharing-00.txt July 2004
[RFC-2026] S. Bradner, "The Internet Standards Process - Revision
3," BCP 9, IETF RFC 2026, January 1996.
[RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, IETF RFC 2119, March 1997.
[RFC-3471] L. Berger (Editor) et al., "Generalized MPLS -
Signaling Functional Description," IETF RFC 3471,
January 2003.
[RFC-3473] L. Berger (Editor) et al., "Generalized MPLS Signaling
- RSVP-TE Extensions," IETF RFC 3473, January 2003.
[FUNCT] J. P. Lang (Editor) et al., "Generalized MPLS Recovery
Functional Specification," Work in progress, draft-ietf
-ccamp-gmpls-recovery-functional-01.txt, September
2003.
[GMPLS-ANAL] D. Papadimitriou (Editor) et al., "Analysis of
Generalized Multi-Protocol Label Switching (GMPLS)
-based Recovery Mechanisms (including Protection and
Restoration)," work in progress, draft-ietf-ccamp-gmpls
-recovery-analysis-02.txt, September 2003.
[TERM] E. Mannie and D. Papadimitriou (Editors), "Recovery
(Protection and Restoration) Terminology for GMPLS,"
Work in progress, draft-ietf-ccamp-gmpls-recovery-
terminology-02.txt, May 2003.
12.2 Informative References
[GLI] G. Li et al., "Efficient distributed restoration path
selection for shared mesh restoration," IEEE/ACM Trans.
Networking, vol. 11, pp. 761-771, January 2003.
13. Authors' Addresses
Qing Huang
National Key Laboratory of Switching & Networking and
Telecommunications Engineering School
Beijing University of Posts and Telecommunications,
Beijing, China
E-mail:huangqing_bupt@hotmail.com
Geng-Sheng (G.S.) Kuo
National Chengchi University, Taipei
E-mail: gskuo@ieee.org
Internet Draft - Expires January 2005 [page 12]
draft-gmpls-recovery-resource-sharing-00.txt July 2004
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Internet Draft - Expires January 2004 [page 13]
