CCAMP working Group W. Imajuku
Internet-Draft NTT
Proposed Status: Standards Track $B!!(B T. Otani
Expires: April 23, 2007 $B!!(B KDDI R&D Labs.
$B!!!!(B Y. Sone
Y.Sameshima
NTT
October 23 2006
Requirements for Inter-Domain LSP Recovery
draft-imajuku-ccamp-inter-domain-recovery-req-01.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 April 23, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Generalized MPLS(GMPLS) suite of protocols h
as been defined
the protection and restoration mechanisms of Label Switched
Paths (LSPs) to realize the highly resilient and reliable networks.
The objective of this document is to extract additional requirements
for the signaling mechanisms in order to extend the applicability of
the protection and restoration mechanisms for inter-domain LSPs.
Imajuku, et al. Expires April 23, 2007 [Page 1]
draft-imajuku-ccamp-inter-domain-recovery-req-01.txt October 2006
Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Document Scope . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Conventions used in this document. . . . . . . . . . . . . 4
2.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . 4
3. Note to Recovery Schemes . . . . . . . . . . .
. . . . . . . . 6
3.1. End-to-End Recovery . . . . . . . . . . . . . . . . . . . 6
3.2. MPLS Fast Re-Route . . . . . . . . . . . . . . . . . . . . 6
3.3. Segment Recovery . . . . . . . . . . . . . . . . . . . . 6
4. Recovery Schemes for inter-domain LSP . . . . . . . . . . . . 7
4.1. Inter-domain End-to-End Recovery . . . . . . . . . . . . 8
4.2. Per-Domain Recovery . . . . . . . . . . . . . . . . . . . 8
4.3. Inter-domain Link Failure Recovery . . . . . . . . . . . . 9
4.4. Domain Border Node Failure Recovery . . . . . . . . . . . 9
4.5. Comments on Described Recovery . . . . . . . . . . . . . 10
5. Problem Statements and Requirements . . . . . . . . . . . . . 10
5.1. Per-domain Recovery . . . . . . . . . . . . . . . . . . . 10
5.2. Inter-domain Link Failure Recovery . . . . . . . . . . . . 11
5.3. Domain Border Node Failure Recovery . . . . . . . . . . . 1
1
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . .. . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative references . . . . . . . . . . . . . . . . . . 12
8.2. Informative references . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Contributors
Tomonori Takeda
NTT Network Service System Laboratories
3-9-11 Midori-cho, Musashino-shi, Tokyo, 180-8585
Japan
E-mail: takeda.tomonori@lab.ntt.co.jp
Eiji Oki
NTT Network Service System Laboratories
3-9-11 Midori-cho, Musashino-shi, Tokyo, 180-8585
Japan
E-mail: oki.eiji@lab.ntt.co.jp
Kenichi Ogaki
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino
Saitama, 356-8502
Japan
Imajuku, et al. Expires April 23, 2007 [Page 2]
draft-imajuku-ccamp-interdomain-reco
very-req-01.txt October 2006
Email: ogaki@kddilabs.jp
Shuichi Okamoto
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino
Saitama, 356-8502
Japan
Email: okamoto@jgn2.jp
Atsushi Taniguchi
NTT Network Innovation Laboratories
1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847
Japan
E-mail: taniguchi.astushi@lab.ntt.co.jp
2. Introduction
CCAMP WG has so far proposed two kinds of GMPLS based recovery
mechanisms, end-to-end recovery [e2e-recovery] and segment recovery
[seg-recovery]. These proposals can provide a promising solution to
enhancing the resiliency and the reliability of networks and they
represent a key motivation toward deploying GMPLS controlled networks.
Recently, activities in many international R&E test-beds require the
standardization of inter-domain GMPLS frameworks, and these
opportunities for experimentation are expected to provide a promising
indication to the deployment of future commercialized inter-domain
GMPLS networks as observed in the historical evolution of the Internet.
In addition, initiation of the standardization process in the L1-VPN
framework [L1VPN-FW] requires the inter-domain GMPLS signaling
architecture for a special case of multi-domain networks.
The objective of this document is to extract additional requirements
for the signaling mechanisms in order to extend the applicability of
the protection and restoration mechanisms for inter-domain TE Label
Switched Paths (LSPs).
2.1 Document Scope
In particular, this document focuses on the GMPLS signaling mechanism
to simplify the problems mentioned above, although a mixed strategy of
routing and signaling is essential. Alternatively, this version of the
document extracts the requirements for GMPLS signaling functionality
for not only the end-to-end recovery strategy, but also seg
ment
recovery.
Therefore, those who wish to consider routing extensions applicable
to an inter-domain framework should refer to other documents such as
[RFC4105], [RFC4216], [RFC PCE-Arch], [brpc], and [GMPLS-AS]. Note
Imajuku et al. Expires April 23, 2007 [Page 3]
draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006
that there is a comprehensive study on inter-domain TE LSP recovery
considering both existing GMPLS routing and signaling [id-recov-anl].
The scope of this document does not include a nested domain
conforming to [inter-domain-frwk].
2.2 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119
[RFC2119].
2.3 Terminology
Terminology frequently used in this docume
nt conforms to the
definitions in [RFC4427], [inter-domain-frwk], [inter-domain-rsvp],
and so on. However, terminology concerning MPLS Fast Reroute
(MPLS FRR) defined in [RFC4090] is updated to GMPLS terminology for
segment recovery in [seg-recovery].
Branch node: The head-end node of a recovery LSP
Domain: A domain is considered to be any collection of network
elements within a common sphere of address management or path
computational responsibility.
Domain border node: A Label Switching Router at the domain boundary.
Specifically, a domain border node is the border of an AS.
The node terminates an inter-domain link connected to a peer AS
border node.
ERO: Explicit Route Object
FA: Forwarding Adjacency
FA-LSP: Forwarding Adjacency LSP
Inter-domain TE LSP: An LSP that is established across multiple
domains.
LSP: Label Switched Path. Note that the term LSP and TE LSP will
be used interchangeably.
LSP segment: Label Switched Path segment stitched to inter-domain
LSPs See [LSP-stitch].
Merge node: The tail-end of a re
covery LSP
NHOP recovery LSP: Next-Hop recovery LSP. A backup LSP that bypasses
Imajuku et al. Expires April 23, 2007 [Page 4]
draft-imajuku-ccamp-interdomain-recovery-req-00.txt October 2006
a single link of the working LSP.
NNHOP recovery LSP: Next-Next-Hop recovery Tunnel. A backup LSP that
bypasses a single node of the working LSP.
Recovery LSP: See [RFC4427]. The recovery LSP transports normal user
traffic when the working LSP fails. The recovery LSP may transport
user traffic even when the working LSP is transporting normal user
traffic, e.g., 1+1 protection. In such a scenario, the recovery LSP
is sometimes referred to as a protection LSP.
RRO - Record Route Object
TE: Traffic Engineering
TE-link: Traffic Engineering link
Working LSP: See [RFC4427]. A working LSP transports normal user
traffic.
One main issue in this do
cument focuses on the signaling method for
inter-domain TE-LSPs. Therefore, the reader should be particularly
familiar with the terminology defined in [inter-domain-frwk].
Contiguous TE LSP: This is a single end-to-end TE LSP that is setup
across multiple domains using RSVP-TE signaling procedures described
in [RFC3473]. No additional TE LSPs are required to signal a
contiguous TE LSP and the same RSVP-TE information for the TE LSP
is maintained along the entire LSP path.
Nested TE LSP: Nesting one or more TE LSPs into another TE LSP is
described in [RFC4206]. This technique can also be used to nest one
or more inter-domain TE LSPs into an intra-domain FA-LSP. While
similar to stitching in the control plane, in the data plane,
nesting allows for one or more inter-domain LSPs to be transported
over a single intra-domain FA-LSP using the label stacking
construct.
Stitched TE LSP:
The concept of LSP stitching as well as the required
signaling procedures are described in [LSP-stitch]. This technique
can be used to stitch an inter-domain TE LSP to an intra-domain LSP
segment. An inter-domain stitched TE LSP is a TE LSP comprising
different TE LSP segments within each domain that are "stitched"
together in the data plane so that an end-to-end LSP is achieved
in the data plane. In the control plane, however, different LSP
segments are signaled as distinct RSVP sessions, which are
independent from the RSVP session for the inter-domain LSP.
Imajuku et al. Expires April 23, 2007 [Page 5]
draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006
3. Note to Recovery Schemes
3.1. End-to-End Recovery
The end-to-end recovery scheme is described in [e2e-recovery]. This
scheme achieves end-to-end protection and restoration.
This document
extends the Protection Object [RFC3471] and defines how to control
the S/P/N/O bit in this object.
LSP Flags assign the recovery type such as 1+1/1:1 protection, 1:n
protection, Re-routing without Extra-Traffic (pre-planed rerouting),
and Full re-routing.
Link Flags assign the desired link protection type used for TE-LSP.
The nested or stitched inter-domain TE LSP assigns the recovery type
of the FA-LSP or LSP segment by using these flags.
3.2. MPLS Fast Reroute (MPLS FRR)
MPLS Fast Reroute (MPLS FRR) provides a form of segment recovery
for packet MPLS-TE networks. Two methods of MPLS FRR are defined
in [RFC4090]. The one-to-one backup method creates detour LSPs for
each protected LSP at each potential point of local repair.
The facility backup method creates a bypass tunnel to protect a
potential failure point which is shared by multiple LSPs and uses
label stacking.
Neither approach supports the full set of recovery types supported
by the End-to-End recovery. Additionally, the facility backup method
is not applicable to most non-PSC (pack
et) switching technologies.
3.3. Segment Recovery
The segment recovery scheme is described in [seg-recovery]. The basic
concept of the segment recovery is compatible with the MPLS FRR. This
scheme achieves protection and restoration over a portion of the
end-to-end TE LSP even for non-PSC switching technologies. In each
portion of the segment recovery, the usage of the S/P/N/O bit and LSP
flags is the same as that in the end-to-end recovery.
The segment recovery scheme provides both dynamic and static
assignment of branch and merge nodes to create recovery LSPs. The
non-zero value of the Segment Recovery Flag in the Protection Object
indicates the dynamic assignment of the branch and merge nodes. On the
other hand, an upstream node can identify the branch and merge nodes
of the recovery LSPs by using the Secondary ERO (SERO).
In addition, the segment recovery scheme further extends a new control
b
it, i.e., I/R bit, in the Protection Object.
Imajuku et al. Expires April 23, 2007 [Page 6]
draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006
The I bit indicates that the desired segment recovery type indicated
in the LSP Segment Recovery Flag is already in place for the
associated LSP.
The R bit indicates that a failure to establish the indicated
protection should result in a failure of the LSP being protected.
Considering the confidentiality of the routing information within
domains, segment recovery for inter-domain TE LSPs dynamically assigns
branch and merge nodes of the recovery LSPs. In many cases, the branch
and merge nodes of the recovery LSPs coincide with the domain border
nodes.
Here, note that segment recovery does not mean the recovery of an LSP
segment.
4. Recovery Schemes for inter-domain TE LSPs
This section categorize
s the recovery schemes for inter-domain TE LSPs
considering failure scenarios. The failure scenarios for inter-domain
TE LSPs are categorized as follows. The first one is a node or link
failure within a domain. The second one is a failure of a domain
boundary link, and the last one is a failure of a domain boundary node.
This document considers four recovery schemes.
(1) Inter-domain end-to-end recovery
End-to-end recovery performed irrespective of the failure scenario.
(2) Per-domain recovery
Sub-path recovery performed for failure scenarios within a domain
except for the failure of a domain border node.
(3) Inter-domain link failure recovery
Sub-path recovery performed for failure scenarios at domain boundary
links.
(4) Domain border node failure recovery
Sub-path recovery performed for failure scenarios at domain boundary
nodes.
Here, the term "sub-path recovery" is u
sed so as not to limit the
recovery scheme such as segment recovery. This section explains the
recovery schemes based on the figure below. For the purpose of
consistency, this figure is taken from [inter-domain-rsvp].
Imajuku et al. Expires April 23, 2007 [Page 7]
draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006
:<----- AS-1 ----->:<------ AS-2 ------->:<--- AS-3 ---->:
: : : :
CE1-----R0----X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9-----R6 :
: | | | | : / | / | / | : | | :
: | | +-ASBR2----/ ASBR5 | / | : | | :
: | | | : | | / | : | | :
: R1--R2----ASBR3------ASBR6--R4---ASBR8----ASBR10----R7---CE2
: : : :
: <================ Inter-AS TE LSP ================> :
4.1 Inter-Domain End-to-End Recovery
Inter-domain LSPs can be protected using end-to-end recovery
irrespective of the failure scenario. In this recov
ery mode, the
working and protection LSPs are created based on the results of diverse
path route computation. In this example, working and protection LSPs,
R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6-R7 and R0-R2-ASBR3-ASBR6-R4-ASBR8-
ASBR10-R7, respectively, are created. The diversity may be nodal, SRLG,
or AS diverse. The path computation strategy may be a per-domain hop
calculation with the subsequent use of a stand-alone Path Computation
Elements (PCEs) or per-domain hop calculation [per-domain-calc] with
the cooperation of multiple PCEs located in each domain.
The important point within the scope of this document is the Link
Flags in the Protection Object. The Link Flag values except 0x01
(Extra Traffic) or 0x02 (Unprotected) result in the assignment of
per-domain recovery in each domain.
4.2 Per-Domain Recovery
This document defines the recovery scheme for the node and/or link
failure within a domain as
"per-domain recovery." In this example, a
working LSP, R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6-R7, is created and
recovery LSPs in AS1, AS2, and AS3, R0-R2-ASBR3- ASBR2-ASBR1,
ASBR4-ASBR5-ASBR6-R4-ASBR8-ASBR7, and ASBR9-ASBR10-R7, respectively,
can be created. The per-domain recovery can employ mainly two kinds
of techniques corresponding to the signaling methods in each domain.
If the domain employs the contiguous signaling method, the domain
boundary nodes perform segment recovery. Namely, the domain boundary
nodes may act as branch/merge nodes that terminate the recovery LSPs
in each domain. For this case, the Protection Object of the inter-domain
LSP contains the non-zero Segment Recovery Flags. The non-zero value of
the segment recovery flag represents the dynamic identification of the
branch and merge nodes on a per-domain basis. Thus, the branch or merge
nodes are selected based on the local policy in each
domain.
On the contrary, the upstream node of the inter-domain LSPs may assign
the recovery type by using the Protection Sub-Object in the SERO.
In such a case, the processing of the SERO in the domain boundary node
Imajuku et al. Expires April 23, 2007 [Page 8]
draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006
becomes the issue, if the network operator of the domain has a local
policy that conflicts with the Segment Recovery Flags in the Protection
Sub-Object in the SERO.
If the domain employs the Nesting or Stitching LSP method, and the
Link Type Flag in the Protection Object of the inter-domain LSPs
assigns a value except 0x01 (Extra Traffic) or 0x02 (Unprotected),
the domain boundary node may perform end-to-end recovery for the
FA-LSP or the LSP segment which accommodates the inter-domain LSP.
The selection of the FA-LSP and the LSP segment is perf
ormed based
on the local policy with the consideration of the Link Type Flag.
Although there is a minor issue resulting from the discrepancy of the
defined value between the Link Flag and LSP Flag in the selection
process of the LSP Flag value of the FA-LSP from the Link Flag value
of the inter-domain LSP, it is obvious that each domain is required to
select higher reliability class of FA-LSPs to accommodate the inter-
domain LSPs.
Similarly, the LSP Flags in the Protection Object of the FA-LSP or
segment LSP are dynamically set to a higher value than the Link Type
Flag in the Protection Object of the inter-domain LSP, if the FA-LSP
or LSP segment are dynamically created following the arrival of the
PATH message of the inter-domain LSP.
The advantage of $B!H(BNesting and Stitching$B!I(B from the signaling aspect is
the ease in achieving control confidentiality for the inter-domain
TE LSP, since the switching operation of inter-domain TE LSP can be
achieved by controlling the FA-LSP or LSP segment.
4.3 Inter-Domain Link Failure Recovery
This document define
s the recovery scheme for the link failure between
a pair of domain boundary nodes as "inter-domain link failure recovery."
In this example, a working LSP, R0-X1- ASBR1-ASBR4-R3-ASBR7-ASBR9-R6-R7,
is created and recovery LSPs between AS1 and AS2, and between AS2 and
AS3, ASBR1-ASBR2-ASBR4 and ASBR7-ASBR8-ASBR10-ASBR9, respectively, can
be created. In addition, the creation of a NHOP recovery LSP may be
required if there are multiple links between pairs of domain border
nodes. Inter-domain link recovery can employ all three signaling schemes
as discussed in Section 4.2. However, the advantage of the stitching LSP
described in the previous section diminishes in this case.
4.4 Domain Border Node Failure Recovery
This document defines the recovery scheme for the nodal failure of
domain boundary nodes as "Domain border node recovery." In this
example, a working LSP, R0-X1-ASBR1-ASBR4-R3-ASBR7- ASBR9-R6-R7,
is crea
ted and recovery LSPs between AS1 and AS2, and between AS2 and
Imajuku et al. Expires April 23, 2007 [Page 9]
draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006
AS3, X1-ASBR1-ASBR2-ASBR3-ASBR6-ASBR5-R3 and R3-ASBR8-ASBR10-R7,
respectively, can be created. Inter-domain link recovery can employ
all three signaling schemes as discussed in Section 4.2. Likewise,
as in the previous section, the advantage of the stitching LSP
diminishes in this case.
4.5 Comments on Described Recovery
The recovery of the domain border link failure recovery and the domain
border node failure recovery may be degenerated as the result of a
topological constraint around the pair of border nodes. There is no
guarantee that a separate route of the recovery LSPs will be
established for the domain border link failure recovery and the domain
border node failure recovery LSPs.
5. Pro
blem Statements and Requirements
5.1 Problem Statements and Requirements for Per-Domain Recovery
Problem statements:
The signaling method is basically selected on a domain-to-domain basis
following the policy of LSP and its management architecture in each
domain. It seems trivial, but a difference in the LSP architecture
results in a difference in the functional design and database in the
network management system in each domain. Therefore, the inter-domain
TE LSP should secure the independency of the signaling method.
The selection of contiguous, nesting, and stitching is determined by
the domain border node at the upstream side of each domain. The
discussion regarding the setting scheme of the signaling method is
outside the scope of this document. However, there is one
consideration in the case that per-domain recovery is performed.
As described in Section 4.2, the creation of a recovery LSP in each
domain is performed following the Segment Recovery Flag or Link Flag
in the Protection Object of the inter-domain TE LSPs. Here, one
problem arises when the inter-domain TE LSP traverses domains
employing the contiguous and the nesting/stitching signaling methods.
For example, if both Segment Recovery Flags and Link Flags select 0x10
(1+1 Bi-directional Protection/Dedicated 1+1), some domains may try to
create four LSPs (two pairs of LSP segments with 1+1 Bi-directional
Protection) against the intension of an operator who tries to create
an inter-domain TE LSP.
Requirements:
The extension of a control bit can be a solution to this problem,
and this extension will indicate the selection of one flag out of
Segment Recovery Flags and Link Flags. This indication enables
successful selection of the proper recovery type for the inter-domain
Imajuku et al. Expires April 23, 2007 [Page 10]
draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006
LSP without any constraint in selecting the signaling method in each
domain.
5.2 Problem Stateme
nts and Requirements for Inter-Domain Link
Failure Recovery
Problem statements:
The probability of link failure becomes trivial when a pair of border
nodes is co-located in the same housing space or building as in many
cases. In such a case, it is useful to secure arbitrariness in
establishing the recovery LSPs for the inter-domain links because it
will help to avoid excess consumption of network resources within
both domains.
In addition, the introduction of a new procedure helps to reduce the
amount of required network resources. For example, let us consider
the case of network AS1, AS2, and AS3 comprising Lambda Switch
Capable (LSC) and the inter-domain links such as link ASBR7-ASBR9 and
link ASBR8-ASBR10 as bundled TE links. In such a case, a lambda
inter-domain TE LSP can be recovered within each bundled domain
border TE link for the scenario of a one-component link failure,
if these TE links co
ntain shared back-up component links. The
introduction of such a recovery technique greatly reduces the
complexity of network design issues for network operators.
Requirements:
For the first problem statement, a possible solution is the addition
of a new control bit in the Protection Object which indicates the
necessity of the inter-domain link failure recovery similar to the
R bit defined in Section [seg-recovery].
For the second problem statement, Sub-Network Connection Protection
(SNCP) can be a solution. However, the introduction of the SNCP into
GMPLS signaling mechanism provides a more generic solution to achieve
SNCP switchover. The GMPLS based solution can achieve equivalent
operation to the SNCP even if the domain border nodes have different
switching capabilities.
5.3 Problem Statements and Requirements for Domain Border Node Failure
Recovery
Problem statements:
The problem that aris
es in the domain border node failure recovery
is similar to the first problem statement of the inter-domain link
failure recovery. It is useful to secure arbitrariness in establishing
the recovery LSPs for the domain border node failure recovery because
it will help to avoid excess consumption of network resources within
both domains.
The second problem pertains to the functionality of the I bit which
Imajuku et al. Expires April 23, 2007 [Page 11]
draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006
aids in the understanding of the status of whether the recovery LSP
is in-place or not at the downstream side of the inter-domain TE LSPs.
However, the use of the I bit cannot provide sufficient information
to the downstream side of the inter-domain TE LSPs regarding whether
or not the recovery LSP for the domain border node failure is in-place.
Let us consider
the case of working inter-domain TE LSP, R0-R1-R2-
ASBR3-ASBR6-R4-ASBR8-ASBR10-R7, and the recovery LSP for a node or
link failure within AS1, R0-X1-ASBR2-ASBR3, based on the segment
recovery procedure. The in-place bit is set for the working inter-
domain TE LSP. This may result in no action; nevertheless, R1 or R2 is
required to create a NNHOP recovery LSP for ASBR3 and/or ASBR4 failure
scenarios.
Requirements:
For the first problem statement, a possible solution is the same as
that described in Section 5.2.
For the second problem statement, a possible solution is the addition
of a new control bit in the Protection Object which indicates the
necessity of the inter-domain link failure recovery similar to the I
bit defined in Section [seg-recovery]. The I bit to understand the
status of the recovery LSPs for the border node failure is necessary
in order to discriminate the status of the I bit representing the
status of the recovery LSPs for the per-domain failure recovery.
The above requirements do not require further extension to the GMPLS
signaling mechanism su
ch as ERO/RRO processing.
6. Security considerations
TBD
7. IANA considerations
This document requires no further IANA considerations.
8. References
8.1 Normative References
[e2e-recovery] Lang, J., Rekhter, Y., and Papadimitriou, D.
(Eds.), "RSVP-TE Extensions in support of End-to-
End Generalized Multi-Protocol Label Switching
(GMPLS)-based Recovery",
draft-ietf-ccamp-gmpls-recovery-e2e-signaling,
work in progress.
[seg-recovery] Berger, L., Bryskin, I., Papadimitriou, D., and
Farrel, A., "GMPLS Based Segment Recovery",
Imajuku et al. Expires April 23, 2007 [Page 12]
draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006
draft-ietf-ccamp-gmpls-segment-recovery, work in
progress.
[L1VPN-FW] Takeda, T., Editor "Framework and Requirements
for Layer 1 Virtual Private Networks", draft-
ietf-l1vpn-framework, work in progress.
[inter-domain-fw] Farrel, A., et al., "A Framework for Inter-Domain
MPLS Traffic Engineering", draft-ietf-ccamp-
inter-domain-framework, work in progress.
[inter-domain-rsvp] Ayyangar, A., Vasseur, JP. "Inter-domain MPLS
Traffic Engineering - RSVP extensions", draft-
ietf-ccamp-inter-domain-rsvp-te, work in
progress.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed.,
"Recovery (Protection and Restoration)
Terminology for Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4427, March 2006
.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC3473] Berger, L., et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE)
Extensions", RFC 3473, January 2003.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched
Paths (LSP) Hierarchy with Generalized Multi-
Protocol Label Switching (GMPLS) Traffic
Engineering (TE)", RFC 4206, October 2005.
[RFC3471] Berger, L., et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003.
[per-domain-calc]
Vasseur, J. P., Ayyanger, A., Zhang, R., "A Per-
domain path computation method for establishing
Inter-domain Traffic Engineering (TE) Label
Switched Paths (LSPs)", RFC 3471, January 2003.
8.2 Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997
Imajuku et al. Expires April 23, 2007 [Page 13]
draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006
[LSP-stitch] Ayyangar, A., and Vasseur, JP., "LSP Stitching
with Generalized MPLS TE", draft-ietf-ccamp-lsp-
stitching, work in progress.
[RFC4105] Le Roux, J.-L. , Vasseur, J.-P., and J. Boyle,
"Requirements for Inter-Area MPLS Traffic
Engineering", RFC 4105, June 2005.
[RFC4216] Zhang, R., and Vasseur, J.-P., "MPLS Inter-
Autonomous System
(AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005
[PCE-Arch] A. Farrel, JP. Vasseur and J. Ash, "Path
Computation Element (PCE) Architecture", draft-
ietf-pce-architecture, work in progress.
[brpc] Vasseur, JP., Zhang, R., and Bitar, N., "A
Backward Recursive PCE-based Computation (BRPC)
procedure to compute shortest inter-domain
Traffic Engineering Label Switched Path", draft-
vasseur-ccamp-brpc, work in progress.
[GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S.,
"GMPLS Inter-AS Traffic Engineering Requirements",
draft-otani-ccamp-interas-GMPLS-TE,
work in progress.
[id-recov-anl] Takeda, T., Ikejiri, Y., Farrel, A., and Vasseur,
J. P., "Analysis of Inter-domain Label Switched
Path (LSP) Recovery", draft-takeda-ccamp-inter-
domain-recovery-analysis, work in progress.
10. Acknowledgements
The authors would like to thank Dr. Tatsuzo Koga, representative of
NICT Tsukuba RC for the support of this study.
11. Authors' Addresses
Wataru Imajuku
NTT Network Innovation Laboratories
1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847
Japan
Phone: +81 46 859 4315
Email: imajuku.wataru@lab.ntt.co. jp
Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara, Fujimino, Saitama, 356-8502
Imajuku et al. Expires April 23, 2007 [Page 14]
draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006
Japan
National Institute of Information and Communications Technology
2-5-5 Azuma, Tsukuba, Ibaraki, 305-0031
Japan
E
mail: otani@kddilabs.jp
Yoshiaki Sone
NTT Network Innovation Laboratories
1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847
Japan
Phone: +81 46 859 2456
Email: sone.yoshiaki@lab.ntt.co.jp
Yasunori Sameshima
NTT Network Innovation Laboratories
1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847
Japan
National Institute of Information and Communications Technology
2-5-5 Azuma, Tsukuba, Ibaraki, 305-0031
Japan
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 R
FC 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
Imajuku et al. Expires April 23, 2007 [Page 15]
draft-imajuku-ccamp-interdomain-recovery-req-01.txt October 2006
"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.
Imajuku et al. Expires April 23, 2007 [Page 16]