One document matched: draft-weingarten-mpls-tp-linear-protection-01.txt
Differences from draft-weingarten-mpls-tp-linear-protection-00.txt
MPLS Working Group S. Bryant
Internet Draft Cisco
Intended status: Standards Y. Weingarten
N. Sprecher
Nokia Siemens Networks
H. van Helvoort
Huawei
A. Fulignoli
Ericsson
Expires: September 2009 March 9, 2009
MPLS-TP Linear Protection
draft-weingarten-mpls-tp-linear-protection-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 9, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Weingarten et al. Expires September 9, 2009 [Page 1]
Internet-Draft MPLS-TP Linear Protection March 2009
(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.
Abstract
This document describes mechanisms for linear protection of Multi-
Protocol Label Switching Transport Profile (MPLS-TP) Label Switched
Paths (LSP) and Pseudowires (PW) on multiple layers. Linear
protection provides a fast and simple protection switching mechanism,
that is especially optimized for a mesh topology. It provides a
clear indication of the protection status. The mechanisms are
described both at the architectural level as well as providing a
protocol that is used to control and coordinate the protection
switching.
Table of Contents
1. Introduction...............................................3
1.1. Contributing Authors .................................4
2. Conventions used in this document..........................4
2.1. Abbreviations.........................................4
2.2. Definitions and terminology...........................5
3. Network objectives.........................................5
4. Protection architectures...................................6
4.1. 1+1 Protection architecture...........................6
4.2. 1:1 Protection architecture...........................7
4.3. Protection of P2MP networks...........................8
4.4. Extension to 1:n protection...........................8
4.5. Revertive and Non-revertive switching.................9
5. Protection switching trigger mechanisms....................9
5.1. Hold-off timer...................................... 10
5.2. Protection switching control logical architecture... 10
6. Protection switching coordination (PSC) protocol......... 12
6.1. Protocol format .................................... 12
6.1.1. PSC Requests................................... 14
6.1.1.1. Interaction between requests ............. 15
6.1.2. Path fault identifier.......................... 15
6.1.3. Active path indicator.......................... 15
6.1.4. Current protection type........................ 16
6.2. Addressing of PSC requests.......................... 16
Weingarten et al. Expires September 9, 2009 [Page 2]
Internet-Draft MPLS-TP Linear Protection March 2009
6.3. Principles of operation............................. 16
6.3.1. Normal state................................... 17
6.3.2. Failure or Degraded condition.................. 17
6.3.3. Lockout of protection.......................... 18
6.3.4. Operator controlled switching.................. 18
6.3.5. Recovery from switching........................ 19
6.3.5.1. Wait-to-restore timer..................... 20
7. Security Considerations.................................. 20
8. IANA Considerations...................................... 20
9. Acknowledgments.......................................... 20
10. References ............................................. 21
10.1. Normative References............................... 21
10.2. Informative References............................. 21
1. Introduction
As noted in the architecture for MPLS-TP [7], the overall
architecture framework for MPLS-TP is based on a profile of the MPLS
and PW procedures as specified for the MPLS and (MS-)PW architectures
defined in RFC 3031 [3], RFC 3985 [5] and [6]. One of the basic
survivability functions, pointed out by the Survivability Framework
document [11], is that of simple and rapid protection switching
mechanisms for Label Switched Paths (LSP) and Pseudo-wires (PW).
Protection switching is a fully allocated survivability mechanism. It
is fully allocated in the sense that the route and bandwidth of the
recovery path is reserved for a selected working path. It provides a
fast and simple survivability mechanism that allows the network
operator to easily grasp the active state of the network compared to
other survivability mechanisms.
This draft proposes an architecture and protocol to provide
protection for the different types of point-to-point (p2p) paths
supported by MPLS-TP. These include LSP, PW, Path Segment Tunnels
(PST), and Tandem Connections (TC). For unidirectional protection
switching a 1+1 architecture is described. For bidirectional
switching both a 1+1 and a 1:1 architecture are described.
In 1+1 unidirectional architecture, a recovery transport path is
dedicated to each working transport path. Normal traffic is bridged
and fed to both the working and the recovery transport entities by a
permanent bridge at the source of the protection domain. The sink of
the protection domain selects which of the working or recovery
entities to receive the traffic from, based on a predetermined
criteria, e.g. server defect indication. When used for bidirectional
switching the 1+1 protection architecture must also support a
Protection Switching Coordination (PSC) protocol. This protocol is
Weingarten et al. Expires September 9, 2009 [Page 3]
Internet-Draft MPLS-TP Linear Protection March 2009
used to help synchronize the decisions of both ends of the protection
domain in selecting the proper traffic flow.
In the 1:1 architecture, a recovery transport path is dedicated to
the working transport path. However, the normal traffic is
transmitted only once, on either the working or the recovery path, by
using a selector bridge at the source of the protection domain. A
selector at the sink of the protection domain then selects the path
that carries the normal traffic. Since the source and sink need to
be coordinated to ensure that the selector bridge at both ends select
the same path, this architecture must support the PSC protocol.
1.1. Contributing Authors
John Drake, Hao Long
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 [1].
2.1. Abbreviations
DNR Do Not Revert
FS Forced Switch
LSR Label Switching Relay
MS Manual Switch
P2P Point to point
P2MP Point to multipoint
PSC Protection Switching Coordination Protocol
PST Path Segment Tunnel
SD Signal Degrade
SF Signal Fail
SLA Service Level Agreement
WTR Wait-to-Restore
Weingarten et al. Expires September 9, 2009 [Page 4]
Internet-Draft MPLS-TP Linear Protection March 2009
2.2. Definitions and terminology
Protection domain: Transport path (e.g. LSP, PW, PST, TC) that
provides protection for its normal traffic. The protection domain
consists of the following elements - Two end points (East and West)
that in each direction one acts as the source and the other as the
sink, a working path, and a recovery path.
Recovery path: A transport path that is dedicated to transport normal
user traffic in case of a failure of the Working path.
Working path: A transport path that is used for transport of normal
user traffic, under normal conditions.
The terminology used in this document is based on the terminology
defined in [10]. In addition, we use the term LSR to refer to a
MPLS-TP Network Element, whether it is a LSR, LER, T-PE, or S-PE.
3. Network objectives
Linear protection for MPLS-TP should comply with the following
network objectives:
. Switch time: protection switching should operate as fast as
possible. A switching time of less than 50ms has been proposed
as a target for certain use cases. The switching time does not
include the detection time and the hold-off time
. Hold-off times: to allow protection by the layer that is closest
to the detected defect and retain the stability of the network,
a hold-off timer should be employed when a defect is detected.
At the expiration of the hold-off period, the defect should be
rechecked and if still existing the protection mechanism shall
be invoked.
. Extent of protection: the protection mechanism should restore
interrupted traffic due to a facility (link or node) failure,
within a protection domain. Traffic terminating at a failed
node may be disrupted, however, traffic passing through to other
nodes should be protected.
. Operation modes: the protection mechanism should provide
protection for both unidirectional and bidirectional transport
entities. The protection mechanism should support both
revertive and non-revertive modes of operation.
Weingarten et al. Expires September 9, 2009 [Page 5]
Internet-Draft MPLS-TP Linear Protection March 2009
. Manual control: administrative commands may be provided for
manual control of the protection switching operations. The
following are examples of possible manual commands: Clear,
Forced Switch, Manual Switch (see definitions in [10]).
4. Protection architectures
The protection mechanism defined here supports transport paths (as
defined in [2]) within a mesh-based network. This includes support
for unidirectional, both point-to-point and point-to-multipoint, and
bidirectional point-to-point paths. This protection may be supported
by different protection architectures as described in the following
subsections.
4.1. 1+1 Protection architecture
The 1+1 protection architecture provides for a fully dedicated
recovery path in addition to the configured working path. Both the
recovery and working path must support the full SLA requirements for
the traffic between the two end points of the protection domain.
In this architecture (see figure 1), all traffic from LSR A to LSR Z
is bridged, using the permanent bridge at LSR A, to both transport
entities, and LSR Z employs a selector bridge to receive the data
from the working path, discarding the packets from the recovery path.
In case of a condition, e.g. a failure condition or an operator
command, where protection switching is indicated, LSR Z SHOULD select
the data packets from the recovery path and discard any data packets
from the working path.
It should be further noted that OAM packets for monitoring the
protection domain, or control plane packets, may be transmitted on
the "non-active" transport path. These packets SHALL NOT be
discarded.
|-------------Protection Domain-----------------|
==============================
/**********Working path************\
+--------+ ============================== +--------+
| LSR /| |\ LSR |
| A {< | | >} Z |
| PB \| | SB |
+--------+ ============================== +--------+
\***********Recovery path***********/
==============================
Weingarten et al. Expires September 9, 2009 [Page 6]
Internet-Draft MPLS-TP Linear Protection March 2009
PB: Permanent Bridge SB: Selector Bridge
Figure 1: 1+1 Unidirectional protection architecture
When using the 1+1 architecture for bidirectional switching, each of
the end-points would have both a permanent bridge and a selector
bridge one for each direction.
4.2. 1:1 Protection architecture
Another option to protect either a unidirectional or bidirectional
connection is a 1:1 architecture. This architecture provides for a
fully allocated recovery transport path in addition to the working
transport path used for normal user data. In principle, this
recovery path MUST support the full capacity and bandwidth of the SLA
but may be degraded from the normal working path.
|-------------Protection Domain-----------------|
==============================
/**********Working path***********\
+--------+ ============================== +--------+
| LSR /| |\ LSR |
| A {< | | >} Z |
| SB | | SB |
+--------+ ============================== +--------+
Recovery path
==============================
SB: Selector Bridge
Figure 2: 1:1 Bidirectional protection architecture using working
path
In this architecture both ends of the protection domain have a
Selector bridge (SB) that selects the transport path to transmit the
data packets over. Under normal conditions the SB selects the
working path for transmission of the data packets. When a condition
that triggers protection switching is active, the SB selects the
recovery path for data transmission.
In principle, the recovery path could be used for "extra traffic",
i.e. preemptible traffic. However, if protection switching is in
force then this traffic SHALL be pre-empted by the protected data
that is being transmitted on this path. In any case, the recovery
path MUST support OAM and protection coordination traffic (see
section 6).
Weingarten et al. Expires September 9, 2009 [Page 7]
Internet-Draft MPLS-TP Linear Protection March 2009
This architecture requires communication between the end-points of
the protection domain to coordinate the protection state. In general
bidirectional protection switching requires coordination between the
end-points and verification that both transmission directions remain
on a corouted bidirectional path.
4.3. Protection of P2MP networks
[2] specifies that all P2MP MPLS-TP connections are unidirectional by
nature. It further requires that these connections should be
supported by both 1+1 and 1:1 protection architectures.
When protecting a P2MP network using a 1+1 protection architecture,
the basic protection mechanism is still relevant. The root LSR will
bridge the user traffic (using a permanent bridge) to both the
working and recovery transport entities. Each leaf LSR will select
the traffic from one transport path according to its own local
triggers. This may lead to a situation where, due to a failure
condition on one branch of the network, that some leaf LSRs may
select the working transport path, while other leaf LSRs may select
traffic from the recovery transport path.
When protecting a P2MP network using 1:1 protection architecture,
there is a need for the root LSR to identify the existence of a
failure condition on any of the branches of the network.
Editor's note: This requires the use tools from the OAM toolset [9],
and also a return path that can pass the indication back to the root
LSR. This protection architecture, in the P2MP case, also requires
that each leaf LSR selects the traffic from the incoming transport
entities based local logic. When protection switching is triggered,
the root LSR selects the recovery transport path to transfer the
traffic and each leaf LSR continues to select the proper
transmission. Endof Editor's note!!
4.4. Extension to 1:n protection
This is for further study
Editor's note: definition of 1:n protection should be that there is
one recovery path that is given a different label relative to each
working path that is being protected. When any one of the working
paths indicates a failure, then the traffic is redirected to the
recovery path, using the dedicated recovery label. When more than
one working path reports a failure, then the path with the highest
priority will have its traffic redirected to the recovery path and
traffic from other paths will not be protected. It should be noted
Weingarten et al. Expires September 9, 2009 [Page 8]
Internet-Draft MPLS-TP Linear Protection March 2009
further that 1:n protection cannot be supported using a single phase
protocol, since the coordination of which is the highest priority
path and notification to other paths needs acknowledgement, i.e. at
least a second phase.
There is a suggestion to have a separate draft for the extension to
1:n protection, that would include a definition to the two-phased
protocol. This draft should only prepare the groundwork of the
protocol so as not to preclude the 1:n protection.
This is still under discussion Endof Editor's note
4.5. Revertive and Non-revertive switching
In revertive operation, the normal traffic signal is restored to the
working transport path after the condition that triggered the
switching has cleared. When a manual operator command (e.g. Forced
Switch) has cleared, then the reversion happens immediately. When a
failure or degradation of service has cleared, the reversion may be
delayed until the expiry of a Wait-to-restore timer, used to
neutralize the effect of intermittent defects.
In non-revertive mode of operation, the normal traffic continues to
use the recovery transport path, even after the condition that
triggered has cleared. Eventually, the network may be reverted to
use the working transport path, by using an explicit operator command
(see section 6.3.5).
The 1+1 protection architecture is often provisioned to operate as
non-revertive, since the recovery transport path is fully dedicated
in any case and continuing to select it on the sink avoids a second
disturbance to the traffic. There may, however, be certain operator
policies that dictate provisioning revertive operation for 1+1
protection.
The 1:1 protection architecture is often provisioned to operate in
revertive mode. This takes advantage of the (typically) more
optimized working transport path, even at the cost of the additional
disturbance to traffic from the additional switch.
In principle, the configuration of revertive or non-revertive
operation should be the same at both ends of the protection domain.
5. Protection switching trigger mechanisms
The protection switching should be initiated in reaction to any of
the following triggers:
Weingarten et al. Expires September 9, 2009 [Page 9]
Internet-Draft MPLS-TP Linear Protection March 2009
. Server layer indication - if any of the lower layers (e.g. the
physical layer) raises an interrupt indicating that a failure
has been detected.
. OAM signalling - if the OAM continuity and connectivity
verification tools detect that there is a loss of continuity or
mis-connectivity or the performance monitoring indicates a
degradation of the utility of the working path for the current
transport path. In cases of signal degradation, switching to
the recovery path SHOULD only be activated if the recovery path
can guarantee better conditions than the degraded working path.
. Control plane - if there is a control plane active in the
network (either signalling or routing), it may send an
indication of problems on the working path. Protection
switching should be initiated as a result, until the problems
are signalled to have cleared.
. Operator command - the network operator may issue commands that
trigger protection switching. The commands that are supported
include - Forced Switch, Manual Switch, Clear, Lockout of
Protection, (see definitions in [10]).
5.1. Hold-off timer
In order to coordinate timing of protection switches at multiple
layers, a hold-off timer may be required. Its purpose is to allow,
for example, a server layer protection switch to have a chance to fix
the problem before switching at a client layer.
Each protection group should have a provisionable holdoff timer. The
suggested range of the holdoff timer is 0 to 10 seconds in steps of
100 ms with an accuracy within 5 ms. The default duration for the
holdoff timer is 0 seconds.
When a failure condition is detected, this will not immediately
activate protection switching if the provisioned hold-off timer value
is non-zero. Rather, the hold-off timer will be started. When the
hold-off timer expires, we check if a failure condition is still
present. If there is still a failure condition, then the protection
switching is activated, regardless if it is the same failure
condition that caused the activation the hold-off timer.
5.2. Protection switching control logical architecture
Protection switching processes the triggers described above together
with the inputs received from the far-end LSR. These inputs cause
Weingarten et al. Expires September 9, 2009 [Page 10]
Internet-Draft MPLS-TP Linear Protection March 2009
the LSR to take certain actions, e.g. switching the Selector Bridge
to select the working or recovery path, and to transmit different
protocol messages.
+-------------+ Operator Command Local PSC +-----------+
| External |-----------------+ +-----------------| PSC Status|
| Interface | | | request +---| Module |
+-------------+ | | | +-----------+
V V V Prot. Stat. ^
+----------+ Local OAM +---------------+Highest +------------+ |
| OAM |----------->| Local Request |------->| PSC Mess. | |
| Module | request | logic |local R.| Generator | |
+----------+ +---------------+ +------------+ |
| | |
Highest local request| | |
V V |
+-------------+ +-----------------+ PSC Message |
| Remote Req. | Remote PSC | global Request | |
| Receiver |------------>| logic | |
+-------------+ Request +-----------------+ |
^ | |
| Highest global request| |
| V |
| +-----------------+ PSC status |
Remote PSC message | PSC Process |-----------------+
| logic |--------> Action
| |
+-----------------+
Figure 3: Protection switching control logic
Figure 3 describes the logical architecture of the protection
switching control. The Local Request logic unit accepts the triggers
from the OAM, external operator commands, and from the local control
plane (when present) and determines the highest priority request.
This high-priority request is passed to both the PSC Message
generator, that will generate the appropriate protocol message to be
sent to the far-end LSR, and the Global Request logic, that will
cross-check this local request with the information received from the
far-LSR. The Global Request logic then processes these two PSC
requests that determines the highest priority request that is passed
to the PSC Process logic. The PSC Process logic uses this input to
determine what actions need to be taken, e.g. switching the Selector
Bridge, and the current status of the protection domain.
Weingarten et al. Expires September 9, 2009 [Page 11]
Internet-Draft MPLS-TP Linear Protection March 2009
6. Protection switching coordination (PSC) protocol
Bidirectional protection switching requires coordination between the
two end-points in determining which of the two possible paths, the
working or recovery path, is operational in any given situation.
When protection switching is triggered as described in section 5, the
end-points must inform each other of the switch-over from one path to
the other in a coordinated fashion.
There are different possibilities for the type of coordinating
protocol. One possibility is a two-phased coordination in which the
MEP that is initiating the protection switching sends a protocol
message indicating the switch but the actual switch-over is performed
only after receiving an 'Ack' from the far-end MEP. The other
possibility is a single-phased coordination in which the initiating
MEP switches over to the alternate path and informs the far-end of
the switch, and the far-end must complete the switch-over.
In the following sub-sections we describe the protocol messages that
should be used between the two end-points of the protection domain.
For the sake of simplicity of the protocol, this protocol is based on
the single-phase approach described above.
The protocol messages should be transmitted over the recovery path
only. This allows the transmission of the messages without affecting
the normal traffic in the most prevalent case, i.e. the idle state.
In addition, limiting the transmission to a single path avoids
possible conflicts and race conditions that could develop if the PSC
messages were sent on both paths.
6.1. Protocol format
The protocol messages SHALL be sent over the GACH as described in
[8]. There is a single channel type for the set of PSC messages,
each message will be identified by the first field of the ACH payload
as described below. PSC messages SHOULD support addressing by use of
the method described in [ACH-TLV]. The following figure shows the
format for the full PSC message.
Weingarten et al. Expires September 9, 2009 [Page 12]
Internet-Draft MPLS-TP Linear Protection March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP PSC Channel Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Addressing TLV +
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ PSC Controlmessage ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Format of PSC packet with a GACH header
Where:
. MPLS-TP PSC Channel Code is the GACH channel number assigned to the
PSC = TBD
. The ACH TLV Header is described in [ACHTLV]
. The use of the Addressing TLV are described in section 6.2
. The following figure shows the format of the PSC Control message
that is the payload for the PSC packet.
Editor's note: There is a suggestion that this format should be
aligned with the format used by G.8031/G.8131/Y.1731 in ITU. The
argument being that this would make it easier to pass review from ITU
and allow easier transfer of technology.
The counter-argument is that the ITU format is based upon an attempt
to find a common format for different functionality and therefore
involves different fields that are not necessary for the protection
switching. Defining a new dedicated format would make for a simpler
and more intuitive protocol.
This is still under discussion Endof Editor's note.
Weingarten et al. Expires September 9, 2009 [Page 13]
Internet-Draft MPLS-TP Linear Protection March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |Request|F|Typ| Path | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Format of the PSC Control packet
Where:
. Ver: is the version of the protocol, for this version the value
SHOULD be 0.
. Request: this field indicates the specific PSC request that is
being transmitted, the details are described in section 6.1.1
. Path: used to indicate the currently active path, possible values
are described in section 6.1.3
. F: used to indicate the path that is reporting a failure condition,
the possible values are described in section 6.1.2
. Typ: indicates the type of protection scheme currently supported,
more details are given in section 6.1.4
6.1.1. PSC Requests
The Protection Switching Coordination (PSC) protocol SHALL support
the following request types, in order of priority from highest to
lowest:
. (1111) Clear
. (1110) Lockout protection
. (1101) Forced switch
. (0110) Signal fault
. (0101) Signal degrade
. (0100) Manual switch
. (0011) Wait to restore
. (0010) Do not revert (DNR)
. (0000) No request
Weingarten et al. Expires September 9, 2009 [Page 14]
Internet-Draft MPLS-TP Linear Protection March 2009
See section 6.3 for a description of the operation of the different
requests
6.1.1.1. Interaction between requests
The following rules SHOULD be observed for interaction between
different requests:
. If the protection domain is currently in a protecting state,
i.e. normal traffic is being transmitted over the recovery path
as a result of a trigger, then the LSRs SHOULD NOT accept a
Manual Switch request.
. If the protection domain is currently in a protecting state,
i.e. normal traffic is being transmitted over the recovery path
as a result of a trigger, and a Forced Switch is requested then
the normal traffic SHALL continue to be transmitted on the
recovery path even if the original protection trigger is
cleared.
. If a Signal Degrade request is received, then protection
switching will be activated only if the recovery path can
guarantee a better signal than the working path. Editor's
note: Do we need to define the method of comparison or is this
out of scope? Endof Editor's note
. If the Clear request is issued in the absence of a Manual
Switch, Forced Switch, Freeze, or Lockout protection, then it
SHALL be ignored. In the presence of any of these commands,
the Clear request SHALL clear the state affected by the
operator command.
6.1.2. Path fault identifier
The F-bit of the PSC control SHALL be used only in a Signal fault
(0101) or Signal degrade (0100) control packet. Its value indicates
on which path the signal anomaly was detected. The following are the
possible values:
. 0: indicates the Recovery path
. 1: indicates the Working path
6.1.3. Active path indicator
The Path field of the PSC control SHALL be used to indicate which
path the source MEP is currently using for data transmission. The
Weingarten et al. Expires September 9, 2009 [Page 15]
Internet-Draft MPLS-TP Linear Protection March 2009
MEP should compare the value of this bit with the path that is
locally selected for data transmission to verify that there is no
inconsistency between the two end-points of the protected domain. If
an inconsistency is detected then an alarm should be raised. The
following are the possible values:
. 0: indicates the Recovery path
. 1: indicates the Working path
. 2-255: for future extensions
. Possibility of extension for 1:n protection would change the
interpretation of this field, where 0 indicates that all normal
traffic is being carried on the working paths, a value other than 0
indicates that the recovery path is being used to transmit normal
traffic for the path indicated, e.g. if we define this field to be
8 bits then a value of 102 would indicate that recovery path is
currently carrying traffic that was intended for the failed path
102.
6.1.4. Current protection type
The Typ field indicates the currently configured protection
architecture type, this should be validated to be consistent for both
ends of the protected domain. If an inconsistency is detected then an
alarm should be raised. The following are the possible values:
. 11: 1+1 bidirectional switching
. 10: 1:1 bidirectional switching
. 01: 1+1 unidirectional switching
. 00: 1:1 unidirectional switching
6.2. Addressing of PSC requests
To be incorporated in a future revision of this document
6.3. Principles of operation
In all of the following sub-sections, assume a protected domain
between LSR-A and LSR-Z, using paths W (working) and R (recovery).
Weingarten et al. Expires September 9, 2009 [Page 16]
Internet-Draft MPLS-TP Linear Protection March 2009
6.3.1. Normal state
When the protected domain has no special condition in effect, the
ingress LSR SHOULD forward the user data along the working path, and
in the case of 1+1 protection the Permanent Bridge will bridge the
data to the recovery path as well. The receiving LSR SHOULD read the
data from the working path.
The ingress LSR MAY transmit a No Request PSC packet with the P-bit
set to 0 for the recovery path.
6.3.2. Failure or Degraded condition
If one of the LSRs (for example, LSR-A) detects a failure condition
or a serious degradation condition on the working path that warrants
invoking protection switching, then it SHOULD take the following
actions:
. Switch all traffic for LSR-Z to the recovery path only.
. Transmit a PCS control packet, using GACH, with the appropriate
Request code (either Signal fault or Signal degrade), the F-bit
set to 0, to indicate that the fault/degrade was detected on
the working path, and the P-bit set to 1, indicating that
traffic is now being forwarded on the recovery path. This
transmission should be repeated every xx ms for the duration of
the failure/degrade condition.
. Verify that LSR-Z replies with a PCS control packet indicating
that it has switched to the recovery path. If this is not
received after xxx then send an alarm to the management system.
When the far-end LSR (in this example LSR-Z) receives the PCS packet
informing it that other LSR (LSR-A) has switched, it SHOULD perform
the following actions:
. Check priority of the request
. Switch all traffic addressed to LSR-A to the recovery path
only.
. Begin transmission of a PCS control packet, using GACH, with
the appropriate Request code (either Signal fault or Signal
degrade), the F-bit set to 0, to indicate that the
fault/degrade was detected on the working path, and the P-bit
set to 1, indicating that traffic is now being forwarded on the
Weingarten et al. Expires September 9, 2009 [Page 17]
Internet-Draft MPLS-TP Linear Protection March 2009
recovery path. This transmission should be repeated every xx
ms for the duration of the failure/degrade condition.
6.3.3. Lockout of protection
If one of the LSRs (for example, LSR-A) receives a management command
indicating that the protection is disabled, then it SHOULD indicate
this to the far-end LSR (for example, LSR-Z) that it is not possible
to use the recovery path. The following actions MUST be taken:
. Transmit a PCS control packet, using GACH, with the Request
code set to Lockout of protection (1010), the F-bit set to 1,
and the P-bit set to 0.
. All normal traffic packets should be transmitted on the working
path only.
. Verify that the far-end LSR (for example LSR-Z) is forwarding
the data packets on the working path. Raise alarm in case of
mismatch.
When the far-end LSR (in this example LSR-Z) receives the PCS packet
informing it that other LSR (LSR-A) has switched, it SHOULD perform
the following actions:
. Check priority of request
. Switch all normal traffic addressed to LSR-A to the working
path only.
. Begin transmission of a PCS control packet, using GACH, with
the appropriate Request code (Lockout of protection), the F-bit
set to 1, and the P-bit set to 0, indicating that traffic is
now being forwarded on the working path only. This
transmission should be repeated every xx ms for the duration of
the lockout condition.
6.3.4. Operator controlled switching
If the management system indicated to one of the LSRs (for example
LSR-A) that a switch is necessary, e.g. either a Forced Switch or a
Manual Switch, then the LSR SHOULD switch the traffic to the recovery
path and perform the following actions:
. Switch all data traffic to the recovery path only.
Weingarten et al. Expires September 9, 2009 [Page 18]
Internet-Draft MPLS-TP Linear Protection March 2009
. Transmit a PCS control packet, using GACH, with the appropriate
Request code (either Manual switch or Forced switch), the F-bit
set to 0, to indicate that the fault/degrade was detected on
the working path, and the P-bit set to 1, indicating that
traffic is now being forwarded on the recovery path. This
transmission should be repeated every xx ms for the duration of
the switch condition.
. Verify that LSR-Z replies with a PCS control packet indicating
that it has switched to the recovery path. If this is not
received after xxx then send an alarm to the management system.
When the far-end LSR (in this example LSR-Z) receives the PCS packet
informing it that other LSR (LSR-A) has switched, it SHOULD perform
the following actions:
. Check priority of the request
. Switch all normal traffic addressed to LSR-A to the recovery
path only.
. Begin transmission of a PCS control packet, using GACH, with
the appropriate Request code (either Manual switch of Forced
switch), the F-bit set to 0, to indicate that the fault/degrade
was detected on the working path, and the P-bit set to 1,
indicating that traffic is now being forwarded on the recovery
path. This transmission should be repeated every xx ms for the
duration of the switch condition.
6.3.5. Recovery from switching
When the condition that triggered the protection switching clears,
e.g. the cause of the failure condition has been corrected, the
operator clears a Manual Switch, then the protection domain SHOULD
follow the following procedures:
. If the network is configured for non-revertive behaviour, then
the two LSRs SHOULD transmit DNR (Request code 0010) messages.
When the operator clears the non-revertive condition, the two
LSRs SHOULD return to use of the working transport path and
transmit No request (Request code 0000) messages.
. If the network is recovering from an operator switching command
(in revertive mode), then both LSRs SHOULD return to using the
working transport path and transmit No request (Request code
0000) messages.
Weingarten et al. Expires September 9, 2009 [Page 19]
Internet-Draft MPLS-TP Linear Protection March 2009
. If the network is recovering from a failure or degraded
condition (in revertive mode), then the LSR that detects this
recovery SHALL activate a local Wait-to-restore (WTR) timer
(see section 6.3.5.1) to verify that there is not an
intermittent failure. After the WTR expires, the LSR SHOULD
return to using the working transport path and transmit No
request (Request code 0000) messages.
6.3.5.1. Wait-to-restore timer
In revertive mode, in order to prevent frequent activation of
protection switching due to an intermittent defect, the working
transport path must become stable and fault-free before reverting to
the normal condition. In order to verify that this is the case a
fixed period of time must elapse before the normal traffic uses the
working transport path. This period, called the WTR period, should
be configurable by the operator in 1-minute intervals within the
range 1-12 minutes. The default value is 5 minutes.
During this period, if a failure condition is detected on the working
transport path, then the WTR timer is stopped and the normal traffic
SHALL continue to be transported over the recovery transport path.
If the WTR timer expires without being pre-empted by a failure, then
the traffic SHOULD be returned to use the working transport path (as
above).
7. Security Considerations
To be incorporated in a future revision of this document
8. IANA Considerations
To be incorporated in a future revision of this document
9. Acknowledgments
The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the
T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS Transport Profile.
This document was prepared using 2-Word-v2.0.template.dot.
Weingarten et al. Expires September 9, 2009 [Page 20]
Internet-Draft MPLS-TP Linear Protection March 2009
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[2] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
Ueno, S., "MPLS TP Requirements", draft-jenkins-mpls-tp-
requirements-04, Feb 2009
10.2. Informative References
[3] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001
[4] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032,
January 2001
[5] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985, March 2005
[6] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007
[7] Bocci, M., et al., " A Framework for MPLS in Transport
Networks", draft-blb-mpls-tp-framework-00 (work in
progress), July 2008
[8] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal,
R., " MPLS Generic Associated Channel ", draft-bocci-mpls-
tp-gach-gal-00, October 2008
[9] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", draft-vigoureux-mpls-tp-oam-
requirements-00, July 2008
[10] Mannie, E., Papadimitriou, D., "Recovery Terminology for
Generalized Multi-Protocol Label Switching", RFC 4427,
March 2006
[11] Sprecher, N., Farrel, A., Kompella, V., "Multi-protocol
Label Switching Transport Profile Survivability Framework",
draft-sprecher-mpls-tp-survive-fwk-01", Feb 2009
Weingarten et al. Expires September 9, 2009 [Page 21]
Internet-Draft MPLS-TP Linear Protection March 2009
Authors' Addresses
Stewart Bryant
Cisco Systems
Email: stbryant@cisco.com
Nurit Sprecher
Nokia Siemens Networks
Email: nurit.sprecher@nsn.com
Yaacov Weingarten
Nokia Siemens Networks
Email: yaacov.weingarten@nsn.com
Annamaria Fulignoli
Ericsson
Email: annamaria.fulignoli@ericsson.com
Huub van Helvoort
Huawei
Email: hhelvoort@huawei.com
Contributing Authors' Addresses
John E. Drake
Boeing Corporation
Email: John.E.Drake2@boeing.com
Hao Long
Huawei
Email: lonho@huawei.com
Weingarten et al. Expires September 9, 2009 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-24 01:27:42 |