Internet DRAFT - draft-lee-ccamp-pce-policy-recovery-framework
draft-lee-ccamp-pce-policy-recovery-framework
Network Working Group Y. Lee
Internet-Draft J. Zhu
Expires: December 1, 2006 Huawei
May 30, 2006
Framework for the Policy-Based Recovery Mechanism in GMPLS Network
draft-lee-ccamp-pce-policy-recovery-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 1, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a framework for policy-based protection/
restoration mechanism in GMPLS network. This document provides the
definition for recovery policy, architecture framework and the
protocol requirements to be able to support policy-based recovery
mechanism.
Lee & Zhu Expires December 1, 2006 [Page 1]
Internet-Draft Policy-based Recovery in GMPLS May 2006
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Recovery Policy Definition . . . . . . . . . . . . . . . . . . 6
4. Recovery Policy Architecture . . . . . . . . . . . . . . . . . 8
4.1. Recovery Policy Architecture in the context of the PCE . . 8
4.2. Recovery Policy Architecture with a Direct Interface
with the Signaling Engine . . . . . . . . . . . . . . . . 10
5. Communication Protocol Requirements . . . . . . . . . . . . . 13
6. Recovery Policy Object/TLV Definition . . . . . . . . . . . . 14
7. Areas for Standardization . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Lee & Zhu Expires December 1, 2006 [Page 2]
Internet-Draft Policy-based Recovery in GMPLS May 2006
1. Terminology
The terminology explained herein complies with [RFC 4427], [RFC
4397], [PCE ARCH] and [RFC 2748].
A Switching layer (a Network Layer, a Layer): A set of data links
with interfaces that have the same switching and data encoding types
and switching bandwidth granularity. Examples of switching layers
are 2.5G/10G wavelength, SDH VC12, SDH VC4, ATM VP/VC, Ethernet, IP,
etc.
Integrated Mode: Recovery process that is performed integrating
multiple layers of the network.
PCC: Path Computation Client: Any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: An entity (component, application or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
PDP: Policy Decision Point: A policy server that contains policy
related information.
PEP: Policy Enforcement Point: A policy client that enforces policy
for its application.
Protected Path: A path subject to protection against faults.
Protection: A class of service recovery that does not require any
provisioning signaling for the alternative LSP after the failure
indication.
Protection Path: A path used for protecting a protected path in case
of failures.
Recovery: A generic term that encompasses both the service protection
and restoration.
R-PDP: Recovery Policy Decision Point: A policy server that is
responsible for making decisions on recovery policy and directives
and communicating them to the client for enforcement.
R-PEP: Recovery Policy Enforcement Point: A policy client that is
responsible for enforcing recovery policy for its application based
on the R-PDP information.
Restoration: A class of service recovery that requires some
Lee & Zhu Expires December 1, 2006 [Page 3]
Internet-Draft Policy-based Recovery in GMPLS May 2006
provisioning of the signaling for the alternative path after the
failure indication.
TED: Traffic Engineering Database which contains the topology and
resource information of the domain. The TED may be fed by IGP
extensions or potentially by other means.
Vertical Integration: A set of collaborative mechanisms within a
single node driving multiple (at least two) network layers, and the
adaptation between those layers.
Lee & Zhu Expires December 1, 2006 [Page 4]
Internet-Draft Policy-based Recovery in GMPLS May 2006
2. Motivation
Recovery mechanism in telecommunication networks has been simplistic
as the scope of recovery has been segmented into a specific layer or
a particular switching capability. Typically different organizations
are responsible for the protection/restoration of the specific layer
and/or the switching capability. As vertical and horizontal
integration is promised in the emerging GMPLS network, it is evident
that the complexity of recovery mechanism has increased. The
complexity of the recovery mechanism in the GMPLS integrated network
has many dimensions that include technical complexity as well as
organizational complexity. This complexity arises partly due to
diversity of views and practices inherent to the individual
organizations/networks that comprise of GMPLS network integration
[OKI], [MLN-RQMT].
Therefore, it is important that operators of the GMPLS networks
should be given the capability to choose recovery policies that best
fit to the practices and philosophies of the operators. To
accommodate this flexibility and need, it is necessary to define
recovery policy model. While implementation and enforcement of
policy is largely a local matter, it is important to provide
operators with the capability to choose preferred recovery policy for
their recovery operation.
This document provides a set of recovery policies. This document
also provides a high level framework for recovery policy architecture
and the protocol requirements.
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].
Lee & Zhu Expires December 1, 2006 [Page 5]
Internet-Draft Policy-based Recovery in GMPLS May 2006
3. Recovery Policy Definition
This section provides policy definition for recovery. In order to
discuss recovery policy constraints, it is essential to understand
the scope of specific protection and restoration mechanism currently
defined by the GMPLS CCAMP Working Group. Based on the discussions
in RFC 4426, 4427, 3471 and [RECOVERY], there are two types of
protection/restoration have been defined: (i) Span (Link) Protection
and (ii) End-to-End (Path) Protection and Restoration. Under Span
(Link) Protection, the following protection types have been defined:
- Unprotected (0:1)
- (Full) Re-routing
- Re-routing without Extra Traffic
- Unidirectional 1+1 dedicated protection
- Bi-directional 1+1 dedicated protection
- Dedicated 1:1 protection with extra traffic
- Shared M:N protection
Under End-to-End (Path) protection and restoration, the following
mechanisms have been defined:
- Unidirectional 1+1 Protection
- Bi-directional 1+1 Protection
- Dedicated 1:1 Protection
- Unprotected
- Extra Traffic
Given the aforementioned Protection/Restoration schemes, there are
numbers of criteria in which operator's recovery policy can be
defined. The recovery policy constraints specified below can be
applied per protection type or globally applied to all protection
types. The list specified below is not meant to be extensive or
complete. Some of these policies are mono-layer oriented while
others are multi-layer oriented. As more recovery related policies
are identified, the list will be expanded.
- Computation of the Protection Path/Link: (i) the protection path
Lee & Zhu Expires December 1, 2006 [Page 6]
Internet-Draft Policy-based Recovery in GMPLS May 2006
can be computed before the failure (pre-computed) or (ii) the
protection path is computed after the failure (post-computed).
- Selection of the Protection Path/Link: (i) the selection of the
protection path is pre-selected before the failure (pre-selected) or
(ii) the selection of the protection path is selected after the
failure (post-selected).
- Signaling of the Protection Path/Link: (i) the protection path
setup is signaled before the failure (pre-signaled) or (ii) the
protection path setup is signaled after the failure (post-signaled).
- Allocation of Bandwidth on the Protection Path/Link: (i) pre-
allocated (the protection bandwidth is pre-allocated and therefore
reserved prior to the failure of the protected path; or (ii) post-
allocated (the protection bandwidth is allocated after the failure of
the protected path).
- Composition of the Protection Path/Link: (i) only single-layer
path/link is allowed; or (ii) multi-layer path/link is allowed.
- Protection Reversion: (i) allowed (the switching of the user
traffic from the protecting to the protected path after recovery is
allowed); or (ii) disallowed (the switching of the user traffic from
the protection to the protected path after recovery is not allowed).
We can easily see that there is a place for policy-based recovery
mechanism that would allow operators to choose appropriate policies
depending on the operator's need and integration directives. It is
to be noted that these policy-based capability provides flexibility
to the operators and facilitates operator's horizontal and vertical
integration effort. Given the complexities and varieties of the
service protection and the network conditions, the operators should
be given an ability to flexibly adapt and enforce their preferences.
Lee & Zhu Expires December 1, 2006 [Page 7]
Internet-Draft Policy-based Recovery in GMPLS May 2006
4. Recovery Policy Architecture
This section provides recovery policy architecture and its key
components. As seen in the previous section, some of the recovery
policies defined in the previous section are closely related to the
path computation element (PCE). Recovery policy architecture,
therefore, can be built on top of the existing PCE architecture as
defined in [PCE ARCH]. On the other hand, it should be also possible
to build recovery policy architecture that has a direct interface
with the Signaling Engine. This approach is based on a distributed
philosophy.
Presented in this section, therefore, are the two base architecture:
(i) Recovery Policy Architecture in the context of the PCE (ii)
Recovery Policy Architecture with a direct interface with he
Signaling Engine.
4.1. Recovery Policy Architecture in the context of the PCE
Figure 1 depicts recovery policy architecture in the context of the
PCE architecture.
+---------+ Routing Protocol
| TED |<--------------------------->
+---------+
|
|
|
\/
+------------+ +------------+ PCE-PCE Protocol
| Recovery |-->| PCE |<------------------------->
| PDP | +------------+
+------------+ /\
| PCE-PCC Protocol
|
\/
Service Request +------------+ Signaling Protocol
---------------->| Signaling |<------------------------->
| Engine |
+------------+
Figure 1: Recovery Policy Architecture in the Context of the PCE.
Lee & Zhu Expires December 1, 2006 [Page 8]
Internet-Draft Policy-based Recovery in GMPLS May 2006
Figure 1 depicts that recovery policy decision is conveyed to the PCE
by which enforcement of the recovery policy is to be performed. As
recovery and path computation are closed related, the recovery policy
can be viewed as an additional component to the PCE with this
architecture.
The invocation of the recovery policy is typically independent of the
service request or signaling flow. When operator's recovery policy
is communicated to the Recovery Policy Decision Point (R-PDP), the
R-PDP, then, communicates the recovery policy to the PCE. There are
many ways for the R-PDP to communicate the recovery policy to the
PCE. The choice of the protocol between the R-PDP and the PCE is not
the focus of this draft. Whether the R-PDP is local to the PCE or
external is also beyond the scope of this draft.
With respect to the R-PDP, the PCE depicted in Figure 1 serves as the
Policy Enforcement Point (PEP) as defined in [RFC 2748] and
[Bryskin]. The responsibility of the PCE is to disseminate the
recovery policy information to the nodes that need to implement
recovery policy during the path establishment stage. There may be
several options for the PCE to disseminate the recovery policy
information to the nodes during the path etablishment stage. One
obvious way is through the Signaling Protocol. This requires the PCE
to request to the Signaling Engine to include the recovery policy
Object/TLV during path establishment. This particular method will be
discussed in more detail in section 4.2. With the PCE architecture
where the PCE is an external entity from the LSR, the PCE could
establish a direct interface to each node under its domain control
and disseminate the recovery policy information via the PCE-PCC
protocol.
The PCE is also responsible for enforcing the recovery policy in its
path computation process. It is to be noted that some of the
recovery policy may be enforced at the PCE level while others may be
enforced at the Signaling Engine. For instance, if recovery policy
for bandwidth allocation were 'allocation before failure' on the
protection path, then this policy should be applied in the process of
reservation. The enforcement of this policy would be expected at the
Signaling Engine. On the other hand, recovery policy related to
computation (for instance, whether the protection path is computed
before the failure or not) would be enforced by the PCE as such
function is an integral part of the PCE.
Important aspect is that both the PCE and the Signaling Engine share
the same policy and coordinate each other in the enforcement of the
recovery policy. While the recovery policy information is to be
disseminated from the PCE to the Signaling Engine with this
architecture, the Signaling Engine should communicate the level of
Lee & Zhu Expires December 1, 2006 [Page 9]
Internet-Draft Policy-based Recovery in GMPLS May 2006
protection associated with a service request to the PCE. When the
Signaling Engine requests path computation to the PCE, the recovery
level (protection/restoration) should be communicated to the PCE so
that the PCE would be able to enforce the recovery policy associated
with the recovery level.
For example, let's suppose that the Signaling Engine requests path
computation for 1:1 protection for a given source-destination pair.
The PCE inspects if there are any policy constraints for 1:1
protection. Let say the recovery policies for the protection path
are: pre-computed, pre-signaled, pre-selected, pre-allocated, inter-
layer path allowed, protection reversion allowed. Then the path
computation would proceed subject to these policy constraints where
possible.
In order for the policy realized across the network domain, the
recovery policy information should be communicated between the PCE
and the Signaling Engine via the PCE-PCC protocol [PCEP], and/or
between the PCEs. Proper Object/TLV should be defined in both PCE-
PCC Protocol and/or the PCE-PCE Protocol to achieve policy
realization and dissemination across the network domain.
4.2. Recovery Policy Architecture with a Direct Interface with the
Signaling Engine
Figure 2 shows recovery policy architecture that has a direct
communication interface with the Signaling Engine.
+---------+ Routing Protocol
| TED |<------------------------->
+---------+
|
|
|
\/
+------------+ +------------+ PCE-PCE Protocol
| Recovery | | PCE |<----------------------->
| PDP | +------------+
+------------+ /\
|______ | PCE-PCC Protocol
| |
\/ \/
Service Request +------------+ Signaling Protocol
---------------->| Signaling |<----------------------->
| Engine |
+------------+
Lee & Zhu Expires December 1, 2006 [Page 10]
Internet-Draft Policy-based Recovery in GMPLS May 2006
Figure 2: Recovery Policy Architecture with a direct communication
interface with the Signaling Engine.
This architectural option does not depend on the PCE architecture as
heavily as the previous option. While the PCE component is still
needed in order to enforce recovery policy, the role of the PCE is
secondary as compared to the previous architecture option. The
Recovery-Policy Decision Point (R-PDP) conveys the recovery policy
information directly to the Signaling Engine. The Signaling Engine
is the main policy enforcement point (PEP) with this model. The
Signaling Engine is responsible for the dissemination of the recovery
policy information to the PCE as well as to adjacent nodes.
Upon a service request, the Signaling Engine would request path
computation to the PCE via the PCE-PCC protocol. In doing so, the
recovery policy information should be conveyed from the Signaling
Engine to the PCE as part of the request message so that the PCE
would apply relevant recovery policy in path computation.
As the recovery policy information resides at the Signaling Engine,
the dissemination of the recovery policy is to be performed by the
Signaling Engine to adjacent nodes associated with the path during
the path establishment stage. The Signaling Engine at the headend
node, upon a service request, would request path computation to the
PCE. The PCE would then apply the pertinent recovery policy
associated with the path request and proceed with the path
computation. The PCE then would send the reply message back to the
Signaling Engine with the result. As the Signaling Engine proceed
with the signaling to the nodes along the path, the recovery policy
information is to be sent to downstream nodes.
The recovery policy information is then stored in the Signaling
Engine in each and every downstream node on the both the protection
and protected paths. The recovery policy information can be defined
as an object/TLV of the RSVP-TE signaling. Compared to the previous
architecture, the role of the Signaling Engine is more significant.
The dissemination of the recovery policy information is based on
distributed and as-needed basis through the Signaling Protocol. When
a path is set up, the recovery policy information should be
communicated to all the nodes associated with the path such that
recovery policy would be enforced if necessary at each node along the
path. To illustrate, let's consider the following topology.
Lee & Zhu Expires December 1, 2006 [Page 11]
Internet-Draft Policy-based Recovery in GMPLS May 2006
A------B------C-------D-------E
\ /
\ /
\ /
F-------G
Figure 3: An Example topology.
Let say that the path (A-B-C-D-E) is the protected path whereas the
path (B-F-G-D) is the protection path for the segment (B-C-D) of the
path (A-B-C-D-E). Assume that the operator wants to enforce the
following recovery policy: pre-computed protection path, pre-selected
protection path, pre-signaled protection path, pre-allocated
bandwidth, multi-layer protection allowed, reversion not allowed. As
the Path message is signaled to downstream nodes along the path (A-B-
C-D-E), the recovery policy information is included as an object/TLV
in the PATH message so that each node is updated with the recovery
policy sent by the headend node A. As the RESV message is sent back
from node E, node B would initiate the path set up for the protection
path enforcing the recovery policy it previously received. All the
relevant recovery policy would be applied where possible by node B.
According to the recovery policy, node B would request computation
and selection of the protection path to the PCE.
Notice that since the policy allows multi-layer links for its
protection path, node B should communicate this policy to the PCE so
that the PCE would apply this particular policy in its path
compuation process. Upon the receipt of the reply message sent from
the PCE, node B would then proceed the signaling of the path to the
adjacent node F while allocating bandwidth for the path according to
the policy.
Assume that a link failure takes place on link (C-D). Based on the
protection scheme, traffic on the protected path would be rerouted to
the protection path (A-B-F-G-D-E). After the failure is fixed, based
on the recovery policy, traffic will not be reverted back to the
protected path.
This example illustrates why the recovery policy object/TLV should be
disseminated to the nodes that are part of the recovery. It also
shows how the recovery policy information is used in the nodes along
the protection path.
Lee & Zhu Expires December 1, 2006 [Page 12]
Internet-Draft Policy-based Recovery in GMPLS May 2006
5. Communication Protocol Requirements
This section discusses communication protocol requirements to support
the recovery policy architecture presented in the previous section.
There are four key communication interfaces whereby communication
protocol support is required to support recovery policy architecture
defined in the previous section.
- Communication between the Recovery Policy Decision Point (R-PDP)
and the Signaling Engine
- Communication between the Recovery Policy Decision Point (R-PDP)
and the PCE
- Communication between the PCE and the Signaling Engine
- Communication between the Signaling Engines (i.e., between nodes)
Communications between the R-PDP and the Signaling Engine and between
the R-PDP and the PCE can be the Common Open Policy Service (COPS)
protocol [RFC 2748], although not limited to that.
Communication between the PCE and the Signaling Engine can be done
via the Path Computation Element communication Protocol (PCEP) which
is described in [PCEP]. The notification message is intended to
notify useful information between the PCE and the Path Computation
Client (PCC) according to [PCEP]. Recovery related policy
information should to be defined as an Object/TLV compliant to the
PCEP message format.
RSVP-TE Object/TLV should be defined to be able to disseminate
recovery policy information to other nodes along the path during the
path establishment stage. When recovery policy information is
reached to other nodes, this would invoke an update to the existing
policy if any. The recovery policy information would be also used to
enforce any local decision associated with protection/restoration.
Lee & Zhu Expires December 1, 2006 [Page 13]
Internet-Draft Policy-based Recovery in GMPLS May 2006
6. Recovery Policy Object/TLV Definition
This section provides the definition for the Recovery Policy (RP)
Object/TLV. The format of the RP Object is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|C|S|G|B|L|R| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|C|S|G|B|L|R| Reserved | Path Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Protected (P): 1 bit
When set to 1, it indicates that the Path/Link is a protected path/
link. When set to 0 (default), this bit indicates that the Path/Link
is a protection path/link.
- Computation (C): 1 bit
When set to 1, this bit indicates that the protection path/link is
computed after failure. When set to 0 (default), this bit indicates
that the protection path/link is computed before failure.
- Selection (S): 1 bit
When set to 1, this bit indicates that the protection path/link is
selected after failure. When set to 0 (default), this bit indicates
that protection path/link is selected before failure.
- Signaling (G): 1 bit
When set to 1, this bit indicates that the protection path/link setup
is signaled after failure. When set to 0 (default), this bit
indicates that protection path/link setup is signaled before failure.
- Bandwidth (B): 1 bit
When set to 1, this bit indicates that the protection bandwidth is
allocated after failure of the protected path/link. When set to 0,
this bit indicates that the protection bandwidth allocation is pre-
allocated prior to failure of the protected path/link.
- Layer (L): 1 bit
Lee & Zhu Expires December 1, 2006 [Page 14]
Internet-Draft Policy-based Recovery in GMPLS May 2006
When set to 1, this bit indicates that multi-layer path/link is
allowed for the path/link. When set to 0 (default), this indicates
that multi-layer path/link is not allowed for the path/link.
- Reversion (R): 1 bit
When set to 1, this bit indicates that the switching of the user
traffic from the protection to the protected path/link after recovery
is allowed. When set to 0 (default), this indicates that protection
reversion is not allowed.
- Reserved: 19 bits
- Link Flags: 6 bits
This indicates the desired link protection type (per [RFC 3471]).
Currently, the following link protection types have been defined in
[RFC 3471]: Enhanced, Dedicated 1+1, Dedicated 1:1, Shared,
Unprotected, Extra Traffic.
- Path Flag: 6 bits
This indicates the desired path recovery type. Currently, the
following path recovery types have been defined in [RECOVERY]:
Unprotected, Re-routing, Re-routing without extra traffic, 1:N
Protection with Extra Traffic, 1+1 Unidirectional Protection, 1+1 Bi-
directional Protection.
The format defined above would allow recovery policy constraints for
both the protection path/link and the protected path/link by the P
bit. It allows recovery policy constraints to be defined per
recovery type and is expandable to accommodate variety of recovery
types and their recovery policies.
Lee & Zhu Expires December 1, 2006 [Page 15]
Internet-Draft Policy-based Recovery in GMPLS May 2006
7. Areas for Standardization
The following areas require standardization in order to support
policy recovery mechanism discussed in this draft.
- Definition of the recovery policy and the MIB
- The Recovery Policy Object/TLV structure
- PCEP Protocol modifications to adopt the Recovery Policy Object/TLV
- RSVP-TE Extension modifications to adopt the Recovery Policy
Object/TLV
Lee & Zhu Expires December 1, 2006 [Page 16]
Internet-Draft Policy-based Recovery in GMPLS May 2006
8. Security Considerations
The current version of this document does not introduce any new
security considerations as it only lists a set of requirements. In
the future versions, new security requirements may be added.
Lee & Zhu Expires December 1, 2006 [Page 17]
Internet-Draft Policy-based Recovery in GMPLS May 2006
9. IANA Considerations
There are no IANA actions requested in this specification.
Lee & Zhu Expires December 1, 2006 [Page 18]
Internet-Draft Policy-based Recovery in GMPLS May 2006
10. References
10.1. Normative References
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R.,
and A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of the
ITU-T's Automatically Switched Optical Network (ASON)
Architecture", RFC 4397, February 2006.
[RFC4426] Lang, J., Rajagopalan, B., and D. Papadimitriou,
"Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification", RFC 4426, March 2006.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006.
10.2. Informative References
[BRYSKIN] Bryskin, I., Papadimitriou, D., and L. Berger, "Policy-
enabled Path Computation Communication Requirements,
draft-bryskin-pce-policy-enabled-path-comp-00.txt, work
in progress", October 2005.
[MLN-RQMT]
Shiomoto, K., Ed., "Requirements for GMPLS-based multi-
region and multi-layer networks (MRN/MLN),
draft-ietf-ccamp-gmpls-mln-reqs-00.txt, work in progress",
January 2006.
[OKI] Oki, E., Ed., "Framework for PCE-Based Inter-Layer MPLS
and GMPLS Traffic Engineering,
draft-ietf-pce-inter-layer-frwk-00.txt, work in progress",
April 2006.
Lee & Zhu Expires December 1, 2006 [Page 19]
Internet-Draft Policy-based Recovery in GMPLS May 2006
[PCE ARCH]
Farrel, A., Vasseur, A., and J. Ash, "A Path Computation
Element (PCE) Based Architecture,
draft-ietf-pce-architecture-05.txt, work in progress",
February 2006.
[PCEP] Vasseur, J., Ed., "Path Computation Element (PCE)
communication Protocol (PCEP) Version 1,
draft-ietf-pce-pcep-01.txt, work in progress",
February 2006.
[RECOVERY]
Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)- based
recovery,
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt",
April 2005.
Lee & Zhu Expires December 1, 2006 [Page 20]
Internet-Draft Policy-based Recovery in GMPLS May 2006
Authors' Addresses
Young Lee
Huawei Technologies (USA)
1700 Alma Drive, Suite 100
Plano, TX 75075
US
Phone: +1 972 509 0309
Fax: +1 469 229 5397
Email: ylee@huawei.com
James Zhu
Huawei Technologies (USA)
1700 Alma Drive, Suite 100
Plano, TX 75075
US
Phone: +1 972 509 0309
Fax: +1 469 229 5397
Email: zhujiangyun@huawei.com
Lee & Zhu Expires December 1, 2006 [Page 21]
Internet-Draft Policy-based Recovery in GMPLS May 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lee & Zhu Expires December 1, 2006 [Page 22]
