One document matched: draft-weingarten-mpls-tp-linear-protection-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!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-05.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></street>
<region></region>
<code></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></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 />
<region />
<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 />
<city />
<region />
<code />
<country>Italy</country>
</postal>
<email>annamaria.fulignoli@ericsson.com</email>
<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 MPLS-TP Survivability
Framework document 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>
<t>This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>As noted in the architecture for Multi-Protocol Label Switching
Transport Profile (MPLS-TP) <xref target="TPFwk"></xref>, 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 <xref target="RFC3031"></xref>, <xref
target="RFC3985"></xref> and <xref target="RFC5085"></xref>. One of the
basic survivability functions, pointed out by the Survivability
Framework document <xref target="SurvivFwk"></xref>, 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 or set of working
paths. 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="SurvivFwk"></xref>, protection switching is applied to a
protected domain. For the purposes of this document, we define the
protected domain of a P2P LSP as consisting of two Label Switching
Routers (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="SurvivFwk"></xref>, a recovery transport path is dedicated to
each working transport path. Normal traffic is bridged (as defined in
<xref target="RFC4427"></xref>)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 a 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="SurvivFwk"></xref>), 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="SurvivFwk"></xref> 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 <xref
target="RFC2119"></xref>.</t>
<section title="Acronyms">
<texttable align="left" style="none">
<preamble>This draft uses the following acronyms:</preamble>
<ttcol align="left"></ttcol>
<ttcol align="left"></ttcol>
<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 Router</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="RFC4427"></xref> and further adapted for
MPLS-TP in <xref target="SurvivFwk"></xref>. 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 the MPLS-TP server layer
detects a failure within its own layer, or due to a failure of its
server layer (e.g. the physical layer) notifies the MPLS-TP layer
that a failure has been detected.</t>
<t>OAM signalling – if, for example, OAM continuity and
connectivity verification tools detect that there is a loss of
continuity or mis-connectivity or 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 signaling 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="RFC3945"></xref>
then the recovery process should comply with the process described
in <xref target="RFC4872"></xref>.</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="RFC4427"></xref>).</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="figure1" title="Protection switching control logic">
<artwork><![CDATA[
+-------------+ 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="figure1"></xref> 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
trigger events reported within the domain.</t>
<t>Protecting state – When either the working path has
reported a signal failure (SF) or degradation of signal (SD), 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 transmitting the data traffic 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 MEP of the switch, and the
far-end MEP 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>Any new PSC control packet must be transmitted immediately when a
change in the transmitted status occurs.</t>
<t>When the PSC information is changed, three PSC packets should be
transmitted as quickly as possible, so that fast protection switching
would be possible. Transmission of three rapid packets allows for fast
protection switching even if one or two PSC packets are lost or
corrupted. The frequency of the first three packets and the separate
frequency of the continual transmission is configurable by the
operator. For protection switching within 50ms, the default interval
of the first three PSC signals should be no larger than 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 recovery path, 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="RFC5586"></xref>. 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="RFC5586"></xref>. The following figure shows the format for
the full PSC message.</t>
<figure anchor="figure 2"
title="Format of PSC packet with a GACH header">
<artwork><![CDATA[
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="RFC5586"></xref></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 3" title="Format of the PSC control packet">
<artwork><![CDATA[
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| PT| 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.2.1</t>
<t>PT: indicates the type of protection scheme currently
supported, more details are given in section 4.2.2</t>
<t>FPath: used to indicate the path that is reporting a failure
condition, the possible values are described in section 4.2.3</t>
<t>Path: used to indicate the currently active path, possible
values are described in section 4.2.4</t>
<t>Reserved: field is reserved for possible future use. These bits
MUST be set to zero on transmission, and ignored upon
reception.</t>
</list></t>
<section title="PSC Requests">
<t>The Protection State Coordination (PSC) protocol SHALL support
the following request types, in order of priority from highest to
lowest:</t>
<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>
<t>See section 6.3 for a description of the operation of the
different requests.</t>
</section>
<section title="Protection Type (PT)">
<t>The PT 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>
<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></t>
</section>
<section title="Path fault identifier (FPath)">
<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>
<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></t>
</section>
<section title="Active path indicator (Path)">
<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>
<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></t>
</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) as
shown in figure 4.</t>
<figure anchor="figure 4" title="Protected domain">
<artwork><![CDATA[
+-----+ //=======================\\ +-----+
|LSR-A|// Working Path \\|LSR-Z|
| /| |\ |
| ?< | | >? |
| \|\\ Recovery Path //|/ |
+-----+ \\=======================// +-----+
|--------Protected Domain---------|
]]></artwork>
</figure>
<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 indicating that the normal data traffic should
be read from the working 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 data 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>
<t><list style="symbols">
<t>(For 1:1 protection) 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 1,
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 2 PSC cycles then send an alarm to the
management system.</t>
</list></t>
<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>
<t><list style="symbols">
<t>Check priority of the request</t>
<t>Switch all traffic addressed to LSR-A to the recovery path
only (for 1:1 protection).</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></t>
</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 (LSR-Z in this example) that it is
not possible to use the recovery path. The following actions MUST be
taken:</t>
<t><list style="symbols">
<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>
<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>
<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></t>
</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>
<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>
<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>
<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></t>
</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>
<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 2 PSC cycles then send an alarm to the
management system.</t>
</list></t>
<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>
<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></t>
<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>
<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></t>
<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
Wait-to-restore (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>To be added in future version.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>To be added in future version.</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.2119.xml. -->
<reference anchor="RFC2119">
<front>
<title abbrev="KeyW">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization></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="2119" />
</reference>
<!-- End inclusion reference.RFC.2116.xml. -->
</references>
<references title="Informative References">
<!-- Begin inclusion reference.RFC.3031.xml. -->
<reference anchor="RFC3031">
<front>
<title abbrev="MPLS-Arch">Multiprotocol Label Switching
Architecture</title>
<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization></organization>
</author>
<author fullname="A. Viswanathan" initials="A."
surname="Viswanathan">
<organization></organization>
</author>
<author fullname="Ross Callon" initials="R." surname="Callon">
<organization></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.3985 -->
<reference anchor="RFC3985">
<front>
<title>Pseudowire Emulation Edge-to-Edge (PWE3) Architecture</title>
<author fullname="S. Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<author fullname="P. Pate" initials="P." surname="Pate">
<organization></organization>
</author>
<date month="March" year="2005" />
<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 octets="22440" target="ftp://ftp.isi.edu/in-notes/rfc3985.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.RFC.3985 -->
<!-- Begin inclusion reference.RFC.5085 -->
<reference anchor="RFC5085">
<front>
<title>Pseudowire Virtual Circuit Connectivity Verification (VCCV):
A Control Channel for Pseudowires</title>
<author fullname="T. Nadeau" initials="T." surname="Nadeau">
<organization></organization>
</author>
<author fullname="C. Pignataro" initials="C." surname="Pignataro">
<organization></organization>
</author>
<date month="December" year="2007" />
<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 octets="67847" target="ftp://ftp.isi.edu/in-notes/rfc5085.txt"
type="TXT" />
</reference>
<!-- End inclusion reference.RFC.5085 -->
<!-- Begin inclusion reference.draft.MPLS-TP.FWK -->
<reference anchor="TPFwk">
<front>
<title>A Framework for MPLS in Transport Networks</title>
<author fullname="Matthew Bocci" initials="M." surname="Bocci">
<organization></organization>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization>Cisco</organization>
</author>
<author fullname="Lieven Levrau" initials="L." surname="Levrau">
<organization>Cisco</organization>
</author>
<date month="July" year="2009" />
<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.GACH -->
<reference anchor="RFC5586">
<front>
<title>MPLS Generic Associated Channel</title>
<author fullname="Martin Vigoureux," initials="M."
surname="Vigoureux,">
<organization></organization>
</author>
<author fullname="Matthew Bocci" initials="M." surname="Bocci">
<organization></organization>
</author>
<author fullname="George Swallow" initials="G." surname="Swallow">
<organization></organization>
</author>
<author fullname="Rahul Aggarwal" initials="R." surname="Aggarwal">
<organization></organization>
</author>
<author fullname="David Ward" initials="D." surname="Ward">
<organization></organization>
</author>
<date month="May" year="2009" />
<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.rfc.4427 -->
<reference anchor="RFC4427">
<front>
<title>Recovery Terminology for Generalized Multi-Protocol Label
Switching</title>
<author fullname="E. Mannie" initials="E." surname="Mannie">
<organization></organization>
</author>
<author fullname="D. Papadimitriou" initials="D."
surname="Papadimitriou">
<organization></organization>
</author>
<date month="Mar" year="2006" />
<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="SurvivFwk">
<front>
<title>Multi-protocol Label Switching Transport Profile
Survivability Framework</title>
<author fullname="Nurit Sprecher" initials="N." surname="Sprecher">
<organization></organization>
</author>
<author fullname="Adrian Farrel" initials="A." surname="Farrel">
<organization></organization>
</author>
<author fullname="Himanshu Shah" initials="H." surname="Shah">
<organization></organization>
</author>
<date month="Feb" year="2009" />
<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="RFC4872">
<front>
<title>RSVP-TE Extensions in Support of End-to-End Generalized
Multi-Protocol Label Switching (GMPLS) Recovery</title>
<author fullname="J.P. Lang" initials="J.P." surname="Lang">
<organization></organization>
</author>
<author fullname="D. Papadimitriou" initials="D."
surname="Papadimitriou">
<organization></organization>
</author>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization></organization>
</author>
<date month="May" year="2007" />
<abstract>
<t></t>
</abstract>
</front>
<seriesInfo name="RFC" value="4872" />
</reference>
<!-- End inclusion reference.RFC.4872 -->
<!-- Begin inclusion reference.RFC.3945 -->
<reference anchor="RFC3945">
<front>
<title>Generalized Multi-Protocol Label Switching (GMPLS)
Architecture</title>
<author fullname="E. Mannie" initials="E." surname="Mannie">
<organization></organization>
</author>
<date month="Oct" year="2004" />
<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-24 02:55:17 |