One document matched: draft-ietf-mpls-tp-linear-protection-02.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-ietf-mpls-tp-linear-protection-02.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="Eric Osborne" initials="E." surname="Osborne">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<region></region>
<code></code>
<country>United States</country>
</postal>
<email>eosborne@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="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="2010" />
<abstract>
<t>The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is being
specified jointly by IETF and ITU-T. This document addresses the functionality
described in the MPLS-TP Survivability Framework document <xref target=
"SurvivFwk" /> 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>The MPLS Transport Profile (MPLS-TP) <xref target="TPFwk" /> is a
framework for the construction and operation of packet-switched transport
networks based on the architectures for MPLS (<xref target="RFC3031" />
and <xref target="RFC3032" />) and for Pseudowires (PWs) (<xref target=
"RFC3985" /> and <xref target="RFC5659" />) and the requirements of
<xref target="RFC5654" />.</t>
<t>Network survivability is the ability of a network to recover traffic
delivery following failure, or degradation of network resources. The
MPLS-TP Survivability Framework <xref target="SurvivFwk" /> is a framework
for survivability in MPLS-TP networks, and describes recovery elements,
types, methods, and topological considerations, focusing on mechanisms
for recovering MPLS-TP Label Switched Paths (LSPs).</t>
<t>Linear protection in mesh networks – networks with arbitrary
interconnectivity between nodes – is described in Section 4.7 of
<xref target="SurvivFwk" />. Linear protection provides rapid and simple
protection switching. In a mesh network, linear protection provides a
very suitable protection mechanism because it can operate between any pair
of points within the network. It can protect against a defect in an
intermediate node, a span, a transport path segment, or an end-to-end
transport path.</t>
<section title="Protection architectures">
<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 protection
domain. For the purposes of this document, we define the protection
domain of a P2P LSP as consisting of two Label Switching Routers (LER)
and the transport paths that connect them. For a P2MP LSP the protection
domain includes the root (or source) LER, 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, similar to the 1:1 case by using a
selector bridge at the source, 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 may
be 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>
</section>
<section title="Scope of the document">
<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.</t>
<t>The scope of this draft is to present a protocol for the Protection State
Coordination of Linear Protection. The protocol addresses the protection of
LSPs in an MPLS-TP network as required by <xref target="RFC5654" /> (in
particular requirements 63-67 and 74-79) and described in <xref target="SurvivFwk"
/>. The basic protocol is designed for use in conjunction with the 1:1 protection
architecture (for both unidirectional and bidirectional protection) and for
1+1 protection of a bidirectional path (for both unidirectional and bidirectional
protection switching). Applicability of the protocol for 1:n protection schemes
may be documented in a future document. The applicability of this protocol to
additional MPLS-TP constructs and topologies may be documented in future
documents.</t>
<t>While the unidirectional 1+1 protection architecture does not require the
use of a coordination protocol, the protocol may be used by the ingress node
of the path to notify the far-side end point that a switching condition has
occurred and verify the consistency of the end-point configuration. This use may
be especially useful for point-to-multipoint transport paths, that are
unidirectional by definition of <xref target="RFC5654" />.
</t>
</section>
<section title="Contributing authors">
<t>Hao Long (Huawei), Dan Frost (Cisco), Davide Chiara
(Ericsson), Francesco Fondelli (Ericsson), </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>G-ACh</c>
<c>Generic Associated Channel Header</c>
<c>LER</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 LER to refer to a MPLS-TP Network Element, whether it is a LER,
LER, T-PE, or S-PE.</t>
</section>
</section>
<section title="Protection switching control logic">
<section title="Protection switching control logical architecture">
<t>Protection switching processes the local triggers described in
<xref target="RFC5654" /> requirements 74-79 together with inputs
received from the far-end LER. Based on these inputs the LER will take certain
protection switching actions, e.g. switching the Selector Bridge to select
the working or protection path, and transmit different protocol messages.</t>
<t>The following figure shows the logical decomposition of the PSC Control
Logic into different logical processing units. These processing units are
presented in subsequent sub-sections of this document.</t>
<figure anchor="figure1" title="Protection switching control logic">
<artwork><![CDATA[
Server Indication Control Plane Indication
-----------------+ +-------------
Operator Command | | OAM Indication
----------------+ | | +---------------
| | | |
V V V V
+---------------+ +-------+
| Local Request |<--------| WTR |
| logic |WTR Exps | Timer |
+---------------+ +-------+
| ^
Highest local|request |
V | Start/Stop
+-----------------+ |
Remote PSC | PSC Process |------------+
------------>| logic |
Request +-----------------+
|
| Action +------------+
+---------------->| Message |
| Generator |
+------------+
|
Output PSC | Message
V
]]></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, from the
local control plane (when present), and the Wait-to-Restore timer. By
considering all of these local request sources it determines the highest
priority local request. This high-priority request is passed to the PSC
Process logic, that will cross-check this local request with the information
received from the far-end LER. The PSC Process logic uses this input to
determine what actions need to be taken, e.g. local actions at the LER, or
what message should be sent to the far-end LER, and the current status of
the protection domain.</t>
<section title="Local Request Logic">
<t>The protection switching logic processes input triggers from five
sources:</t>
<t><list style="symbols">
<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>
<t>Server layer alarm indication – the underlying server
layer of the network detects failure conditions at the underlying
layer and may issue an indication to the MPLS-TP layer. The server
layer may employ its own protection switching mechanism, and
therefore this input MAY be controlled by a holdoff-timer that
SHOULD be configurable by the network operator.</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 SHALL comply with the process described
in <xref target="RFC4872"></xref>.</t>
<t>OAM indication – OAM fault management or performance
measurement tools may detect a failure or degrade condition on the MPLS-TP
transport path and this SHOULD input an indication to the Local
Request Logic.</t>
<t>WTR expires – The Wait-to-Restore timer is used in conjunction
with recovery from failure conditions on the working path in revertive mode.
The timer SHALL signal the PSC control process when it expires and the
end-point SHOULD revert to the normal transmission of the user data traffic.</t>
</list></t>
<t>The Local request logic SHALL process these different input sources and,
based on the priorities between them, SHOULD produce a current local request.
The different local requests that may be output from the Local Request Logic
are:</t>
<t><list style="symbols">
<t>Clear – if the opeartor cancels an active local administrative
command, i.e. LO/FS/MS.</t>
<t>Lockout of Protection (LO) – if the operator requested to disable
the protection path.</t>
<t>Signal Fail (SF) – if any of the Server Layer, Control plane, or
OAM indications signaled a failure condition on either the protection path or
one of the working paths.</t>
<t>Signal Degrade (SD) – if any of the Server Layer, Control plane, or
OAM indications signaled a degraded transmission condition on either the
protection path or one of the working paths</t>
<t>Clear Signal Fail – if all of the Server Layer, Control plane, or OAM
indications are no longer indicating a failure condition on a path that was
peviously indicating a failure condition.</t>
<t>Forced Switch (FS) – if the operator requested that traffic be
switched from one of the working paths to the protection path.</t>
<t>Manual Switch (MS) – if the operator requested that traffic be switched
from its current path to the other path. This is only relevant if there
is no currently active Fault condition or Operator command.</t>
<t>WTR Expires – generated by the WTR timer completing its period.</t>
</list></t>
<t>If none of the input sources have generated any input then the current local
request SHALL be a No Request (NR) request.</t>
</section>
<section title="Remote Requests">
<t>In addition to the local requests generated as a result of the local triggers
indicated in the previous sub-section, the PSC Control Logic SHALL accept PSC
messages from the far-end LER of the transport path. These remote messages
indicate the status of the transport path from the viewpoint of the far-end LER,
and may indicate if the local MEP SHOULD initiate a protection switch operation.</t>
<t>The following remote requests may be received by the PSC process:</t>
<t><list style="symbols">
<t>Remote LO – indicates that the remote end-point is in Unavailable
state due to a Lockout of Protection operator command.</t>
<t>Remote SF – indicates that the remote end-point has detected a Signal
Fail condition on one of the transport paths in the protection domain.
This remote message SHALL include an indication of which transport path is
affected by the SF condition. In addition, it should be noted that the SF
condition may be either unidirectional or bidirectional failure, even if the
transport path is bidirectional.</t>
<t>Remote SD – indicates that the remote end-point has detected a Signal
Degrade condition on one of the transport paths in the protection domain.
This remote message SHALL include an indication of which transport path is
affected by the SD condition. In addition, it should be noted that the SD
condition may be either unidirectional or bidirectional failure, even if the
transport path is bidirectional.</t>
<t>Remote FS – indicates that the remote end point is operating under
an operator command to switch the traffic to the protection path.</t>
<t>Remote MS – indicates that the remote end point is operating under
an operator command to switch the traffic to the path that was not being
used previously.</t>
<t>Remote WTR – indicates that the remote end-point has determined that
the failure condition has recovered and has started its WTR timer in
preparation for reverting to the Normal state.</t>
<t>Remote DNR – indicates that the remote end-point has determined that
the failure condition has recovered and will continue transporting traffic on
the protection path due to operator configuration that prevents automatic
reversion to the Normal state.</t>
<t>Remote NR – indicates that the remote end-point has no abnormal
condition to report.</t>
</list></t>
</section>
<section title="PSC Process Logic">
<t>The PSC Process Logic SHALL accept as input – a. the Local request
output from the Local Request Logic, b. the remote request message from the
remote end-point of the transport path, and c. the current state of the PSC
Control Logic (maintained internally by the PSC Control Logic). Based on
the priorities between the different inputs, the PSC Process Logic SHALL
determine the new state of the PSC Control Logic and what actions need to
be taken.</t>
<t>The new state information SHALL be sent for retention by the State Manager,
while the requested action SHALL be sent to the PSC Message Generator (see
subsection 3.1.4) to generate and transmit the proper PSC message to be
transmitted to the remote end-point of the protection domain.</t>
</section>
<section title="PSC Message Generator">
<t>Based on the action output from the Process Logic this unit formats the
PSC protocol message that is transmitted to the remote end-point of the
protection domain. When the PSC information has changed three PSC messages
SHOULD be transmitted in quick succession, and subsequent messages should be
transmitted continually at a slower rate.</t>
<t>The transmission of three rapid packets allows for fast protection switching
even if one or two PSC messages are lost or corrupted. For protection
switching within 50ms, it is RECOMMENDED that the default interval of the first
three PSC messages SHOULD be no larger than 3.3ms. The subsequent messages
SHOULD be transmitted with an interval of 5 sec, to avoid traffic congestion.</t>
</section>
<section title="Wait-to-Restore (WTR) timer">
<t>The WTR timer is used to delay reversion to Normal state when recovering
from a failure condition on the working path and the protection domain is
configured for revertive behavior. The WTR timer MAY be started, stopped, or
expire. If the WTR timer is running, sending a Stop command SHALL reset the
timer but SHALL NOT generate a WTR Expires local signal. If the WTR timer is
not running, a Stop command SHALL be ignored.</t>
</section>
<section title="PSC Control States">
<t>The PSC Control Logic SHOULD maintain information on the current state of
the protection domain. The state information SHALL include information of the
current state and an indication of the cause for the current state (e.g.
unavailable due to local LO command, protecting due to remote FS). In
particular, the state information SHOULD include an indication if the state
is related to a remote or local condition.</t>
<t>The states that are supported by the PSC Control Logic include:
<list style="symbols">
<t>Normal state – Both the protection and working paths are fully
allocated and active, data traffic is being transmitted over the working
path, and no trigger events are reported within the domain.</t>
<t>Unavailable state – The protection path is unavailable –
either as a result of an operator Lockout command or a failure/degrade
condition detected on the protection path.</t>
<t>Protecting failure state – The working path has reported a
failure/degrade condition and the user traffic is being transmitted on the
protection path.</t>
<t>Protecting administrative state – The operator has issued a
command switching the user traffic to the protection path.</t>
<t>Wait-to-restore state – The protection domain is recovering from
a SF/SD condition on the working path that is being controlled by the
Wait-to-Restore (WTR) timer.</t>
<t>Do-not-revert state – The protection domain is recovering from a
Protecting state, but the operator has configured the protection domain to
not automatically revert to the Normal state upon recovery. The protection
domain SHALL remain in this state until the operator issues a command to
revert to the Normal state or there is a new trigger to switch to a
different state.</t>
</list></t>
<t>See section 4.3.1 for details on what actions are taken by the PSC Process
Logic for each state and the relevant input.</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 LER
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 LER. The other possibility is a
single-phased coordination, in which the initiating LER performs the
protection switchover to the alternate path and informs the far-end LER
of the switch, and the far-end LER must complete the switchover.</t>
<t>For the sake of simplicity of the protocol, this protocol is based on
the single-phase approach described above. In the following sub-sections we
describe the protocol messages that SHALL be used between the two end-points
of the protection domain.</t>
<section title="Transmission and acceptance of PSC control packets">
<t>The PSC control packets SHALL be transmitted over the protection
path only. This allows the transmission of the messages without
affecting the normal data traffic in the most prevalent case, i.e. the Normal
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>When the PSC information is changed due to a local input, three PSC messages
SHOULD be transmitted as quickly as possible, to allow for rapid protection
switching. This set of three rapid messages allows for fast protection switching
even if one or two of these packets are lost or corrupted. When the PSC
information changes due to a remote message there is no need for the rapid
transmission of three messages with the following exception – When going
from Wait-to-Restore state to Normal state as a result of a remote NR message.</t>
<t>The frequency of the three rapid messages and the separate frequency of the
continual transmission SHOULD be configurable by the operator. For protection
switching within 50ms, the default interval of the first three PSC messages is
RECOMMENDED to be no larger than 3.3ms. The continuous transmission interval
is RECOMMENDED to be 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 path, the received PSC specific
information should be evaluated.</t>
</section>
<section title="Protocol format">
<t>The protocol messages SHALL be sent over the G-ACh as described in
<xref target="RFC5586"></xref>. There is a single channel type for the
set of PSC messages [to be assigned by IANA]. The actual message function
SHALL be identified by the Request field of the ACH payload as described
below. The following figure shows the format for the complete PSC message:.</t>
<figure anchor="figure 2"
title="Format of PSC packet with a G-ACh 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|Version| Reserved | Channel Type = MPLS-TP PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|Request|PT |R| Reserved | FPath | Path |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Where: <list style="symbols">
<t>MPLS-TP PSC Channel Code is the G-ACh channel number assigned to
the PSC = TBD</t>
<t>The ACH TLV Header is described in <xref target="RFC5586"></xref></t>
<t>The following subsections will describe the fields of the PSC payload.</t>
</list></t>
<section title="PSC Ver field">
<t>The Ver field identifies the version of the protocol. For this
version the value SHALL be 0.</t>
</section>
<section title="PSC Request field">
<t>The PSC protocol SHALL support transmission of the following requests
between the two end-points of the protection domain:</t>
<t><list style="symbols">
<t>(1110) Lockout of protection – indicates that the endpoint has
disabled the protection path as a result of an administrative command.
Both the FPath and Path fields SHOULD be set to 0.</t>
<t>(1101) Forced switch – indicates that the transmitting end-point has
switched traffic to the protection path as a result of an administrative
command. The Fpath field SHOULD indicate that the working path is being
blocked, and the Path field SHOULD indicate that user data traffic is being
transmitted on the protection path.</t>
<t>(0110) Signal Fail – indicates that the transmitting end-point has
identified a signal fail condition on either the working or protection
path. The Fpath field SHALL identify the path that is reporting the failure
condition, and the Path field SHALL indicate where the data traffic is being
transmitted.</t>
<t>(0100) Manual switch – indicates that the transmitting end-point has
switched traffic as a result of an administrative Manual Switch command.
The Fpath field SHALL indicate the path that is the manual switch is being
applied to and the Path field SHALL indicate the path being utilized by the
endpoint to transmit user data traffic.</t>
<t>(0011) Wait to restore – indicates that the transmitting endpoint
is recovering from a failure condition of the working path and has started
the Wait-to-Restore timer. Fpath SHOULD be set to 0 and ignored upon
receipt. Path SHOULD indicate the working path that is currently being
protected.</t>
<t>(0010) Do not revert – indicates that the transmitting endpoint is
recovering from a failure/blocked condition, but due to the local settings
is requesting that the protection domain continues to transmit data over
the protection path, rather than revert to the Normal state. Fpath SHOULD
be set to 0 and ignored upon receipt. Path SHOULD indicate the working
path that is currently being protected.</t>
<t>(0000) No request – indicates that the transmitting end-point has
nothing to report, Fpath and Path fields SHOULD be set to according to the
state of the end-point.</t>
</list></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
protection domain. If an inconsistency is detected then an alarm SHALL be
sent to the management system. The following are the possible values:</t>
<t><list style="symbols">
<t>11: bidirectional switching using a permanent bridge</t>
<t>10: bidirectional switching using a selector bridge</t>
<t>01: unidirectional switching using a permanent bridge</t>
<t>00: unidirectional switching using a selector bridge</t>
</list></t>
<t>As described in the introduction (section 1.1) a 1+1 protection architecture
is characterized by the use of a permanent bridge at the source node, whereas
the 1:1 and 1:n protection architectures are characterized by the use of a
selector bridge at the source node.</t>
</section>
<section title="Revertive (R) field">
<t>This field indicates that the transmitting endpoint is configured to work
in revertive mode. If there is an inconsistency between the two endpoints,
i.e. one end-point is configured for revertive action and the second end-point
is in non-revertive mode, then the management system SHOULD be notified.
Possible values are:</t>
<t><list style="symbols">
<t>0 – non-revertive mode</t>
<t>1 – revertive mode</t>
</list></t>
</section>
<section title="Fault path (FPath) field">
<t>The Fpath field indicates which path (i.e. working or protection) is
identified to be in a fault condition or affected by an administrative
command. The following are the possible values:</t>
<t><list style="symbols">
<t>0: indicates that the anomaly condition is on the protection
path</t>
<t>1: indicates that the anomaly condition is on the working path</t>
<t>2-255: for future extensions</t>
</list></t>
</section>
<section title="Data path (Path) field">
<t>The Path field indicates which data is being transmitted on the
protection path. Under normal conditions, the protection path
(especially in 1:1 or 1:n architecture) does not need to carry any
user data traffic. If there is a failure/degrade condition on one of
the working paths, then that working path's data traffic will be
transmitted over the protection path. The following are the
possible values:</t>
<t><list style="symbols">
<t>0: indicates that the protection path is not transporting user
data traffic (in 1:n architecture) or transporting redundant user
data traffic (in 1+1 architecture).</t>
<t>1: indicates that the protection path is transmitting user
traffic replacing the use of 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 protection domain
between LER-A and LER-Z, using paths W (working) and P (protection) as
shown in figure 3.</t>
<figure anchor="figure 3" title="Protection domain">
<artwork><![CDATA[
+-----+ //=======================\\ +-----+
|LER-A|// Working Path \\|LER-Z|
| /| |\ |
| ?< | | >? |
| \|\\ Protection Path //|/ |
+-----+ \\=======================// +-----+
|--------Protection Domain--------|
]]></artwork>
</figure>
<section title="Basic operation">
<t>The basic operation of the coordination protocol is to allow the
end-points to notify their peer of the status that is known to that end-point.
The parameters that are notified between the end-points – the local
condition of the protection domain, the blocked path (if there is a blockage
within the protection domain), and the current usage of the protection path.
It should be noted that the messages exchanged between the two end-points may
not be the same at a given point in time, although the states of the
end-points are coordinated. In particular it should be noted that a remote
message MAY not cause the end-point to change the Request field that is being
transmitted while it does affect the Path field (see details in the following
subsections).</t>
<t>The protocol is a single-phase protocol, although it includes a possibility
to extend the protocol for multiple-phased operation. Single-phase implies
that each end-point notifies its peer of a change in the operation (switching
to or from the protection path) and makes the switch without waiting for
acknowledgement.</t>
<t>The following subsections will identify the messages that are transmitted
by the end-point in different scenarios. The messages are described as
REQ(FP, P) – where REQ is the value of the Request field, FP is the
value of the Fpath field, and P is the value of the Path field. All examples
assume a protection domain between LER-A and LER-Z with a single working path
and single protection path (as shown in figure 3).</t>
</section>
<section title="Priority of inputs">
<t>As noted above (in section 3.1.1) the PSC Control Process
accepts input from five local input sources. There is a definition of
priority between the different inputs that may be triggered locally. The
list of local requests in order of priority are (from highest to lowest
priority):</t>
<t><list style="numbers">
<t>Clear (Operator command)</t>
<t>Lockout of protection (Operator command)</t>
<t>Signal Fail on protection (OAM/Control Plane/Server Indication)</t>
<t>Forced switch (Operator command)</t>
<t>Signal Fail on working (OAM/Control Plane/Server Indication)</t>
<t>Clear Signal Fail (OAM/Control Plane/Server Indication)</t>
<t>Manual switch (Operator command)</t>
<t>WTR expires (WTR Timer)</t>
</list></t>
<t>The determination of whether a remote message is accepted or ignored is
a function of the current state of the local LER and the current local
request (see section 3.1.3). Part of this consideration will be included in
the following subsections describing the operation in the different states.</t>
</section>
<section title="Operation of PSC States">
<section title="Normal State">
<t>When the protection domain has no special condition in effect,
the ingress LER 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
LER SHOULD read the data from the working path.</t>
<t>When the end-point is in Normal State it SHOULD transmit a NR(0,0)
message – indicating – Nothing to report and data traffic
is being transmitted on the working path.</t>
<t>When the LER (assume LER-A) is in Normal State the following transitions
are relevant in reaction to a local input (new state SHOULD be marked as
local):
<list style="symbols">
<t>A local Lockout of protection input SHALL cause the LER to go into
Unavailable State and begin transmission of a LO(0,0) message to the
far-end LER (LER-Z).</t>
<t>A local Forced switch input SHALL cause the LER to go into Protecting
administrative state and begin transmission of a FS(1,1) message to the
far-end LER (LER-Z).</t>
<t>A local Signal Fail indication on the protection path SHALL cause the
LER to go into Unavailable state and begin transmission of a SF(0,0) message
to the far-end LER (LER-Z).</t>
<t>A local Signal Fail indication on the working path SHALL cause the LER
to go into Protecting failure state and begin transmission of a SF(1,1) message
to the far-end LER (LER-Z).</t>
<t>A local Manual switch input SHALL cause the LER to go into Protecting
administrative state and begin transmission of a MS(1,1) message to the
far-end LER (LER-Z).</t>
<t>All other local inputs SHOULD be ignored.</t>
</list></t>
<t>In Normal state, remote messages would cause the following reaction from
the LER (new state SHOULD be marked as remote):
<list style="symbols">
<t>A remote Lockout of protection message SHALL cause the LER (LER-A) to go
into Unavailable state, while continuing to transmit the NR(0,0) message.</t>
<t>A remote Forced switch message SHALL cause the LER (LER-A) to go into
Protecting administrative state, and transmit a NR(0,1) message.</t>
<t>A remote Signal Fail message that indicates that the failure is on the
protection path SHALL cause the LER (LER-A) to go into Unavailable state,
while continuing to transmit the NR(0,0) message.</t>
<t>A remote Signal Fail message that indicates that the failure is on the
working path SHALL cause the LER (LER-A) to go into Protecting failure state,
and transmit a NR(0,1) message.</t>
<t>A remote Manual switch message SHALL cause the LER (LER-A) to go into
Protecting administrative state, and transmit a NR(0,1) message.</t>
<t>All other remote messages SHOULD be ignored.</t>
</list></t>
</section>
<section title="Unavailable State">
<t>When the protection path is unavailable – either as a result
of a Lockout operator command, or as a result of a SF or SD detected
on the protection path – then the protection domain is in the
unavailable state. In this state, the data traffic is transmitted and
received on 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 protection path recovers from the signal fail or degraded
situation. Both ends will resume sending the PSC packets over the
protection path, as a result of this recovery.</t>
<t>When in unavailable state the data traffic is being transmitted on
the working path and is not protected. In many cases the remote messages
will not be received (since the protection path is blocked) and the main
effect will be as a result of local inputs.</t>
<t>When the LER (assume LER-A) is in Unavailable State the following
transitions are relevant in reaction to a local input (new state SHOULD
be marked as local):
<list style="symbols">
<t>A local Clear input SHOULD be ignored if the LER is in remote
Unavailable state. If in local Unavailable state due to a Lockout
command, then the input SHALL cause the LER to go to Normal state and
begin transmitting a NR(0,0) message.</t>
<t>A local Lockout of protection input SHALL cause the LER to remain in
Unavailable State and begin transmission of a LO(0,0) message to the
far-end LER (LER-Z).</t>
<t>A local Clear SF indication SHOULD be ignored if the LER is in remote
Unavailable state. If in local Unavailable state due to a Signal Fail
on the protection path and the Clear SF indicates that the protection
path is now cleared, then the input SHALL cause the LER to go to Normal
state and begin transmitting a NR(0,0) message.</t>
<t>A local Forced switch input when in Unavailable state due to a local
or remote failure condition on the protection path SHALL cause the LER to
go into Protecting administrative state and begin transmission of a
FS(1,1) message. When in Unavailable state due to local Lockout input
– this message SHOULD be filtered out by the Local Request Logic.
If Unavailable due to remote Lockout input, then this message SHOULD be
ignored by the PSC Process Logic.</t>
<t>A local Signal Fail indication on the protection path SHALL cause the
LER to remain in Unavailable state and begin transmission of a SF(0,0)
message.</t>
<t>All other local inputs SHOULD be ignored.</t>
</list></t>
<t>If remote messages are being received over the protection path then they
would have the following affect:
<list style="symbols">
<t>A remote Lockout of protection message SHALL cause the LER to remain in
Unavailable state, and continue transmission of the current message (either
NR(0,0) or LO(0,0))</t>
<t>A remote Signal Fail message that indicates that the failure is on the
protection path SHALL cause the LER to remain in Unavailable state and
continue transmission of the current message (either NR(0,0) or SF(0,0)).</t>
<t>A remote No Report, when the LER is remote Unavailable state SHALL
cause the LER to go into Normal state and begin transmission of a NR(0,0)
message. When in local Unavailable state, the message SHALL be ignored.</t>
<t>All other remote messages SHOULD be ignored.</t>
</list></t>
</section>
<section title="Protecting administrative state">
<t>In the protecting state the user data traffic is being transported on
the protection path, while the working path is blocked due to an operator
command, i.e. Forced Switch or Manual Switch.</t>
<t>The following describe the reaction to local input:
<list style="symbols">
<t>A local Clear SHOULD be ignored if in remote Protecting state. If
in local Protecting administrative state then this input SHALL cause
the LER to go into Normal state and begin transmitting a NR(0,0)
message.</t>
<t>A local Lockout of protection input SHALL cause the LER to go into
Unavailable state and begin transmission of a LO(0,0) message.</t>
<t>A local Forced switch input SHALL cause the LER to remain in Protecting
administrative state and begin transmission of a FS(1,1) message.</t>
<t>A local Signal Fail indication on the protection path SHALL cause the
LER to go into Unavailable state and begin transmission of a SF(0,0)
message.</t>
<t>A local Signal Fail indication on the working path SHOULD be filtered
by the Local Request Logic if the protecting state was entered due to an
active local Forced switch operator command. If the protecting state is
due to a remote Forced switch message, then this local indication SHOULD
be filtered by the PSC Process Logic. If the current state is due to a
(local or remote) Manual switch operator command, it shall cause the LER
to go into Protecting failure state and begin transmitting a SF(1,1)
message.</t>
<t>A local Manual switch input SHALL be filtered by the Local Request Logic
if there is an active local Forced switch. If the protecting state is due
to a remote Forced switch command, then this local indication SHOULD be
filtered by the PSC Process Logic. If the current state is due to a (local
or remote) Manual switch operator command, it shall cause the LER to remain
in Protecting administrative state and begin transmission of a MS(1,1)
message.</t>
<t>All other local inputs SHOULD be ignored.</t>
</list></t>
<t>While in Protecting administrative state the LER may receive and react
as follows to remote PSC messages:
<list style="symbols">
<t>A remote Lockout of protection message SHALL cause the LER to go into
Unavailable state and begin transmitting a NR(0,0) message. It should be
noted that this automatically cancels the current Forced switch or Manual
switch command and data traffic is reverted to the working path.</t>
<t>A remote Forced switch message SHOULD be ignored by the PSC Process
Logic if there is an active local Forced switch operator command. If the
Protecting state is due to a remote Forced switch message then the LER
SHALL remain in Protecting administrative state and continue transmission
of the last message. If the Protecting state is due to either a local or
remote Manual switch then the LER SHALL remain in Protecting administrative
state (updating the state information with the proper relevant information)
and begin transmitting a NR(0,1) message.</t>
<t>A remote Signal Fail message indicating a failure on the protection path
SHALL cause the LER to go into Unavailable state and begin transmitting a
NR(0,0) message. It should be noted that this automatically cancels the
current Forced switch or Manual switch command and data traffic is reverted
to the working path.</t>
<t>A remote Signal Fail message indicating a failure on the working path SHALL
be ignored if there is an active local Forced switch command. If the Protecting
state is due to a local or remote Manual switch then the LER SHALL go to
Protecting failure state and begin transmitting a NR(0,1) message.</t>
<t>A remote Manual switch message SHALL be ignored by the PSC Process Logic
if in Protecting state due to a local or remote Forced switch. If in
Protecting state due to a remote Manual switch then the LER SHALL remain in
Protecting administrative state and continue transmitting the current message.
If in Protecting state due to an active local Manual switch then the LER SHALL
remain in Protecting administrative state and continue transmission of the
MS(1,1) message.</t>
<t>A remote DNR(0,0) message SHALL be ignored if in Protecting state due to
a local input. If in Protecting state due to a remote message then the LER
SHALL go to Do-not-revert state and begin transmitting a NR(0,0) message.</t>
<t>A remote NR(0,0) message SHALL be ignored if in Protecting state due to a
local input. If in Protecting state due to a remote message then the LER
SHALL go to Normal state and begin transmitting a NR(0,0) message.</t>
<t>All other remote messages SHALL be ignored.</t>
</list></t>
</section>
<section title="Protecting failure state">
<t>When the protection mechanism has been triggered and the protection domain
has performed a protection switch, the domain is in the protecting failure state.
In this state the normal data traffic is transmitted and received on the
protection path.</t>
<t>The following describe the reaction to local input:
<list style="symbols">
<t>A local Clear SF SHOULD be ignored if in remote Protecting state. If the
Clear SF indicates that the protection path is now cleared (but working is
still in SF condition) then the indicateion SHOULD be ignored. If in
local Protecting failure state and the LER is configured for revertive behavior
then this input SHALL cause the LER to go into Wait-to-restore state, start the
WTR timer, and begin transmitting a WTR(0,1) message. If in local Protecting
failure state and the LER is configured for non-revertive behavior then this
input SHALL cause the LER to go into Do-not-revert state and begin
transmitting a DNR(0,1) message.</t>
<t>A local Lockout of protection input SHALL cause the LER to go into
Unavailable state and begin transmission of a LO(0,0) message.</t>
<t>A local Forced switch input SHALL cause the LER to go into Protecting
administrative state and begin transmission of a FS(1,1) message.</t>
<t>A local Signal Fail indication on the protection path SHALL cause the LER
to go into Unavailable state and begin transmission of a SF(0,0) message.</t>
<t>A local Signal Fail indication on the working path SHALL cause the LER to
remain in Protecting failure state and begin transmitting a SF(1,1) message.</t>
<t>All other local inputs SHOULD be ignored.</t>
</list></t>
<t>While in Protecting failure state the LER may receive and react as follows to
remote PSC messages:
<list style="symbols">
<t>A remote Lockout of protection message SHALL cause the LER to go into
Unavailable state and if in protecting failure state due to a local SF condition
begin transmitting a SF(1,0) message, otherwise transmit a NR(0,0) message.
It should be noted that this may cause loss of user data since the working
path is still in a failure condition.</t>
<t>A remote Forced switch message SHALL cause the LER go into Protecting
administrative state and if in protecting failure state due to a local SF condition
begin transmitting the SF(1,1) message, otherwise begin transmitting NR(0,0).</t>
<t>A remote Signal Fail message indicating a failure on the protection path
SHALL cause the LER to go into Unavailable state and if in protecting failure
state due to a local SF condition begin transmitting a SF(1,0) message,
otherwise begin transmitting NR(0,0) message. It should be noted that this
may cause loss of user data since the working path is still in a failure condition.</t>
<t>If in Protecting state due to a remote message, a remote Wait-to-Restore
message SHOULD cause the LER to go into Wait-to-Restore state and continue
transmission of the current message.</t>
<t>If in Protecting state due to a remote message, a remote Do-not-revert
message SHOULD cause the LER to go into Do-not-revert state and continue
transmission of the current message.</t>
<t>All other remote messages SHALL be ignored.</t>
</list></t>
</section>
<section title="Wait-to-restore state">
<t>The Wait-to-Restore state is used by the PSC protocol to delay reverting to
the normal state, when recovering from a failure condition on the working path,
for the period of the WTR timer to allow the recovering failure to stabilize.
While in the Wait-to-Restore state the data traffic SHALL continue to be
transmitted on the protection path. The natural transition from the
Wait-to-Restore state to Normal state will occur when the WTR timer expires.</t>
<t>When in Wait-to-Restore state the following describe the reaction to local
inputs:
<list style="symbols">
<t>A local Lockout of protection command SHALL cause the LER to Stop the WTR
timer, go into Unavailable state, and begin transmitting a LO(0,0) message.</t>
<t>A local Forced switch command SHALL cause the LER to Stop the WTR timer, go
into Protecting administrative state, and begin transmission of a FS(1,1)
message.</t>
<t>A local Signal Fail indication on the protection path SHALL cause the LER
to Stop the WTR timer, go into Unavailable state, and begin transmission of a
SF(0,0) message.</t>
<t>A local Signal Fail indication on the working path SHALL cause the LER to
Stop the WTR timer, go into Protecting failure state, and begin transmission of
a SF(1,1) message.</t>
<t>A local Manual switch input SHALL cause the LER to Stop the WTR timer, go
into Protecting administrative state and begin transmission of a MS(1,1)
message.</t>
<t>A local WTR expires input SHALL cause the LER to remain in Wait-to-Restore
state and begin transmitting a NR(0,1) message.</t>
<t>All other local inputs SHOULD be ignored.
</t>
</list></t>
<t>When in Wait-to-Restore state the following describe the reaction to remote
messages:
<list style="symbols">
<t>A remote Lockout of protection message SHALL cause the LER to Stop the WTR
timer, go into Unavailable state, and begin transmitting a NR(0,0) message.</t>
<t>A remote Forced switch message SHALL cause the LER to Stop the WTR timer,
go into Protecting administrative state, and begin transmission of a NR(0,1)
message.</t>
<t>A remote Signal Fail message for the protection path SHALL cause the LER
to Stop the WTR timer, go into Unavailable state, and begin transmission of
a NR(0,0) message.</t>
<t>A remote Signal Fail message for the working path SHALL cause the LER to
Stop the WTR timer, go into Protecting failure state, and begin transmission
of a NR(0,1) message.</t>
<t>A remote Manual switch message SHALL cause the LER to Stop the WTR timer,
go into Protecting administrative state and begin transmission of a NR(0,1)
message.</t>
<t>If the WTR timer is running then a remote NR message SHALL be ignored.
If the WTR timer is no longer running then a remote NR message SHALL cause
the LER to go into Normal state and begin transmitting a NR(0,0) message.</t>
<t>All other remote messages SHOULD be ignored.</t>
</list></t>
</section>
<section title="Do-not-revert state">
<t>Do-not-revert state is a continuation of the protecting state when the
protection domain is configured for non-revertive behavior. While in
Do-not-revert state data traffic continues to be transmitted on the protection
path until the administrator sends a command to revert to the Normal state.
It should be noted that there is a fundemental difference between this state
and Normal – whereas Forced Switch in Normal state actually causes a
switch in the transport path used, in Do-not-revert state the Forced switch
just switches the state but the traffic would continue to be transmitted on
the protection path! The command to revert back to Normal state could either
be a Lockout of protection (followed be a Clear command), a Clear command, or
a new form of the Manual switch command [note: This would also require some
kind of agreement, although it seems to have been adopted by ITU-T in G.8031
for Ethernet]. The following description of operation is based on the
Lockout/Clear option mentioned!</t>
<t>When in Do-not-revert state the following describe the reaction to local
input:
<list style="symbols">
<t>A local Lockout of protection command SHALL cause the LER to go into
Unavailable state and begin transmitting a LO(0,0) message.</t>
<t>A local Forced switch command SHALL cause the LER to go into Protecting
administrative state and begin transmission of a FS(1,1) message.</t>
<t>A local Signal Fail indication on the protection path SHALL cause the
LER to go into Unavailable state and begin transmission of a SF(0,0)
message.</t>
<t>A local Signal Fail indication on the working path SHALL cause the LER
to go into Protecting failure state and begin transmission of a SF(1,1)
message.</t>
<t>A local Manual switch input SHALL cause the LER to go into Protecting
administrative state and begin transmission of a MS(1,1) message.</t>
<t>All other local inputs SHOULD be ignored.</t>
</list></t>
<t>When in Do-not-revert state the following describe the reaction to remote
messages:
<list style="symbols">
<t>A remote Lockout of protection message SHALL cause the LER to go into
Unavailable state and begin transmitting a NR(0,0) message.</t>
<t>A remote Forced switch message SHALL cause the LER to go into Protecting
administrative state and begin transmission of a NR(0,1) message.</t>
<t>A remote Signal Fail message for the protection path SHALL cause the LER
to go into Unavailable state and begin transmission of a NR(0,0) message.</t>
<t>A remote Signal Fail message for the working path SHALL cause the LER to
go into Protecting failure state, and begin transmission of a NR(0,1) message.</t>
<t>A remote Manual switch message SHALL cause the LER to go into Protecting
administrative state and begin transmission of a NR(0,1) message.</t>
<t>All other remote messages SHOULD be ignored.</t>
</list></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. -->
<!-- Begin inclusion reference.RFC.5654 -->
<reference anchor="RFC5654">
<front>
<title>Requirements of an MPLS Transport Profile</title>
<author fullname="Ben Niven-Jenkins" initials="B." surname="Niven-Jenkins">
<organization></organization>
</author>
<author fullname="Deborah Brungard" initials="D." surname="Brungard">
<organization></organization>
</author>
<author fullname="Malcolm Betts" initials="M." surname="Betts">
<organization></organization>
</author>
<author fullname="Nurit Sprecher" initials="N." surname="Sprecher">
<organization></organization>
</author>
<author fullname="S. Ueno" initials="S." surname="Ueno">
<organization></organization>
</author>
<date month="September" year="2009" />
<abstract>
<t>This document specifies the requirements of an MPLS Transport Profile
(MPLS-TP). This document is a product of a joint effort of the
International Telecommunications Union (ITU) and IETF 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 International Telecommunications Union -
Telecommunications Standardization Sector (ITU-T).</t>
<t>This work is based on two sources of requirements: MPLS and PWE3
architectures as defined by IETF, and packet transport networks as
defined by ITU-T.</t>
<t>The requirements expressed in this document are for the behavior of
the protocol mechanisms and procedures that constitute building
blocks out of which the MPLS Transport Profile is constructed. The
requirements are not implementation requirements.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5654" />
</reference>
<!-- End inclusion reference.RFC.5654 -->
</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.3031.xml. -->
<reference anchor="RFC3032">
<front>
<title abbrev="MPLS-Arch">MPLS Label Stack Encoding</title>
<author fullname="E. Rosen" initials="E." surname="Rosen">
<organization></organization>
</author>
<author fullname="D. Tappan" initials="D." surname="Tappan">
<organization></organization>
</author>
<author fullname="G. Fedorkow" initials="G." surname="Fedorkow">
<organization></organization>
</author>
<author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
<organization></organization>
</author>
<author fullname="D. Farinacci" initials="D." surname="Farinacci">
<organization></organization>
</author>
<author fullname="T. Li" initials="T." surname="Li">
<organization></organization>
</author>
<author fullname="A. Conta" initials="A." surname="Conta">
<organization></organization>
</author>
<date month="Jan" year="2001" />
<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" />
</reference>
<!-- End inclusion reference.RFC.3032.xml. -->
<!-- Begin inclusion reference.RFC.5659 -->
<reference anchor="RFC5659">
<front>
<title>An Architecture for Multi-Segment Pseudowire Emulation
Edge-to-Edge</title>
<author fullname="Matthew Bocci" initials="M." surname="Bocci">
<organization></organization>
</author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization></organization>
</author>
<date month="October" year="2009" />
<abstract>
<t>This document describes an architecture for extending pseudowire
emulation across multiple packet switched network (PSN) segments.
Scenarios are discussed where each segment of a given edge-to-edge
emulated service spans a different provider's PSN, as are other
scenarios where the emulated service originates and terminates on the
same provider's PSN, but may pass through several PSN tunnel segments
in that PSN. It presents an architectural framework for such multi-
segment pseudowires, defines terminology, and specifies the various
protocol elements and their functions.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5659" />
</reference>
<!-- End inclusion reference.RFC.5659 -->
<!-- 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.G-ACh -->
<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-23 19:47:40 |