Network Working Group M. Zhang
Internet-Draft LF. Zhang
Intended status: Informational YF. Ji
Expires: April 21, 2012 YB. Xu
BUPT
Y. Wang
CATR
October 19, 2011
Network Survivability Evaluation Metrics in Multi-domain Generalized
MPLS Networks
draft-zhangm-ccamp-reroute-02
Abstract
The ubiquitous presence of the internet coupled with the increasing
demand for high bandwidth dedicated large scale network has made it
imperative that the multi-domain networks are facilitated by the
development of GMPLS. In such large scale network, the high
performance network survivability is a significant factor to resist
the fault service discontinue and interruption even to decrease
economic loss and the society impact. This document proposes a
series of network survivability evaluation metrics and methodologies
that can be used to demonstrate the network survivability performance
in single and multi-domain GMPLS networks, more specifically, the
network fault restoration performance.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Zhang, et al. Expires April 21, 2012 [Page 1]
Internet-Draft Survivability Evaluation Metric October 2011
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Overview of Network Survivability Evaluation Metrics . . . . . 4
4. Network Survivability Evaluation Metrics . . . . . . . . . . . 4
4.1. Fault Restoration Time Phases . . . . . . . . . . . . . . 4
4.2. Restoration Schemes and Scenarios . . . . . . . . . . . . 6
4.2.1. Fault types . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Faults in single domain . . . . . . . . . . . . . . . 7
4.2.3. Faults in multi-domain . . . . . . . . . . . . . . . . 8
4.2.3.1. Faults within a domain . . . . . . . . . . . . . . 8
4.2.3.2. Inter-domain faults . . . . . . . . . . . . . . . 9
5. Methodologies . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Fault restoration in single domain network . . . . . . . . 9
5.1.1. Reroute . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. Fast Reroute . . . . . . . . . . . . . . . . . . . . . 11
5.2. Fault restoration within a domain in multi-domain
network . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Reroute . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.2. Fast Reroute . . . . . . . . . . . . . . . . . . . . . 14
5.3. Inter-domain fault restoration in multi-domain network . . 15
6. Protocol Extension Requirements . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Other Authors . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Zhang, et al. Expires April 21, 2012 [Page 2]
Internet-Draft Survivability Evaluation Metric October 2011
1. Introduction
1.1. motivation
Generalized Multi-Protocol Lable Switching (GMPLS) network is a
promising choice with the use of optical technology in core networks
combined with IP/Multi-Protocol Label Switching (MPLS) solution for
the next generation Internet architecture. The ubiquitous presence
of the internet coupled with the increasing demand for high bandwidth
and dedicated large scale network has made it imperative that the
multi-domain networks are facilitated by the development of GMPLS.
Survivability is the capability of the network to maintain service
continuity in the presence of faults within the network, at the same
time, service influenced could be switched over to free resource.
All kinds of intra-domain and inter-domain faults occurs in multi-
domain GMPLS Networks, therefore, in such large scale network, the
high performance network survivability is a significant factor to
resist the fault service interruption even to decrease economic loss
and the society impact due to faults. Recovery time is a key factor
to measure network survivability performance which has an impact on
the link and service evaluation. The long recovery time could
increase the traffic delay, packet losses, the resource collision,
preemption and service discontinue even the whole network can not
reach the level of reliability required by traffic service. The time
of every recovery phrase is required to be known by a series of
measurement methodologies in order to reduce the fault restoration
time. Certain method could be adopted to reduce the every phrase
time to achieve the aim of reducing the whole recovery time.
Therefore, network survivability evaluation metrics is necessary in
multi-domain Generalized MPLS Networks.
This document proposes a series of network survivability evaluation
metrics and methodologies that can be used to demonstrate the network
survivability performance in single and multi-domain GMPLS networks,
more specifically, the network fault restoration performance. The
time of every fault restoration phase is measured precisely to
evaluate the whole network performance by proposed evaluation
metrics.
1.2. Terminology
LSP: Lable Switched Path.
LSR: Label Switched Router.
QoS: Quality of Service.
Zhang, et al. Expires April 21, 2012 [Page 3]
Internet-Draft Survivability Evaluation Metric October 2011
PSL: Path Switch LSR.
ML: Merge LSR.
NMS: Network Management System.
RSVP: Resource Reserve Protocol.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].In addition,
the reader is assumed to be familiar with the terminology used in
[RFC3945], [RFC3471], [RFC3473] and referenced as well as in
[RFC4427] and [RFC4426].
3. Overview of Network Survivability Evaluation Metrics
There are two recovery mechanisms (eg. protection and restoration)
and the former is outside the scope of this document currently.
Network survivability evaluation metric is used to measure precise
recovery time which is a key factor during the whole fault recovery
process (eg. fault detection, fault location, fault notification,
fault recovery and reversion). These phases define the sequence of
generic operations that need to be performed when a failure occurs.
The evaluation metrics take the time of every phrase into account and
give the specific measurement steps and methodologies.
4. Network Survivability Evaluation Metrics
High performance of network survivability has become a key issue to
improve and satisfy the increasing requirements of reliability and
Quality of Service (QoS) of the whole network. This section defines
a network survivability evaluation metric in single and multi-domain
Generalized MPLS networks.
4.1. Fault Restoration Time Phases
This section gives several typical definitions of restoration times
and durations as shown in figure 1.
Phase 1: Fault detection.
Phase 2: Fault localization and isolation.
Zhang, et al. Expires April 21, 2012 [Page 4]
Internet-Draft Survivability Evaluation Metric October 2011
Phase 3: Fault notification.
Phase 4: Recovery.
Phase 5: Reversion.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Fault management|Backup path|Recovery|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TDET TLOC TNOT|TBR TBS TBA TSW TCR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Failure Restoration Time Phases
A detailed analysis and specific definition is provided for each of
the restoration phases as identified in [RFC4427] and [RFC4428].
o Fault detection time TDET
Fault detection time is defined as the time between occurrence of
fault and detecting the fault and degradation.
TDET depends on several factors pertaining to the link propagation
time, link transmission time, node processing time and node queuing
time.
o Fault Localization and isolation time TLOC
Fault Localization and isolation time is defined as the time the
signal indication information is delivered from fault node to PSL.
o Fault notification time TNOT
Fault notification time is defined as the time to inform the
noderesponsible of the switchover that a failure has occurred.
TNOT depends on failure notification delay and the notification
method used.
o Backup routing time TBR
Backup routing time is defined as the time for new backup creation,
routing (TBR) and signaling (TBS).
TBR depends on the routing method applied.
Zhang, et al. Expires April 21, 2012 [Page 5]
Internet-Draft Survivability Evaluation Metric October 2011
o Backup signaling time TBS
Backup signaling time is defined as the time that is required to
activate the backup path before the switchover.
TBS depends on the signaling method applied.
o Backup activation time TBA
Backup activation time is defined as the time between the settlement
of backup path and the switching over the traffic.
TBA depends on the backup path distance and signaling process.
o Switchover time TSW
Switchover time is defined as the time of switching the traffic from
the working path through which the traffic is flowing, to the
alternative/backup path.
TSW depends on the node technology.
o Restoration completion time TCR
Restoration completion time is defined as the time to complete the
fault recovery, i.e. the time it takes the first packet to arrive
from the backup path to the ML.
TCR depends on the backup distance.
o The total restoration time
The total restoration time is defined as the sum of TDET, TNOT, TBR,
TBS, TBA , TSW and TCR.
4.2. Restoration Schemes and Scenarios
Link restoration could effectively take use of network bandwidth to
eliminate faults. The restoration technique is also referred as
reroute and fast reroute, for instance, no backup path is established
prior to the failure to protect the working path. Therefore,
restoration requires dynamic routing algorithms and bandwidth
allocation to establish a backup path on demand upon network failure.
Once the backup path has been set up, traffic is then switched from
the working path.
Zhang, et al. Expires April 21, 2012 [Page 6]
Internet-Draft Survivability Evaluation Metric October 2011
4.2.1. Fault types
There are three failure types according to the fault level in the
optical network, such as service fault, channel failure and fiber
failure. We only take channel failure and fiber failure into
account.
Service fault : service mistake during the process of the message
packaging.
Channel fault: all the services are influenced if a TE link fault
occurs in the certain wavelength channel due to transmitter or
receiver and so on.
Fiber fault: all the services traversing the link are influenced if a
fiber fault occurs due to fiber cut or other external factor and so
on.
4.2.2. Faults in single domain
There are two restoration methods in allusion to fault in single
domain. Fast reroute mainly provides the local repair function such
as span restoration and segment restoration. The start node of span
and segment restoration is responsible for backup path computation
and traffic switching as the PSL(Path Switch LSR) instead of the
source node in reroute scheme.
o Reroute
In the scenario of single domain, detecting entities in transport
plane detect related fault information when node or link failure
occurs. Failure localization/isolation is triggered immediately
after the failure detection. And then the fault indication signaling
is sent to the source node through the GMPLS-based signaling or
flooding method by the detecting node. In the case of flooding
method, intermediate nodes pertaining to the fault end-to-end LSP are
informed the fault indication signaling between the upstream node and
source node through a notification mechanism. In the signaling-based
technique, detecting node sends fault indication signaling such as
RSVP-TE to each LSP affected by the failure through different
notification mechanism.
After receiving the fault indication signaling, the source node
computes a backup path by a series of routing algorithms or route
pre-computation scheme and then allocates the bandwidth. Path and
RESV signaling are responsible for path establishment and resource
reservation respectively for the new backup path. After that, the
traffic is switched to the backup path from the working path.
Zhang, et al. Expires April 21, 2012 [Page 7]
Internet-Draft Survivability Evaluation Metric October 2011
o Fast reroute
In the scheme of fast reroute, failure localization/isolation is
triggered immediately after the failure detection. And then the
fault indication signaling is sent to the span or segment PSL from
the upstream node of failure link through the GMPLS-based signaling
or flooding method. These two notification methods are described in
reroute part of section 4.2.1. On receiving the fault indication
signaling, PSL is computes a new path by a series of routing
algorithms and allocates the bandwidth to the backup path bypass the
fault LSP. After that, the traffic is switched to the backup path
from the working path.
4.2.3. Faults in multi-domain
There are three types of faults in multi-domain network, such as link
or node failure within the domain, failure of a link at a domain
border and failure of domain border node. Inter-domain and Intra-
domain restoration mechanisms are independent with each other.
4.2.3.1. Faults within a domain
When an intra-domain failure occurs, intra-domain restoration
mechanism is set up first within a domain and the restoration scheme
is similar to that of single domain in the scenario of multi-domain.
Inter-domain restoration mechanism would be triggered only if the
previous restoration mechanism fails.
o Reroute
Detecting entities in transport plane detect related fault
information when node or link failure occurs within a domain.
Failure localization/isolation is triggered immediately after the
failure detection. And then the fault indication signaling is sent
to the source node across intermediate domains through the GMPLS-
based signaling or flooding method. After receiving the fault
indication signaling, the source node computes a new path by a series
of routing algorithms and allocates the bandwidth. Path and RESV
signaling are responsible for path establishment and resource
reservation respectively for the backup path. After that, the
traffic is switched to the backup path from the working path.
o Fast reroute
In the same scenario above, detecting entities in transport plane
detect related fault information when node or link failure occurs
within a domain. Failure localization/isolation is triggered
immediately after the failure detection. And then the fault
Zhang, et al. Expires April 21, 2012 [Page 8]
Internet-Draft Survivability Evaluation Metric October 2011
indication signaling is sent to the local or segment PSL from the
upstream node of failure link through the GMPLS-based signaling or
flooding method. These two notification methods are described in
section 4.2.1.1. After receiving the fault indication signaling,
Path Switch LSR (PSL) is responsible for computing a new path by a
series of routing algorithms and allocates the bandwidth to establish
the backup path bypass the fault LSP. After that, the traffic is
switched to the backup path from the working path.
4.2.3.2. Inter-domain faults
Inter-domain faults comprise inter-domain link fault and border node
fault of the domain. Each domain has its own domain border node, and
these two border nodes are connected by a TE link. TE link is
invalid once the border node fails.
When the LSP traverses multiple domains and inter-domain failure
occurs, the process of failure detection and localization/isolation
is the same to that of single domain whose detail is described in
section 4.2.1. If the fault TE link is the only one between two
domains, the restoration mechanism adopts the end-to-end reroute
restoration scheme. The fault indication signal is sent to source
node by the upstream node along the LSP, and then the source node
computes another path and allocates the resource avoiding the domain
relative to the fault node and link. Otherwise, the restoration
mechanism could adopt either the reroute or the fast reroute scheme
if there is more than one link between two domains. Path and RESV
signaling are responsible for path establishment and resource
reservation respectively between PSL and ML. After that, the traffic
is switched to the backup path from the working path.
5. Methodologies
It is difficult to measure Detection time TDEF which depends on the
monitoring technique and reversion is a normalization process.
Therefore, the methodology of detection and reversion time are
outside the scope of this document.
5.1. Fault restoration in single domain network
This section gives two measurement methods of fault restoration which
are end-to-end reroute and fast reroute respectively in single domain
network. It is assumed that there exits an LSP (1-2-3-4) where data
flow is from node 1 to node 4 as an example shown in figure 2 and 3.
The link fault occurs between node 2 and node 3.
Zhang, et al. Expires April 21, 2012 [Page 9]
Internet-Draft Survivability Evaluation Metric October 2011
5.1.1. Reroute
Generally, when the failure occurs the methodology would proceed as
follows:
o The node 3 sends Channelstatus Message to node 2 indicating the
failure to the corresponding the upstream node.
o Record the timestamp (T1) when the first bit of Channelstatus
Message is sent to the node 2 along the LSP.
o When node 2 receives the ChannelStatus message from node 3, it
returns a ChannelStatusAck message back to node 3 and correlates
the failure locally. When Node 2 correlates the failure and
verifies that the failure is clear, it has localized the failure
to the data link between node 3 and node 2. At that time, node 2
sends a ChannelStatus message to node 3 indicating that the
failure has been localized.
o Then record the timestamp (T2) when the last bit of ChannelStatus
message from node 2 is received by node 3.
o The fault localization delay is T2-T1.
o The node 2 sends the notification information to the source
node(node 1) of the LSP traversing intermediate nodes. Then
record the timestamp (T3) when the first bit of PathErr
information is sent out.
o Record the timestamp (T4) when the node 1 receives the last bit of
the PathErr Message.
o Notification delay is T4-T3.
o Record the timestamp (T5) after node receives the notification
information. Node 1 as the PSL computes a new path through either
a series of route algorithms or pre-computed schemes.
o PATH and RESV signaling are responsible for path establishment
request and resource reservation respectively for a new backup
path. Then the traffic is switched from a working path to the
backup path. Record the timestamp (T6) when the first packet of
traffic arrives at the ML(node 4) through the backup path.
o Recovery time is T6-T5.
o The total fault restoration time is T2+T4+T6-T1-T3-T5.
Zhang, et al. Expires April 21, 2012 [Page 10]
Internet-Draft Survivability Evaluation Metric October 2011
+-------+ +-------+ +-------+ +-------+
+ Node1 +----c-----+ Node2 +--- c ----+ Node3 +----c ---+ Node4 +
--+-------+----------+-------+----##----+-------+---------+-------+->
+ + + + + + + +
+-------+ +-------+ +-------+ +-------+
Figure 2: Reroute of fault in single domain (indicated by ## in the
figure)
5.1.2. Fast Reroute
Generally, when the failure occurs, the methodology would proceed as
follows:
o The process of fault localization is similar to that of reroute
restoration in single domain network which is described in section
5.1.1.
o The fault localization delay is also T2-T1.
o PathErr information is sent to different PSL that differs from
fast reroute restoration scheme. Node 2 is the PSL as the ingress
node of backup path if the span recovery scheme is adopted.
Otherwise, consider other PSL as the ingress node of backup path
if segment restoration scheme is implemented.
o Then record the timestamp (T3) when the first bit of notification
information is sent out by the node 2 to the PSL which is
responsible for switching over the traffic.
o Record the timestamp (T4) when the PSL receives the last bit of
the notification information.
o Notification delay is T4-T3.
o Record the timestamp (T5) after PSL receives the PathErr Message.
The PSL computes a new path through either a series of route
algorithms or pre-computed scheme (eg. 1-2-5-3-4).
o PATH and RESV signaling are responsible for path establishment
request and resource reservation respectively for the backup path.
Then the traffic is switched from a working path to the backup
path. Record the timestamp (T6) when the first packet of traffic
arrives at the ML(node 3) through the backup path.
Zhang, et al. Expires April 21, 2012 [Page 11]
Internet-Draft Survivability Evaluation Metric October 2011
o Recovery time is T6-T5.
o The total fault restoration time is T2+T4+T6-T1-T3-T5.
+-------+ +-------+ +-------+ +-------+
+ Node1 +-----c----+ Node2 +--- c ----+ Node3 +--- c ----+ Node4 +
-+-------+----------+-------+----##----+-------+----------+-------+->
+ + + +--| -+ + + +
+-------+ +-------+ | |+-------+ +-------+
| |
| |
| |-------|
\ +-------+ |
\ + Node5 +--|
+ +
+ +
+-------+
Figure 3: Fast reroute of fault in single domain (indicated by ## in
the figure)
5.2. Fault restoration within a domain in multi-domain network
5.2.1. Reroute
Figure 4 describes the node connection situation. As illustrated
node 1 and node 4 are in domain A and B respectively and node 2 and 3
are all in domain B. Generally, when the failure occurs, the
methodology would proceed as follows:
o The node 3 sends Channelstatus Message to node 2 indicating the
failure to the corresponding upstream node.
o Record the timestamp (T1) when the first bit of Channelstatus
Message is sent to the node 2 along the LSP.
o When node 2 receives the ChannelStatus message from node 3, it
returns a ChannelStatusAck message back to node 3 and correlates
the failure locally. When Node 2 correlates the failure and
verifies that the failure is clear, it has localized the failure
to the data link between Node 3 and node 2. At that time, Node 2
sends a ChannelStatus message to Node 3 indicating that the
failure has been localized.
Zhang, et al. Expires April 21, 2012 [Page 12]
Internet-Draft Survivability Evaluation Metric October 2011
o Then record the timestamp (T2) when the last bit of ChannelStatus
message from node 2 is received by node 3.
o The fault localization delay is T2-T1.
o Node 2 sends the notification information to the source node of
the LSP(node 1) traversing intra-domain nodes and border nodes.
Notification time depends on whether the source and the
destination node are in the same domain or not. Then record the
timestamp (T3) when the first bit of notification information is
sent out.
o Record the timestamp (T4) when the node 1 receives the last bit of
the notification information.
o Notification delay is T4-T3.
o Record the timestamp (T5) after node 1 receives the PathErr
Message. As the PSL, node 1 finds a new path through either a
series of route algorithms or pre-computation scheme.
o PATH and RESV signaling are responsible for path establishment
request and resource reservation respectively for a new backup
path. Then the traffic is switched from a working path to the
backup path. Record the timestamp (T6) when the first packet of
traffic arrives at the destination node (node 4) through the
backup path.
o Recovery time is T6-T5.
o The total fault restoration time is T2+T4+T6-T1-T3-T5.
+-------+ | +-------+ +-------+ | +-------+
+ Node1 +----|c----+ Node2 +--- c ---+ Node3 +----|c ---+ Node4 +
--+-------+----|-----+-------+----##---+-------+----|-----+-------+->
+ + | + + + + | + +
+-------+ | +-------+ +-------+ | +-------+
Domain A | Domain B | Domain C
Figure 4: Reroute of fault within a domain in multi-domain
network(indicated by ## in the figure)
Zhang, et al. Expires April 21, 2012 [Page 13]
Internet-Draft Survivability Evaluation Metric October 2011
5.2.2. Fast Reroute
Figure 5 describes the node connection situation that is node 1 and
node 4 are in domain A and B respectively and node 2 ,3 and 5 are all
in domain B.
Generally, when the failure occurs between node 2 and 3 in domain B,
the methodology would proceed as follows:
o The process of fault localization is similar to that of reroute
restoration in single domain network which is described in section
5.1.2. The fault localization delay is also T2-T1.
o Notification information is sent to different PSL that differs
from fast reroute restoration scheme. Node 2 is the PSL as the
ingress node of restoration path if the span recovery scheme is
adopted. Otherwise, consider other PSL as the ingress node of
restoration path if segment recovery scheme is implemented.
o Then record the timestamp (T3) when the first bit of notification
information is sent out by the node 2 to the PSL which is
responsible for switching over the traffic.
o Record the timestamp (T4) when the PSL receives the last bit of
the PathERR message.
o Notification delay is T4-T3.
o Record the timestamp (T5) after PSL receives the PathErr Message.
The PSL finds a new path through either a series of route
algorithms or pre-computed schemes.
o PATH and RESV signaling are responsible for path establishment
request and resource reservation respectively for a new backup
path. Then the traffic is switched from a working path(2-3) to
the backup path(2-5-3). Record the timestamp (T6) when the first
packet of traffic arrives at the ML(node 3) through the backup
path.
o Recovery time is T6-T5.
o The total fault restoration time is T2+T4+T6-T1-T3-T5.
o If the intra-domain fast reroute mechanism fails, reroute
restoration is triggered whose methodology is illustrated in
section 5.2.1.
Zhang, et al. Expires April 21, 2012 [Page 14]
Internet-Draft Survivability Evaluation Metric October 2011
+-------+ | +-------+ +-------+ | +-------+
+ Node1 +-----|c---+ Node2 +--- c ---+ Node3 +--- |c ---+ Node4 +
--+-------+-----|----+-------+----##---+-------+----|-----+-------+->
+ + | + + | |+ + | + +
+-------+ | +-------+ | |+-------+ | +-------+
| | | |
| | | |
Domain A | | |-------| | Domain C
| \ +-------+ | |
| \ + Node5 +--| |
+ +
+ +
+-------+
Domain B
Figure 5: Fast reroute of fault within a domain in multi-domain
network(indicated by ## in the figure)
5.3. Inter-domain fault restoration in multi-domain network
Figure 6 describes the node connection situation. As illustrated
node 1 and node 4 are in domain A and C respectively and node 2,3 and
5 are all in domain B.
Generally, when the failure between domain A and B occurs, the
methodology would proceed as follows:
o The node 4 sends Channelstatus Message to node 3 indicating the
failure to the corresponding upstream node.
o Record the timestamp (T1) when the first bit of Channelstatus
Message is sent to the node 3 along the LSP.
o When node 3 receives the ChannelStatus message from node 4, it
returns a ChannelStatusAck message back to node 4 and correlates
the failure locally. When Node 3 correlates the failure and
verifies that the failure is clear, it has localized the failure
to the data link between Node 3 and node 4. At that time, Node 3
sends a ChannelStatus message to Node 4 indicating that the
failure has been localized.
o Record the timestamp (T2) when the last bit of ChannelStatus
message from node 3 is received by node 4.
o The fault localization delay is T2-T1.
Zhang, et al. Expires April 21, 2012 [Page 15]
Internet-Draft Survivability Evaluation Metric October 2011
o Measurement method of notification delay is the same to that of
fault reroute restoration within a domain in multi-domain network
as described in section 5.2.1.
o Notification delay is T4-T3.
o Record the timestamp (T5) after node 1 receives the PathErr
Message. Node 1 as the PSL computes a new path through either a
series of route algorithms or pre-computed scheme. Consider to
choose a backup path bypass the upstream domain of fault link if
the fault link is the only link between domain B and domain C.
o PATH and RESV signaling are responsible for path establishment
request and resource reservation respectively for a new backup
path. Then the traffic is switched from a working path to the
backup path. Record the timestamp (T6) when the first packet of
traffic arrives at the destination node (node 4) through the
backup path.
o Recovery time is T6-T5.
o The total fault restoration time is T2+T4+T6-T1-T3-T5.
| |
+-------+ | +-------+ +-------+ | +-------+
+ Node1 +-----|c----+ Node2 +--- c --+ Node3 +--- |c ---+ Node4 +
--+-------+-----|-----+-------+--------+-------+----|##---+-------+->
+ + | + +--| -+ + | + +
+-------+ | +-------+ | |+-------+ | +-------+
| | | | Domain C
| | | |
Domain A | | |--------| |
| \ +-------+ | |
| \ + Node5 +-| |
+ +
+ +
+-------+
Domain B
Figure 5: Inter-domain fault in multi-domain network(indicated by ##
in the figure)
Zhang, et al. Expires April 21, 2012 [Page 16]
Internet-Draft Survivability Evaluation Metric October 2011
6. Protocol Extension Requirements
It is assumed that clock of every control node is synchronous during
the process of measurement. Control plane reports different time to
NMS(Network Management System) which is responsible for computing the
sum of different fault restoration duration time. LMP and RSVP
extensions are required in order to record precise the start and end
time in every restoration phrase.
In the process of fault location measurement, detection entities send
alarm information to upstream neighbor node through signaling of LMP
when it detects the fault in control plane. It is necessary to
extend LMP by adding a FAULT_TIMESTAMP object as a timestamp in the
ChannelStatus Message. The FAULT_TIMESTAMP Object could be used to
record the time when the signaling is sent and received to measure
the precise fault location notification time. Then when the fault
notification is implemented, the fault indicating signal is delivered
to the PSL through the PathErr signal of RSVP. SEND_ERR_TIMESTAMP
and RECEIVE_ERR_TIMESTAMP Objects are added in PathErr signal and
defined to record the time of notification signal sent and received
by upstream node next to the fault and PSL respectively.
7. Security Considerations
As this document is solely for the purpose of providing metric
methodology and describes neither a protocol nor a protocol
implementation, there is no security considerations associated with
this document.
8. Acknowledgments
We wish to thank Jiuyu Xie, Yongli Zhao and Shengwei Meng for their
comments and help.
The RFC text was produced using Marshall Rose's xml2rfc tool.
9. Normative References
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource Reservation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
Zhang, et al. Expires April 21, 2012 [Page 17]
Internet-Draft Survivability Evaluation Metric October 2011
[RFC4204] Lang, Jonathan P., "Link Management Protocol (LMP)",
RFC 4204, October 2005.
[RFC4426] Lang, Jonathan P., "Generalized Multiprotocol 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.
[RFC4428] Papadimitriou, D. and E. Mannie, "A Backward-Recursive
PCE-Based Computation (BRPC) Procedure to Compute Shortest
Constrained Inter-Domain Traffic Engineering Label
Switched Paths", RFC 4428, March 2006.
Appendix A. Other Authors
1. Haiyi Zhang
MIIT
No.52 Hua Yuan Bei Lu,Haidian District
Beijing 100083
P.R.China
Phone: +861062300100
Email: Zhanghaiyi@mail.ritt.com.cn
Authors' Addresses
Min Zhang
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613910621756
Email: mzhang@bupt.edu.cn
URI: http://www.bupt.edu.cn
Zhang, et al. Expires April 21, 2012 [Page 18]
Internet-Draft Survivability Evaluation Metric October 2011
Lifang Zhang
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8615210889041
Email: capricorn7111@hotmail.com
URI: http://www.bupt.edu.cn/
Yuefeng Ji
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613701131345
Email: jyf@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Yunbin Xu
BUPT
No.52 Hua Yuan Bei Lu,Haidian District
Beijing 100083
P.R.China
Phone: +8613681485428
Email: xuyunbin@mail.ritt.com.cn
URI: http://www.catr.cn/
Yu Wang
CATR
No.52 Hua Yuan Bei Lu,Haidian District
Beijing 100083
P.R.China
Phone: +8613651161646
Email: wangyu@mail.ritt.com.cn
URI: http://www.catr.cn/
Zhang, et al. Expires April 21, 2012 [Page 19]