One document matched: draft-weingarten-mpls-tp-linear-protection-04.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-weingarten-mpls-tp-linear-protection-04.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="MPLS-TP LP">MPLS-TP Linear Protection</title>
<author fullname="Stewart Bryant" initials="S." role="editor"
surname="Bryant">
<organization>Cisco</organization>
<address>
<postal>
<street />
<region />
<code />
<country>United Kingdom</country>
</postal>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="Nurit Sprecher" initials="N." role="editor" surname="Sprecher">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<region />
<code>45241</code>
<country>Israel</country>
</postal>
<email>nurit.sprecher@nsn.com</email>
</address>
</author>
<author fullname="Huub van Helvoort" initials="H." role="editor" surname="van Helvoort">
<organization>Huawei</organization>
<address>
<postal>
<street>Kolkgriend 38, 1356 BC Almere</street>
<city></city>
<region />
<code></code>
<country>Netherlands</country>
</postal>
<email>hhelvoort@huawei.com</email>
<phone>+31 36 5316076</phone>
</address>
</author>
<author fullname="Annamaria Fulignoli" initials="A." role="editor" surname="Fulignoli">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city></city>
<region />
<code></code>
<country>Italy</country>
</postal>
<email>annamaria.fulignoli@ericsson.com</email>
<phone></phone>
</address>
</author>
<author fullname="Yaacov Weingarten" initials="Y." role="" surname="Weingarten">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>3 Hanagar St. Neve Ne'eman B</street>
<city>Hod Hasharon</city>
<region />
<code>45241</code>
<country>Israel</country>
</postal>
<email>yaacov.weingarten@nsn.com</email>
<phone>+972-9-775 1827</phone>
</address>
</author>
<date year="2009" />
<abstract>
<t>The MPLS Transport Profile (MPLS-TP) being specified jointly by IETF and ITU-T
includes requirements documents and framework documents. The framework documents
define the basic architecture that is needed in order to support various aspects
of the required behavior. This document addresses the functionality described in
the Survivability Framework document <xref target='11' /> and defines a protocol that may be used
to fulfill the function of the Protection State Coordination for linear protection,
as described in that document.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>As noted in the architecture for Multi-Protocol Label Switching Transport
Profile (MPLS-TP) <xref target='7'/>, the overall architecture framework for
MPLS-TP is based on a profile of the MPLS and Pseudowire (PW) procedures as
specified for the MPLS and (MS-)PW architectures defined in RFC 3031
<xref target='3'/>, RFC 3985 <xref target='5' /> and <xref target='6' />. One
of the basic survivability functions, pointed out by the Survivability Framework
document <xref target='11' />, is that of simple and rapid protection switching
mechanisms for Label Switched Paths (LSP) and Pseudo-wires (PW).</t>
<t>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.</t>
<t>As specified in the Survivability Framework document <xref target='11' />, protection
switching is applied to a protection domain. For the purposes of this document,
we define the protection domain of a P2P LSP as consisting of two Label Switching
Relays (LSR) and the transport paths that connect them. For a P2MP LSP the protection
domain includes the root (or source) LSR, the destination (or sink) LSRs, and the transport
paths that connect them.</t>
<t>In 1+1 unidirectional architecture as presented in <xref target='11'/>, 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 State Coordination (PSC)
protocol. This protocol is used to help synchronize the decisions of both ends of
the protection domain in selecting the proper traffic flow.</t>
<t>In the 1:1 architecture, a recovery transport path is dedicated to the working
transport path of a single service. 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.</t>
<t>The 1:n protection architecture extends this last architecture by sharing the
recovery path amongst n services. Again, the recovery path is fully allocated and
disjoint from any of the n working transport paths that it is being used to protect.
The normal data traffic for each service is transmitted only once, either on the normal
working path for that service or, in cases that trigger protection switching (as defined
in <xref target='11'/>) may be sent on the recovery path. It should be noted that in cases where
multiple working path services have triggered protection switching that some services,
dependent upon their Service Level Agreement (SLA), may not be transmitted as a result
of limited resources on the recovery path. In this architecture there is a need for
coordination of the protection switching, and in addition there is need for resource
allocation negotiation. Due to the added complexity of this architecture, the
procedures for this will be delayed to a different document and further study.</t>
<t>As was pointed out in the Survivability Framework <xref target='11'/> and highlighted
above, there is a need for coordination between the end-points of the protection domain
when employing bidirectional protection schemes. This is especially true when there is
a need to maintain traffic over a co-routed bidirectional LSP. This document presents
a protocol and a set of procedures for activating this coordination within the protection
domain.</t>
<section title="Contributing authors">
<t>Hao Long (Huawei)</t>
</section>
</section>
<section title="Conventions used in this document">
<t>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 <xref target='1' />.</t>
<section title="Acronyms">
<texttable>
<preamble>This draft uses the following acronyms:</preamble>
<ttcol align="left"/>
<ttcol align="left"/>
<c>DNR</c><c>Do not revert</c>
<c>FS</c><c>Forced Switch</c>
<c>GACH</c><c>Generic Associated Channel Header</c>
<c>LSR</c><c>Label Switching relay</c>
<c>MPLS-TP</c><c>Transport Profile for MPLS</c>
<c>MS</c><c>Manual Switch</c>
<c>P2P</c><c>Point-to-point</c>
<c>P2MP</c><c>Point-to-multipoint</c>
<c>PDU</c><c>Packet Data Unit</c>
<c>PSC</c><c>Protection State Coordination Protocol</c>
<c>PST</c><c>Path Segment Tunnel</c>
<c>SD</c><c>Signal Degrade</c>
<c>SF</c><c>Signal Fail</c>
<c>SLA</c><c>Service Level Agreement</c>
<c>WTR</c><c>Wait-to-Restore</c>
</texttable>
</section>
<section title="Definitions and Terminology">
<t>The terminology used in this document is based on the terminology defined in
<xref target='10' /> and further adapted for MPLS-TP in <xref target='11' />. . 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.</t>
</section>
</section>
<section title="Protection switching logic">
<section title="Protection switching trigger mechanisms">
<t>The protection switching should be initiated in reaction to any of the following
triggers:</t>
<t>
<list style="symbols">
<t>Server layer indication – if any of the lower layers (e.g. the physical
layer) notifies the MPLS-TP layer that a failure has been detected.</t>
<t>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.</t>
<t>Control plane – if there is a control plane active in the network (either
signalling or routing), it MAY trigger protection switching based on conditions
detected by the control plane. If the control-plane is based on GMPLS
<xref target='13' /> then the recovery process should comply with the process
described in <xref target='12' />.</t>
<t>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 <xref target='10' />).</t>
</list> </t>
</section>
<section title="Protection switching control logical architecture">
<t>Protection switching processes the triggers described above together with the
inputs received from the far-end LSR. These inputs cause 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.</t>
<figure anchor="figure 1" title="Protection switching control logic">
<artwork>
+-------------+ 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 | |
+----------+ +------->+---------------+ +------------+ |
+----------+ | | | |
| Svr/CP |---+ 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
| |
+-----------------+
</artwork>
</figure>
<t><xref target="figure 1" /> 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.</t>
<section title="PSC Status Module">
<t>The PSC Control Logic must retain the status of the protection domain. The
possible different states indicate the current status of the protection environment,
and can be in one of three states:</t>
<t><list style="symbols">
<t>Normal (Idle) state – When both the recovery and the working paths are
fully allocated and active, data traffic is being transmitted over the working
path, and there are no events being reported within the domain.</t>
<t>Protecting state – When either the working path has reported a signal
failure or degradation of signal, or the operator has issued an operator command
and the data traffic has been redirected to the recovery path.</t>
<t>Unavailable state – When the recovery path is unavailable, either as a
result of reporting a SF or SD condition, or as a result of an administrative
Lockout command.</t>
</list></t>
<t>This state may affect the actions taken by the control logic, and therefore, the
PSC Status Module transfers the current status to the Local Request Logic.</t>
<t>See section 4.3.1 for details on what actions are affected by the PSC state.</t>
</section>
</section>
</section>
<section title="Protection state coordination (PSC) protocol">
<t>Bidirectional protection switching, as well as unidirectional 1:1 protection,
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 3.1, the end-points
must inform each other of the switch-over from one path to the other in a coordinated
fashion.</t>
<t>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.</t>
<t>In the following sub-sections we describe the protocol messages that should be used
between the two end-points of the protection domain.</t>
<t>For the sake of simplicity of the protocol, this protocol is based on the single-phase
approach described above.</t>
<section title="Transmission and acceptance of PSC control packets">
<t>The PSC control packets 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.</t>
<t>A new PSC control packets must be transmitted immediately when a change in
the transmitted status occurs.</t>
<t>The first three PSC packets should be transmitted as fast as possible only
if the PSC information to be transmitted has been changed so that fast
protection switching is possible even if one or two PSC packets are lost or
corrupted. For protection switching within 50ms, the interval of the
first three PSC signals should be 3.3ms. PSC packets after the first three
should be transmitted with an interval of 5 seconds.</t>
<t>If no valid PSC specific information is received, the last valid received
information remains applicable. In the event a signal fail condition is
detected on the protection transport entity, the received PSC specific
information should be evaluated.</t>
</section>
<section title="Protocol format">
<t>The protocol messages SHALL be sent over the GACH as described in
<xref target='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
<xref target='8' />. The following figure shows the format for the full PSC message.</t>
<figure anchor="figure 4" title="Format of PSC packet with a GACH header">
<artwork>
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 Control Packet ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>Where:
<list style="symbols">
<t>MPLS-TP PSC Channel Code is the GACH channel number assigned to the PSC = TBD</t>
<t>The ACH TLV Header is described in <xref target='8' /></t>
<t>The use of the Addressing TLV are for further study</t>
<t>The following figure shows the format of the PSC Control message that is the
payload for the PSC packet.</t>
</list>
</t>
<t>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.</t>
<t>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. End of editor's note.</t>
<figure anchor="figure 5" title="Format of the PSC control packet">
<artwork>
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|Typ| FPath | Path | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>Where:
<list style="symbols">
<t>Ver: is the version of the protocol, for this version the value SHOULD be 0.</t>
<t>Request: this field indicates the specific PSC request that is being
transmitted, the details are described in section 4.1.1</t>
<t>Typ: indicates the type of protection scheme currently supported, more
details are given in section 4.1.4</t>
<t>FPath: used to indicate the path that is reporting a failure condition,
the possible values are described in section 4.1.2</t>
<t>Path: used to indicate the currently active path, possible values are
described in section 4.1.3</t>
<t>Rsv, Reserved: these fields are reserved for possible future use. These bits MUST
be set to zero on transmission, and ignored upon reception.</t>
</list>
</t>
<!-- Need to continue from here with section 4.1.1 of document!! -->
<section title="PSC Requests">
<t>The Protection Switching Coordination (PSC) protocol SHALL support
the following request types, in order of priority from highest to lowest:</t>
<list style="symbols">
<t>(1111) Clear</t>
<t>(1110) Lockout protection</t>
<t>(1101) Forced switch</t>
<t>(0110) Signal fault</t>
<t>(0101) Signal degrade</t>
<t>(0100) Manual switch</t>
<t>(0011) Wait to restore</t>
<t>(0010) Do not revert (DNR)</t>
<t>(0000) No request</t>
</list>
<t>See section 6.3 for a description of the operation of the different
requests.</t>
</section>
<!-- This will be the continuation from section 4.2 of document!! -->
<section title="Path Fault Identifier">
<t>The Fpath field 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:</t>
<list style="symbols">
<t>0: indicates that the fault condition is on the Recovery path </t>
<t>1: indicates that the fault condition is on the Working path</t>
<t>2-255: for future extensions</t>
</list>
</section>
<section title="Active path indicator">
<t>The Path field of the PSC control SHALL be used to indicate which path
the source MEP is currently using for data transmission. The 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:</t>
<list style="symbols">
<t>0: indicates that normal traffic is being transmitted on the Working
path.</t>
<t>1: indicates the Recovery path is being used to transmit the normal
traffic from the Working path.</t>
<t>2-255: for future extensions</t>
</list>
</section>
<section title="Current Protection Type">
<t>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:</t>
<list style="symbols">
<t>11: 1+1 bidirectional switching</t>
<t>10: 1:1 bidirectional switching</t>
<t>01: 1+1 unidirectional switching</t>
<t>00: 1:1 unidirectional switching</t>
</list>
</section>
</section>
<section title="Principles of Operation">
<t>In all of the following sub-sections, assume a protected domain
between LSR-A and LSR-Z, using paths W (working) and R (recovery).</t>
<section title="PSC States">
<section title="Normal State">
<t>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.</t>
<t>The ingress LSR MAY transmit a No Request PSC packet with the Path field
set to 0 for the recovery path.</t>
</section>
<section title="Protecting State">
<t>When the protection mechanism has been triggered and the protected domain
has performed a protection switch, the domain is in the protecting state.
In this state the normal traffic is transmitted and received on the recovery
path.</t>
<t>If the protection domain is currently in a protecting state, then the LSRs
SHOULD NOT accept a Manual Switch request.</t>
<t>If the protection domain is currently in a protecting state, 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, and
the Forced Switch condition will be signalled by the PSC messages.</t>
</section>
<section title="Unavailable State">
<t>When the recovery path is unavailable – either as a result of a Lockout
operator command (see section 4.3.3), or as a result of a SF or SD detected on
the recovery path (see section 4.3.4) – then the protection domain is in the
unavailable state. In this state, the normal traffic is transmitted and
received on the working path.</t>
<t>While in unavailable state any event that would trigger a protection
switching SHOULD be ignored with the following exception – 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.</t>
<t>The protection domain will exit the unavailable state and revert to the
normal state when, either the operator clears the Lockout command or the
recovery path recovers from the signal fault or degraded situation. Both
ends will resume sending the PCS packets over the recovery path, as a result
of this recovery.</t>
</section>
</section>
<section title="Failure or Degraded condition (Working path)">
<t>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:</t>
<list style="symbols">
<t>Switch all traffic for LSR-Z to the recovery path only.</t>
<t>Transmit a PCS control packet, using GACH, with the appropriate Request code
(either Signal fault or Signal degrade), the Fpath set to 1, to indicate that
the fault/degrade was detected on the working path, and the Path set to 0,
indicating that normal traffic is now being transmitted on the recovery path.
</t>
<t>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.</t>
</list>
<t>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:</t>
<list style="symbols">
<t>Check priority of the request</t>
<t>Switch all traffic addressed to LSR-A to the recovery path only.</t>
<t>Begin transmission of a PCS control packet, using GACH, with the appropriate
Request code (either Signal fault or Signal degrade), the Fpath set to 1, to
indicate that the fault/degrade was detected on the working path, and the Path
set to 1, indicating that traffic is now being transmitted on the recovery path.
</t>
</list>
</section>
<section title="Lockout of Protection">
<t>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:</t>
<list>
<t>Transmit a PCS control packet, using GACH, with the Request code set to Lockout
of protection (1110), the Fpath set to 0, and the Path set to 0.</t>
<t>All normal traffic packets should be transmitted on the working path only.</t>
<t>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.</t>
<t>The PSC control logic should go into Unavailable state.</t>
</list>
<t>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:</t>
<list style="symbols">
<t>Check priority of request</t>
<t>Switch all normal traffic addressed to LSR-A to the working path only.</t>
<t>The PSC control logic should go into Unavailable status.</t>
<t>Begin transmission of a PCS control packet, using GACH, with the appropriate
Request code (Lockout of protection), the Fpath set to 0, and the Path set to 0,
indicating that traffic is now being transmitted on the working path only.</t>
</list>
</section>
<section title="Failure or Degraded condition (Recovery path)">
<t>If one of the LSRs (for example, LSR-A) detects a failure condition or a serious
degradation condition on the recovery path, then it SHOULD take the following
actions:</t>
<list style="symbols">
<t>Begin transmission of a PCS control packet with the appropriate Request code
(either Signal fault or Signal degrade), the Fpath set to 0, to indicate that
the fault/degrade was detected on the recovery path, and the Path set to 0,
indicating that traffic is now being forwarded on the working path. Note that
this will actually reach the far-end if this is a unidirectional fault or
recovery path is possibly in a degraded situation.</t>
<t>The PSC control logic should go into Unavailable state.</t>
<t>All traffic MUST be transmitted on the working path for the duration of
the SF/SD condition.</t>
</list>
<t>When the far-end LSR (in this example LSR-Z) receives the PCS packet informing
it that other LSR (LSR-A) has become Unavailable, it SHOULD perform the following
actions:</t>
<list style="symbols">
<t>Transmit all traffic on the working path for the duration of the SF/SD
condition</t>
<t>The PSC Control logic should go into Unavailable state.</t>
</list>
</section>
<section title="Operator Controlled Switching">
<t>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:</t>
<list style="symbols">
<t>Switch all data traffic to the recovery path only.</t>
<t>Transmit a PCS control packet, using GACH, with the appropriate Request code
(either Manual switch or Forced switch), the Fpath set to 0, to indicate that the
fault/degrade was detected on the working path, and the Path set to 1, indicating
that traffic is now being forwarded on the recovery path.</t>
<t>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.</t>
</list>
<t>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:</t>
<list style="symbols">
<t>Check priority of the request</t>
<t>Switch all normal traffic addressed to LSR-A to the recovery path only.</t>
<t>Begin transmission of a PCS control packet, using GACH, with the appropriate
Request code (either Manual switch of Forced switch), the Fpath set to 1, to
indicate that the fault/degrade was detected on the working path, and the Path set
to 1, indicating that traffic is now being forwarded on the recovery path.</t>
</list>
<section title="Clearing operator commands">
<t>The operator may clear the switching condition by issuing a Clear request.
This command will cause immediate recovery from the switch that was initiated by
any of the previous operator commands, i.e. Forced Switch or Manual Switch. In
addition, a Clear command after a Lockout Protection command should clear the
Unavailable state and return the protection domain to the normal state.</t>
<t>If the Clear request is issued in the absence of a Manual Switch, Forced
Switch, 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.</t>
</section>
</section>
<section title="Recovery from switching">
<t>When the condition that triggered the protection switching clears, e.g. the cause
of the failure condition has been corrected, or the operator clears a Manual Switch, then
the protection domain SHOULD follow the following procedures:</t>
<list style="symbols">
<t>If the network is configured for non-revertive behaviour, then the two LSRs SHOULD
transmit DNR (Request code 0010) messages.</t>
<t>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.</t>
<t>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 4.3.6.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.</t>
</list>
<section title="Wait-to-restore timer">
<t>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.</t>
<t>During this period, if a failure condition is detected on the working transport path,
then the WTR timer is cleared 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).</t>
</section>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not by itself raise any particular security
considerations.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- Begin inclusion reference.RFC.2116.xml. -->
<reference anchor="1">
<front>
<title abbrev="KeyW">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization />
</author>
<date month="March" year="1997" />
<abstract>
<t>Defines the normative terms used in RFCs.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="792" />
</reference>
<!-- End inclusion reference.RFC.2116.xml. -->
<!-- Begin inclusion reference.draft.MPLS.TP.Reqs -->
<reference anchor="2">
<front>
<title>Requirements for the Trasport Profile of MPLS</title>
<author initials="B." surname="Niven-Jenkins" fullname="Ben Niven-Jenkins">
<organization> BT </organization>
</author>
<author initials="D." surname="Brungard" fullname="Deborah Brungard">
<organization> AT&T </organization>
</author>
<author initials="M." surname="Betts" fullname="Malcolm Betts">
<organization />
</author>
<author initials="N." surname="Sprecher" fullname="Nurit Sprecher">
<organization> Nokia Siemens Networks </organization>
</author>
<author initials="S." surname="Ueno" fullname="S.Ueno">
<organization />
</author>
<date year="2009" month="June" />
<abstract>
<t>Lists the requirements for MPLS-TP with cross reference </t>
</abstract>
</front>
<seriesInfo name="RFC" value="5654" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.Reqs -->
</references>
<references title="Informative References">
<!-- Begin inclusion reference.RFC.3031.xml. -->
<reference anchor="3">
<front>
<title abbrev="MPLS-Arch">Multiprotocol Label Switching Architecture</title>
<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization />
</author>
<author fullname="A. Viswanathan" initials="A." surname="Viswanathan">
<organization />
</author>
<author fullname="Ross Callon" initials="R." surname="Callon">
<organization />
</author>
<date month="Jan" year="2001" />
<abstract>
<t>Describes the architecture of MPLS and the use of LSP tunnels.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3031" />
</reference>
<!-- End inclusion reference.RFC.3031.xml. -->
<!--Begin inclusion reference.RFC.3032 -->
<reference anchor="4">
<front>
<title>MPLS Label Stack Encoding", RFC 3032, January 2001</title>
<author initials="E." surname="Rosen" fullname="E. Rosen">
<organization />
</author>
<author initials="D." surname="Tappan" fullname="D. Tappan">
<organization />
</author>
<author initials="G." surname="Fedorkow" fullname="G. Fedorkow">
<organization />
</author>
<author initials="Y." surname="Rekhter" fullname="Yakov Rechter">
<organization />
</author>
<author initials="T." surname="Li" fullname="T. Li">
<organization />
</author>
<date year="2001" month="Jan" />
<abstract>
<t>"Multi-Protocol Label Switching (MPLS)" requires a set of procedures
for augmenting network layer packets with "label stacks",thereby turning
them into "labeled packets". Routers which support MPLS are known as
"Label Switching Routers", or "LSRs". In order to transmit a labeled
packet on a particular data link, an LSR must support an encoding
technique which, given a label stack and a network layer packet, produces
a labeled packet. This document specifies the encoding to be used by an
LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP)
data links, on LAN data links, and possibly on other data links as well.
On some data links, the label at the top of the stack may be encoded in
a different manner, but the techniques described here MUST be used to
encode the remainder of the label stack. This document also specifies
rules and procedures for processing the various fields of the label stack
encoding.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3032" />
<format type="TXT" octets="116872" target="ftp://ftp.isi.edu/in-notes/rfc3032.txt" />
</reference>
<!-- End inclusion reference.RFC.3032 -->
<!-- Begin inclusion reference.RFC.3985 -->
<reference anchor="5">
<front>
<title>Pseudowire Emulation Edge-to-Edge (PWE3) Architecture</title>
<author initials="S." surname="Bryant" fullname="S. Bryant">
<organization />
</author>
<author initials="P." surname="Pate" fullname="P. Pate">
<organization />
</author>
<date year="2005" month="March" />
<abstract>
<t>This document describes an architecture for Pseudo Wire Emulation Edge-to-
Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM,
Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP
or MPLS. It presents the architectural framework for pseudo wires (PWs),
defines terminology, and specifies the various protocol elements and their
functions. </t>
</abstract>
</front>
<seriesInfo name="RFC" value="3985" />
<format type="TXT" octets="22440" target="ftp://ftp.isi.edu/in-notes/rfc3985.txt" />
</reference>
<!-- End inclusion reference.RFC.4385 -->
<!-- Begin inclusion reference.RFC.5085 -->
<reference anchor="6">
<front>
<title>Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires</title>
<author initials="T." surname="Nadeau" fullname="T. Nadeau">
<organization />
</author>
<author initials="C." surname="Pignataro" fullname="C. Pignataro">
<organization />
</author>
<date year="2007" month="December" />
<abstract>
<t>This document describes Virtual Circuit Connectivity Verification (VCCV), which
provides a control channel that is associated with a pseudowire (PW), as well as
the corresponding operations and management functions (such as connectivity
verification) to be used over that control channel. VCCV applies to all supported
access circuit and transport types currently defined for PWs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5085" />
<format type="TXT" octets="67847" target="ftp://ftp.isi.edu/in-notes/rfc5085.txt" />
</reference>
<!-- End inclusion reference.RFC.5085 -->
<!-- Begin inclusion reference.draft.MPLS-TP.FWK -->
<reference anchor="7">
<front>
<title>A Framework for MPLS in Transport Networks</title>
<author initials="M." surname="Bocci" fullname="Matthew Bocci">
<organization />
</author>
<author initials="S." surname="Bryant" fullname="Stewart Bryant">
<organization> Cisco </organization>
</author>
<author initials="L." surname="Levrau" fullname="Lieven Levrau">
<organization> Cisco </organization>
</author>
<date year="2009" month="July" />
<abstract>
<t>This document specifies an architectural framework for the application of MPLS
in transport networks. It describes a profile of MPLS that enables operational
models typical in transport networks , while providing additional OAM,
survivability and other maintenance functions not currently supported by MPLS. </t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-framework-06.txt" />
</reference>
<!-- End inclusion reference.draft.MPLS-TP.FWK -->
<!-- Begin inclusion reference.draft.MPLS.BFD -->
<reference anchor="8">
<front>
<title>MPLS Generic Associated Channel</title>
<author initials="M." surname="Vigoureux," fullname="Martin Vigoureux,">
<organization />
</author>
<author initials="M." surname="Bocci" fullname="Matthew Bocci">
<organization />
</author>
<author initials="G." surname="Swallow" fullname="George Swallow">
<organization />
</author>
<author initials="R." surname="Aggarwal" fullname="Rahul Aggarwal">
<organization />
</author>
<author initials="D." surname="Ward" fullname="David Ward">
<organization />
</author>
<date year="2009" month="May" />
<abstract>
<t>This document generalizes the applicability of the pseudowire (PW)
Associated Channel Header (ACH), enabling the realization of a control
channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections
in addition to MPLS pseudowires. In order to identify the presence of
this Associated Channel Header in the label stack, this document also
assigns one of the reserved MPLS label values to the Generic Associated
Channel Label (GAL), to be used as a label based exception mechanism. </t>
</abstract>
</front>
<seriesInfo name="RFC" value="5586" />
</reference>
<!-- End inclusion reference.draft.MPLS.BFD -->
<!-- Begin inclusion reference.draft.MPLS.TP.OAM.Reqs -->
<reference anchor="9">
<front>
<title>Requirements for OAM in MPLS Transport Networks</title>
<author initials="M." surname="Vigoureux" fullname="Martin Vigoureux">
<organization />
</author>
<author initials="M." surname="Betts" fullname="Malcolm Betts">
<organization />
</author>
<author initials="D." surname="Ward" fullname="Dave Ward">
<organization />
</author>
<date year="2009" month="April" />
<abstract>
<t>Lists the requirements for the OAM functionality in support of MPLS-TP.</t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-oam-requirements-03" />
</reference>
<!-- End inclusion reference.draft.MPLS.TP.OAM.Reqs -->
<!-- Begin inclusion reference.rfc.4427 -->
<reference anchor="10">
<front>
<title>Recovery Terminology for Generalized Multi-Protocol Label Switching</title>
<author initials="E." surname="Mannie" fullname="E. Mannie">
<organization />
</author>
<author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou">
<organization />
</author>
<date year="2006" month="Mar" />
<abstract>
<t>This document defines a common terminology for Generalized Multi-Protocol
Label Switching (GMPLS)-based recovery mechanisms (i.e.,protection and
restoration). The terminology is independent of the underlying transport
technologies covered by GMPLS</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4427" />
</reference>
<!-- End inclusion reference.rfc.4427 -->
<!-- Begin inclusion reference.draft.survive.fwk -->
<reference anchor="11">
<front>
<title>Multi-protocol Label Switching Transport Profile Survivability Framework</title>
<author initials="N." surname="Sprecher" fullname="Nurit Sprecher">
<organization />
</author>
<author initials="A." surname="Farrel" fullname="Adrian Farrel">
<organization />
</author>
<author initials="H." surname="Shah" fullname="Himanshu Shah">
<organization />
</author>
<date year="2009" month="Feb" />
<abstract>
<t>Network survivability is the network's ability to restore traffic following
failure or attack; it plays a critical factor in the delivery of reliable
services in transport networks. Guaranteed services in the form of Service
Level Agreements (SLAs) require a resilient network that detects facility or
node failures very rapidly, and immediately starts to restore network
operations in accordance with the terms of the SLA. The Transport Profile of
Multiprotocol Label Switching (MPLS-TP) is a packet transport technology that
combines the packet experience of MPLS with the operational experience of
transport networks like SONET/SDH. It provides survivability mechanisms such
as protection and restoration, with similar function levels to those found in
established transport networks such as in SONET/SDH networks. Some of the
MPLS-TP survivability mechanisms are data plane-driven and are based on MPLS-TP
OAM fault management functions which are used to trigger protection switching
in the absence of a control plane. Other survivability mechanisms utilize the
MPLS-TP control plane. This document provides a framework for MPLS-TP
survivability. </t>
</abstract>
</front>
<seriesInfo name="ID" value="draft-ietf-mpls-tp-survive-fwk-02.txt" />
</reference>
<!-- End inclusion reference.draft.survive.fwk -->
<!-- Begin inclusion reference.draft.RFC.4872 -->
<reference anchor="12">
<front>
<title>RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol
Label Switching (GMPLS) Recovery</title>
<author initials="J.P." surname="Lang" fullname="J.P. Lang">
<organization />
</author>
<author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou">
<organization />
</author>
<author initials="Y." surname="Rekhter" fullname="Yakov Rekhter">
<organization />
</author>
<date year="2007" month="May" />
<abstract>
<t></t>
</abstract>
</front>
<seriesInfo name="RFC" value="4872" />
</reference>
<!-- End inclusion reference.RFC.4872 -->
<!-- Begin inclusion reference.RFC.3945 -->
<reference anchor="13">
<front>
<title>Generalized Multi-Protocol Label Switching (GMPLS) Architecture</title>
<author initials="E." surname="Mannie" fullname="E. Mannie">
<organization />
</author>
<date year="2004" month="Oct" />
<abstract>
<t></t>
</abstract>
</front>
<seriesInfo name="RFC" value="3945" />
</reference>
<!-- End inclusion reference.RFC.3945 -->
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 19:38:03 |