Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP)Huawei Technologieshuub@van-helvoort.euETRIryoo@etri.re.krHuawei Technologieszhanghaiyan@huawei.comPhilipsfeng.huang@philips.comChina Mobilelihan@chinamobile.comTelecom Italiaalessandro.dalessandro@telecomitalia.itMPLS Working GroupexampleThe IETF Standards Track solution for MPLS Transport Profile (MPLS&nbhy;TP)
Linear Protection is provided in RFCs 6378, 7271, and 7324. This document describes the pre-standard implementation of
MPLS-TP Linear Protection that has been deployed by several
network operators using equipment from multiple vendors.
At the time of publication, these pre-standard implementations
were still in operation carrying live traffic. The specified mechanism supports 1+1 unidirectional/bidirectional
protection switching and 1:1 bidirectional protection switching.
It is purely supported by the MPLS-TP data plane
and can work without any control plane. The IETF Standards Track solution for MPLS Transport Profile (MPLS&nbhy;TP)
Linear Protection
is provided in ,
,
and . This document describes the pre-standard implementation of
MPLS-TP Linear Protection that has been deployed by several
network operators using equipment from multiple vendors.
At the time of publication, these pre-standard implementations
were still in operation carrying live traffic. This implementation was considered in the MPLS WG; however, a
different path was chosen.This document may be useful in the future if a vendor or operator
is trying to
interwork with a different vendor or operator
who has deployed the pre-standard implementation,
and it provides a permanent record of the pre-standard implementation.
It is also worth noting that the experience gained during deployment
of the implementations of this document was used to refine
.
MPLS-TP is defined as the transport profile of MPLS technology
to allow its deployment in transport networks.
A typical feature of a transport network is that it can provide fast
protection switching for end-to-end transport paths and transport
path segments.
The protection-switching time is generally required
to be less than 50 ms to meet the strict requirements of
services such as voice, private line, etc. The goal of a linear protection-switching mechanism is to satisfy the
requirement of fast protection switching for an MPLS-TP network.
Linear protection switching means that,
for one or more working transport entities (working paths),
there is one protection transport entity (protection path),
which is disjoint from any of the working transport entities,
ready to take over the
service transmission when a working transport entity has failed. This document specifies a 1+1 unidirectional protection-switching
mechanism for a unidirectional transport entity (either point to point
or point to multipoint) as well as a bidirectional point-to-point
transport entity and a 1+1/1:1 bidirectional protection-switching
mechanism for a point-to-point bidirectional transport entity.
Since bidirectional protection switching needs the coordination
of the two endpoints of the transport entity,
this document also specifies the Automatic Protection Switching (APS)
protocol, which is used for this purpose.The linear protection mechanism described in this document is
applicable to both Label Switched Paths (LSPs) and
Pseudowires (PWs).The APS protocol specified in this document is based on the same
principles and behavior of the APS protocol designed for
Synchronous Optical Network (SONET)
/ Synchronous Digital Hierarchy (SDH)
,
Optical Transport Network (OTN) , and
Ethernet
and provides commonality with the established operation models
utilized in transport network technologies
(e.g., SDH/SONET, OTN, and Ethernet).
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 .This document uses the following acronyms:APSAutomatic Protection SwitchingDNRDo not RevertEXERExerciseG-AChGeneric Associated ChannelFSForced SwitchLOLockout of ProtectionLSPLabel Switched PathMPLS-TPMPLS Transport ProfileMSManual SwitchMS-PManual Switch to Protection transport entityMS-WManual Switch to Working transport entityNRNo RequestOAMOperations, Administration, and MaintenanceOTNOptical Transport NetworkPDUProtocol Data UnitPWPseudowireRRReverse RequestSDSignal DegradeSD-PSignal Degrade on Protection transport entitySD-WSignal Degrade on Working transport entitySDHSynchronous Digital HierarchySFSignal FailSF-PSignal Fail on Protection transport entitySF-WSignal Fail on Working transport entitySONETSynchronous Optical NetworkWTRWait to RestoreTo guarantee the protection-switching time for a working transport
entity, its protection transport entity is always preconfigured
before the failure occurs. Normally, traffic will be
transmitted and received on the working transport entity.
Switching to the protection transport entity is usually triggered by
link or node failure, external commands, etc. Note that external
commands are often used in transport networks by operators, and they
are very useful in cases of service adjustment, path maintenance, etc.
In the 1+1 architecture, the protection transport entity is associated
with a working transport entity. The normal traffic is permanently
bridged onto both the working transport entity and the protection
transport entity at the source endpoint of the protected domain. The
normal traffic on working and protection transport entities is
transmitted simultaneously to the destination
sink endpoint of the protected domain,
where a selection between the working and protection transport
entity is made based on predetermined criteria, such as signal fail
and signal degrade indications. In the 1:1 architecture, the protection transport entity is associated
with a working transport entity. When the working transport entity
is determined to be impaired, the normal traffic MUST be transferred
from the working to the protection transport entity at both the
source and sink endpoints of the protected domain. The selection
between the working and protection transport entities is made based
on predetermined criteria, such as signal fail and signal degrade
indications from the working or protection transport entity.The bridge at the source endpoint can be realized in two ways: it is
either a selector bridge or a broadcast bridge. With a selector
bridge, the normal traffic is connected either to the working
transport entity or the protection transport entity. With a broadcast
bridge, the normal traffic is permanently connected to the working
transport entity, and in case a protection switch is active, it is also
connected to
the protection transport entity. The broadcast bridge is recommended to
be used in revertive mode only.Details for the 1:n protection-switching architecture are out of
scope of this document and will be
provided in a different document in the future. It is worth noting that the APS protocol defined here is capable of
supporting 1:n operations.The linear protection-switching types can be a unidirectional
switching type or a bidirectional switching type.
Unidirectional switching type: Only the affected direction of
the working transport entity is switched to the protection transport
entity; the selectors at each endpoint operate independently.
This switching type is recommended to be used for 1+1 protection
in this document.Bidirectional switching type: Both directions of the working transport
entity, including the affected direction and the unaffected
direction, are switched to the protection transport entity. For
bidirectional switching, the APS
protocol is required to coordinate the two endpoints so that both
have the same bridge and selector settings, even for a
unidirectional failure. This type is applicable for 1+1 and 1:1
protection.The linear protection operation types can be a non-revertive
operation type or a revertive operation type.
Non-revertive operation: The normal traffic will not be switched
back to the working transport entity even after a protection
switching cause has cleared. This is generally accomplished by
replacing the previous switch request with a "Do not Revert (DNR)"
request, which has a low priority.Revertive operation: The normal traffic is restored to the working
transport entity after the condition(s) causing the protection
switching has cleared. In the case of clearing a command (e.g.,
Forced Switch), this happens immediately. In the case of clearing
a defect, this generally happens after the expiry of a "Wait
to Restore (WTR)" timer, which is used to avoid chattering of
selectors in the case of intermittent defects.Fault conditions mean the requests generated by the local
Operations, Administration, and Maintenance (OAM) function.
Signal Fail (SF): If an endpoint detects a failure by an OAM
function or other mechanism, it will submit a local signal failure
(local SF) to the APS module to request a protection switch.
The local SF could be on the working transport entity
(Signal Fail on Working transport entity (SF-W))
or the protection transport entity
(Signal Fail on Protection transport entity (SF-P)).Signal Degrade (SD): If an endpoint detects signal degradation
by an OAM function or other mechanism,
it will submit a local signal degrade
(local SD) to the APS module to request a protection switching.
The local SD could be on the working transport entity
(Signal Degrade on Working transport entity (SD-W))
or the protection transport entity
(Signal Degrade on Protection transport entity (SD-P)).The external command issues an appropriate external request to the
protection process.These commands are applied to both local and remote nodes.
When the APS protocol is present, these commands, except the Clear command,
are signaled to the far end of the connection.
In bidirectional switching, these commands affect the bridge
and selector at both ends.
Lockout of Protection (LO): This command is used to provide
the operator a tool for temporarily disabling access to the protection
transport entity.Manual Switch (MS): This command is used to provide the operator a
tool for temporarily switching normal traffic to the
working transport entity
(Manual Switch to Working transport entity (MS-W)) or to the
protection transport entity
(Manual Switch to Protection transport entity (MS-P)), unless a
higher priority switch request (i.e., LO, FS, or SF)
is in effect.Forced Switch (FS): This command is used to provide the operator a
tool for temporarily switching normal traffic from the working
transport entity to the protection transport entity, unless a higher
priority switch request (i.e., LO or SF-P) is in effect.Exercise (EXER): Exercise is a command to test if the APS
communication is operating correctly.
The EXER command SHALL NOT affect the state of the protection selector
and bridge.Clear: This command between management and the local protection
process is not a request sent by APS to other endpoints. It is
used to clear the active near-end external command or WTR state.These commands apply only to the near end (local node) of
the protection group.
Even when an APS protocol is supported,
they are not signaled to the far end.
Freeze: This command freezes the state of the protection group.
Until the freeze is cleared, additional near-end commands are rejected,
and condition changes and received APS information are ignored.
When the Freeze command is cleared, the state of the protection group
is recomputed based on the condition and received APS information.Because the freeze is local, if the freeze is issued at one end only,
a failure of protocol can occur as the other end is open to accept
any operator command or fault condition. Clear Freeze: This command clears the local freeze. | | --------+->
| \ | | |
| \ |---------------------------------------| |
| -+---------------------------------------| |
| source |---------------------------------------| sink |
+-----------+ Protection transport entity +-----------+
(normal condition)
+-----------+ +-----------+
| |---------------------------------------| |
| -+------------------XX-------------------+ |
| / |---------------------------------------| |
| / | Working transport entity (failure) | |
--|-------> | | --------+->
| \ | | / |
| \ |---------------------------------------| / |
| -+---------------------------------------+- |
| source |---------------------------------------| sink |
+-----------+ Protection transport entity +-----------+
(failure condition)
]]>1+1 unidirectional protection switching is the simplest protection
switching mechanism. The normal traffic is permanently bridged on
both the working and protection transport entities at the source
endpoint of the protected domain. In the normal condition, the sink
endpoint receives traffic from the working transport entity. If the sink
endpoint detects a failure on the working transport entity, it will
switch to receive traffic from the protection transport entity. 1+1
unidirectional protection switching is recommended to be used for
unidirectional transport.Note that 1+1 unidirectional protection switching does not use the APS
coordination protocol since it only performs protection switching
based on the local request.+ \ |
| sink / /|---------------------------------------|\ \ sink |
<-+-------/ / | Working transport entity | --\-------+->
--+--------> | | <------+--
| source \ | | / source|
| \|---------------------------------------| / |
| +-------------------------------------->| / |
| |<--------------------------------------+- |
| APS <...................................................> APS |
| |---------------------------------------+ |
+-----------+ Protection transport entity +-----------+
(normal condition)
+-----------+ +-----------+
| |---------------------------------------| |
| +<----------------XX--------------------+- |
| +-------------------------------------->+ \ |
| /|---------------------------------------| \ |
| source / | Working transport entity (failure) | \ source|
--+--------> | | \<-----+--
<-+------- \ | | --/------+->
| sink \ \|---------------------------------------| / / sink |
| \ +-------------------------------------->+- / |
| --+<--------------------------------------+-/ |
| APS <...................................................> APS |
| |---------------------------------------+ |
+-----------+ Protection transport entity +-----------+
(failure condition)
]]>In 1+1 bidirectional protection switching, for each direction, the
normal traffic is permanently bridged on both the working and
protection transport entities at the source endpoint of the
protected domain. In the normal condition, for each direction, the sink
endpoint receives traffic from the working transport entity.If the sink endpoint detects a failure on the working transport
entity, it will switch to receive traffic from the protection transport
entity. It will also send an APS message to inform the sink endpoint
on the other direction to switch to receive traffic from the protection
transport entity.The APS mechanism is necessary to coordinate the two endpoints of
the transport entity and to implement 1+1 bidirectional protection switching
even for a unidirectional failure.+ \ |
| sink / /|---------------------------------------|\ \ source|
<-+-------/ / | Working transport entity | \ <-------+--
--+--------> | | ---------+->
| source | | sink |
| |---------------------------------------| |
| | | |
| | | |
| APS <...................................................> APS |
| |---------------------------------------| |
+-----------+ Protection transport entity +-----------+
(normal condition)
+-----------+ +-----------+
| |---------------------------------------| |
| | \/ | |
| | /\ | |
| |---------------------------------------| |
| source | Working transport entity (failure) | sink |
--+-------> | | --------+->
<-+------- \ | | / <------+--
| sink \ \ |---------------------------------------| / / source|
| \ -+-------------------------------------->+- / |
| --+<--------------------------------------+-- |
| APS <...................................................> APS |
| |---------------------------------------+ |
+-----------+ Protection transport entity +-----------+
(failure condition)
]]>In 1:1 bidirectional protection switching, for each direction, the
source endpoint sends traffic on either the working transport entity or
the protection transport entity. The sink endpoint receives the traffic
from the same transport entity on which the source endpoint sends the traffic.In the normal condition, for each direction,
the source and sink
endpoints send and receive traffic from the working transport entity.If the sink endpoint detects a failure on the working transport
entity, it will switch to send and receive traffic from the protection
transport entity. It will also send an APS message to inform the sink
endpoint on another direction to switch to send and receive traffic
from the protection transport entity.The APS mechanism is necessary to coordinate the two endpoints of
the transport entity and implement 1:1 bidirectional protection switching
even for a unidirectional failure.This APS protocol is based upon the APS protocol defined in
Section 11 of .
See that reference for further definition of the Protocol Data Unit
(PDU) fields
and protocol details beyond the description in this document.
APS packets MUST be sent over a Generic Associated Channel (G-ACh)
as defined in .The format of APS PDU is specified in
below.The following values MUST be used for APS PDU:
Channel Type: The Channel Type MUST be configurable
by the implementation.
During deployment, the local system administrator provisioned
the value 0x7FFA.
This is a code point value in the range of experimental Channel
Types as described in RFC 5586, Section 10.
Maintenance Entity group Level (MEL):
The MEL value to set and check MUST be configurable.
The DEFAULT value MUST be "111".
With co-routed bidirectional transport paths,
the configured MEL MUST be the same in both directions.
Version: 0x00 OpCode: 0x27 (=0d39) Flags: 0x00TLV Offset: 4End TLV: 0x00The format of the APS-specific information is defined in
.
All bits defined as "Reserved" MUST be transmitted as 0
and ignored on reception.
Request/State: The four bits indicate the protection-switching request type.
See
for the code of each request/state type.In case that there are multiple protection-switching requests, only
the protection-switching request with the highest priority MUST be
processed.Protection Type (Pr.Type): The four bits are used to specify the protection type.
A: reserved (set by default to 1)
B: 0 - 1+1 (permanent bridge)
1 - 1:1 (no permanent bridge)
D: 0 - Unidirectional switching
1 - Bidirectional switching
R: 0 - Non-revertive operation
1 - Revertive operation
Requested Signal: This byte is used to indicate the traffic that the near-end requests
to be carried over the protection entity.
value = 0: Null traffic
value = 1: Normal traffic 1
value = 2~255: Reserved
Bridged Signal: This byte is used to indicate the traffic that is bridged onto the
protection entity.
value = 0: Null traffic
value = 1: Normal traffic 1
value = 2~255: Reserved
Bridge Type (T): This bit is used to further specify the type of non-permanent bridge
for 1:1 protection switching.
value = 0: Selector bridge
value = 1: Broadcast bridge
Reserved: This field MUST be set to zero. The APS message MUST be transported on the protection transport entity
by encapsulation with the protection transport entity label
(the label of the LSP used to transport protection traffic).
If an endpoint receives APS-specific information from
the working transport entity,
it MUST ignore this information and MUST report the failure of
protocol defect (see ) to the operator.
A new APS packet MUST be transmitted immediately when a change in the
transmitted status occurs. The first three APS packets MUST be
transmitted as fast as possible only if the APS information to be
transmitted has been changed so that fast protection switching is
possible, even if one or two APS packets are lost or corrupted. The
interval of the first three APS packets SHOULD be 3.3 ms. APS packets
after the first three MUST be transmitted with the interval of 5
seconds.If no valid APS-specific information is received, the last valid
received information remains applicable.In order to coordinate timing of protection switches at multiple
layers, a hold-off timer MAY be required. The purpose is to allow a
server-layer protection switch to have a chance to fix the problem
before switching at a client layer.
Each selector SHOULD have a provisioned hold-off timer. The
suggested range of the hold-off timer is 0 to 10 seconds in steps of
100 ms (accuracy of +/-5 ms).
When a new defect or more severe defect occurs (new SF or SD) on the
active transport entity (the transport entity that currently carries
and selects traffic), this event will not
be reported immediately to protection switching if the provisioned
hold-off timer value is non-zero. Instead, the hold-off timer SHALL be
started. When the hold-off timer expires, it SHALL be checked whether
a defect still exists on the transport entity that started the timer.
If it does, that defect SHALL be reported to protection switching. The
defect need not be the same one that started the timer.
This hold-off timer mechanism SHALL be applied for both working and
protection transport entities.
In revertive mode of operation, to prevent frequent operation of the
protection switch due to an intermittent defect,
a failed working transport entity MUST become fault free.
After the failed working transport entity meets this criterion,
a fixed period of time SHALL elapse before a normal
traffic signal uses it again. This period, called a WTR period,
MAY be configured by the operator in 1 minute steps between 5 and 12
minutes; the default value is 5 minutes.
An SF or SD condition will override the WTR.
To activate the WTR timer appropriately, even when both ends concurrently
detect clearance of SF-W and SD-W,
when the local state transits from SF-W or SD-W to No Request (NR)
with the requested signal number 1, the previous local state, SF-W or SD-W,
MUST be memorized.
If both the local state and far-end state are NR with the requested signal
number 1, the local state transits to WTR only when the previous local
state is SF-W or SD-W.
Otherwise, the local state transits to NR with the requested signal number 0.
In revertive mode of operation, when the protection is no longer
requested, i.e., the failed working transport entity is no longer in SF or
SD condition (and assuming no other requesting transport entities),
a local WTR state will be activated.
Since this state becomes the highest in priority,
it is indicated on the APS signal
and maintains the normal traffic signal from the previously failed working
transport entity on the protection transport entity.
This state SHALL normally time out and become an NR state.
The WTR timer deactivates earlier when any request of higher priority
request preempts this state.
The commands Clear, LO, FS, MS, and EXER are accepted or rejected
in the context of previous commands, the condition of the working and
protection entities in the protection group, and (in
bidirectional switching only) the APS information received.
The Clear command MUST be only valid if a near-end LO, FS, MS, or EXER
command is in effect or if a WTR state is present at the near end
and rejected otherwise. This command will remove the near-end command
or WTR state, allowing the next lower-priority condition or
(in bidirectional switching) APS request to be asserted.
Other commands MUST be rejected unless they are higher priority than
the previously existing command, condition, or (in bidirectional switching)
APS request. If a new command is accepted, any previous,
lower-priority command that is overridden MUST be forgotten.
If a higher priority command overrides a lower-priority condition or
(in bidirectional switching) APS request, that other request will be
reasserted if it still exists at the time the command is cleared.
If a command is overridden by a condition or (in bidirectional switching)
APS request, that command MUST be forgotten.
Exercise is a command to test if the APS communication is operating
correctly. It is lower priority than any "real" switch request.
It is only valid in bidirectional switching, since this is the only place
where you can get a meaningful test by looking for a response.
The Exercise command SHALL issue the command with the same requested and
bridged signal numbers of the NR, Reverse Request (RR), or DNR request
that it replaces.
The valid response will be an RR with the
corresponding requested and bridged signal numbers.
When Exercise commands are input at both ends, an EXER, instead of RR,
MUST be transmitted from both ends.
The standard response to DNR MUST be DNR rather than NR.
When the exercise command is cleared, it MUST be replaced with NR or RR
if the requested signal number is 0 and DNR or RR if
the requested signal number is 1.
| timer logic |----------->| request |
+-------------+ | logic |
Other local requests ----------------->| |
(LO, FS, MS, EXER, Clear) +----------+
|
| Highest
| local request
|
Remote APS V
message +-------+ Remote APS +----------------+
------------->| APS | request/state | APS process |
(received | check |-------------->| logic |
from far end) +-------+ +----------------+
| ^ | |
| | | Signaled |
| | | APS |
| | Txed | |
| | "Requested V |
| | Signal" +-----------+ |
| +-----------------| APS mess. | |
| | generator | |
| +-----------+ |
| | |
V | |
Failure of V |
protocol APS message |
detection V
Set local
bridge/selector
]]> describes the protection-switching logic.
One or more local protection-switching requests may be active. The
"local request logic" determines which of these requests is highest
using the order of priority given in . This highest local
request information SHALL be passed on to the "APS process logic". Note
that an accepted Clear command, clearance of SF or SD, or expiration of
the WTR timer SHALL NOT be processed by the local request logic but
SHALL be considered as the highest local request and submitted to the
APS process logic for processing.
The remote APS message is received from the far end and is subjected
to the validity check and mismatch detection in "APS check". Failure
of protocol situations are as follows:
The "B" field mismatch due to incompatible provisioning;
The reception of the APS message from the working entity due to
working/protection configuration mismatch;
No match in sent "Requested Signal" and received "Requested
Signal" for more than 50 ms;
No APS message is received on the protection transport entity
during at least 3.5 times the long APS interval (e.g., at least
17.5 seconds), and there is no defect on the protection transport
entity.
Provided the "B" field matches:
If the "D" bit mismatches, the bidirectional side will fall back to
unidirectional switching.
If the "R" bit mismatches, one side will clear switches to WTR
and the other will clear to DNR. The two sides will interwork
and the traffic is protected.
If the "T" bit mismatches, the side using a broadcast bridge will
fall back to using a selector bridge.
The APS message with invalid information MUST be ignored, and the
last valid received information remains applicable.
The linear protection-switching algorithm SHALL commence immediately
every time one of the input signals changes, i.e., when the status of
any local request changes, or when different APS-specific
information is received from the far end. The consequent actions of
the algorithm are also initiated immediately, i.e., change the local
bridge/selector position (if necessary), transmit new APS-specific
information (if necessary), or detect the failure of protocol defect
if the protection switching is not completed within 50 ms.
The state transition is calculated in the "APS process logic" based
on the highest local request, the request of the last received
"Request/State" information, and state transition tables defined in
, as follows:
If the highest local request is Clear, clearance of SF or SD,
or expiration of WTR, a state transition is calculated first
based on the highest local request and state machine table for
local requests to obtain an intermediate state. This intermediate
state is the final state in case of clearance of SF-P; otherwise,
starting at this intermediate state, the last received far-end
request and the state machine table for far-end requests are used
to calculate the final state.
If the highest local request is neither Clear nor clearance of
SF or of SD nor expiration of WTR, the APS process logic
compares the highest local request with the request of the last
received "Request/State" information
based on .
If the highest local request has higher or equal priority, it
is used with the state transition table for local requests
defined in
to determine the final state; otherwise,
The request of the last received "Request/State" information is
used with the state transition table for far-end requests
defined in
to determine the final state.
The "APS message generator" generates APS-specific information with
the signaled APS information for the final state from the state
transition calculation (with coding as described in
).
In general, once a switch has been completed due to a request,
it will not be overridden by another request of the same priority
(first-come, first-served policy).
Equal priority requests from both sides of a bidirectional protection group
are both considered valid, as follows:
If the local state is NR, with the requested signal number 1,
and the far-end state is NR, with the requested signal number 0,
the local state transits to NR with the requested signal number 0.
This applies to the case when the remote request for switching to
the protection transport entity has been cleared.
If both the local and far-end states are NR,
with the requested signal number 1, the local state transits
to the appropriate new state
(DNR state for non-revertive mode and WTR state for revertive mode).
This applies to the case when the old request has been
cleared at both ends.
If both the local and far-end states are RR,
with the same requested signal number,
both ends transit to the appropriate new state according to
the requested signal number. This
applies to the case of concurrent deactivation of EXER from both ends.
In other cases, no state transition occurs,
even if equal priority requests are activated from both ends.
Note that if MSs are issued simultaneously to both working and protection
transport entities, either as local or far-end requests,
the MS to the working transport entity is considered as having higher
priority than the MS to the protection transport entity.
Signal degrade on the protection transport entity has the same priority
as signal degrade on the working transport entity.
As a result, if an SD condition affects both transport entities,
the first SD detected MUST NOT be overridden by the second SD detected.
If the SD is detected simultaneously, either as local or far-end requests
on both working and protection transport entities, then the SD on the
standby transport entity MUST be considered as having higher priority than
the SD on the active transport entity,
and the normal traffic signal continues to be selected from
the active transport entity (i.e., no unnecessary protection switching is
performed).
In the preceding sentence, "simultaneously" relates to the occurrence
of SD on both the active and standby transport entities at input to
the protection-switching process at the same time, or as long as an
SD request has not been acknowledged by the remote end in bidirectional
protection switching.
In this section, state transition tables for the following protection
switching configurations are described.
1:1 bidirectional (revertive mode, non-revertive mode); 1+1 bidirectional (revertive mode, non-revertive mode); 1+1 unidirectional (revertive mode, non-revertive mode).
Note that any other global or local request that is not described in
state transition tables does not trigger any state transition.
The states specified in the state transition tables can be described
as follows:
NR: NR is the state entered by the local priority
under all conditions where no local protection-switching requests
(including WTR and DNR) are active. NR can
also indicate that the highest local request is overridden by the
far-end request, whose priority is higher than the highest local
request. Normal traffic signal is selected from the corresponding
transport entity. LO, SF-P, SD-P: The access by the normal traffic to the
protection transport entity is NOT allowed in this state.
The normal traffic is carried by the working
transport entity, regardless of the fault/degrade condition
possibly present (due to the highest priority of the switching
triggers leading to this state).
FS, SF-W, SD-W, MS-W, MS-P: A switching trigger NOT resulting in
the protection transport entity unavailability is present. The
normal traffic is selected either from the corresponding working
transport entity or from the protection transport entity,
according to the behavior of the specific switching trigger.
WTR: In revertive operation, after the clearing of an
SF-W or SD-W, this maintains normal traffic as
selected from the protection transport entity until the WTR
timer expires or another request with higher priority,
including the Clear command, is received. This is used to prevent
frequent operation of the selector in the case of intermittent
failures.
DNR: In non-revertive operation, this is used to
maintain a normal traffic to be selected from the protection
transport entity.
EXER: Exercise of the APS protocol.
RR: The near end will enter and signal Reverse
Request only in response to an EXER from the far end.
[State transition tables are shown at the end of the PDF form
of this document.]MPLS-TP is a subset of MPLS and so builds upon many of the aspects of
the security model of MPLS. MPLS networks make the assumption that
it is very hard to inject traffic into a network and equally hard to
cause traffic to be directed outside the network. The control-plane
protocols utilize hop-by-hop security and assume a "chain-of-trust"
model such that end-to-end control-plane security is not used. For
more information on the generic aspects of MPLS security, see
.
This document describes a protocol carried in the G-ACh
and so is dependent on the security of the G-ACh, itself.
The G-ACh is a generalization of the associated channel defined in
.
Thus, this document relies heavily on the security mechanisms
provided for the associated channel and described in those two
documents.
The authors would like to thank Hao Long, Vincenzo Sestito, Italo
Busi, Igor Umansky, and Andy Malis
for their input to and review of the current
document.Types and characteristics of SDH network protection architectures
International Telecommunications UnionOptical Transport Network (OTN): Linear protection
International Telecommunications UnionEthernet linear protection switching
International Telecommunications UnionSynchronous Optical Network (SONET) -
Automatic Protection Switching
American National Standards Institute
The sequence diagrams shown in this section are only a few examples
of the APS operations. The first APS message, which differs from the
previous APS message, is shown. The operation of hold-off timer is
omitted. The fields whose values are changed during APS packet
exchange are shown in the APS packet exchange. They are Request/State,
requested traffic, and bridged traffic. For an example, SF(0,1)
represents an APS packet with the following field values:
Request/State = SF, Requested Signal = 0, and Bridged Signal = 1. The
values of the other fields remain unchanged from the initial
configuration. The signal numbers 0 and 1 refer to null signal and
normal traffic signal, respectively. W(A->Z) and P(A->Z) indicate the
working and protection paths in the direction of A to Z, respectively.
Example 1. 1:1 bidirectional protection switching (revertive mode) -
Unidirectional SF case
|
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z->A)) |
|---- SF(1,1)----->| (3)
|<----- NR(1,1)----|
(4) | |
| |
(5) | (Recovery) |
|---- WTR(1,1)---->|
/| |
WTR timer | |
\| |
(6) |---- NR(0,0)----->| (7)
(8) |<----- NR(0,0)----|
| |
]]>The protected domain is operating without any defect, and the
working entity is used for delivering the normal traffic.
Signal Fail occurs on the working entity in the Z to A direction.
Selector and bridge of node A select protection entity. Node A
generates an SF(1,1) message.
Upon receiving SF(1,1), node Z sets selector and bridge to
protection entity. As there is no local request in node Z, node Z
generates an NR(1,1) message.
Node A confirms that the far end is also selecting protection
entity.
Node A detects clearing of the SF condition, starts the WTR timer,
and sends a WTR(1,1) message.
At expiration of the WTR timer, node A sets selector and bridge
to working entity and sends an NR(0,0) message.
Node Z is notified that the far-end request has been cleared and
sets selector and bridge to working entity.
It is confirmed that the far end is also selecting working entity.
Example 2. 1:1 bidirectional protection switching (revertive mode) -
Bidirectional SF case
| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z<->A)) | (2)
|<---- SF(1,1)---->|
(3) | | (3)
| |
(4) | (Recovery) | (4)
|<---- NR(1,1)---->|
(5) |<--- WTR(1,1)---->| (5)
/| |\
WTR timer | | WTR timer
\| |/
(6) |<---- NR(1,1)---->| (6)
(7) |<----- NR(0,0)--->| (7)
(8) | | (8)
]]>
The protected domain is operating without any defect, and the
working entity is used for delivering the normal traffic.
Nodes A and Z detect local SF conditions on the working
entity, set selector and bridge to protection entity, and generate
SF(1,1) messages.
Upon receiving SF(1,1), each node confirms that the far end
is also selecting protection entity.
Each node detects clearing of the SF condition and sends an NR(1,1)
message as the last received APS message was SF.
Upon receiving NR(1,1), each node starts the WTR timer and
sends WTR(1,1).
At expiration of the WTR timer, each node sends NR(1,1) as
the last received APS message was WTR.
Upon receiving NR(1,1), each node sets selector and bridge
to working entity and sends an NR(0,0) message.
It is confirmed that the far end is also selecting working entity.
Example 3. 1:1 bidirectional protection switching (revertive mode) -
Bidirectional SF case - Inconsistent WTR timers
| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z<->A)) | (2)
|<---- SF(1,1)---->|
(3) | | (3)
| |
(4) | (Recovery) | (4)
|<---- NR(1,1)---->|
(5) |<--- WTR(1,1)---->| (5)
/| |\
WTR timer | | |
\| | WTR timer
(6) |----- NR(1,1)---->| | (7)
| |/
(9) |<----- NR(0,0)----| (8)
|---- NR(0,0)----->| (10)
]]>
The protected domain is operating without any defect, and the
working entity is used for delivering the normal traffic.
Nodes A and Z detect local SF conditions on the working
entity, set selector and bridge to protection entity, and generate
SF(1,1) messages.
Upon receiving SF(1,1), each node confirms that the far end
is also selecting protection entity.
Each node detects clearing of the SF condition and sends an NR(1,1) message
as the last received APS message was SF.
Upon receiving NR(1,1), each node starts the WTR timer and
sends WTR(1,1).
At expiration of the WTR timer in node A, node A sends an NR(1,1)
message as the last received APS message was WTR.
At node Z, the received NR(1,1) is ignored as the local WTR
has a higher priority.
At expiration of the WTR timer in node Z, node Z sets
selector and bridge to working entity and sends an NR(0,0) message.
Upon receiving NR(0,0), node A sets selector and bridge to
working entity and sends an NR(0,0) message.
It is confirmed that the far end is also selecting working
entity.
Example 4. 1:1 bidirectional protection switching (non-revertive
mode) - Unidirectional SF on working followed by unidirectional SF on
protection
| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z->A)) |
|----- SF(1,1)---->| (3)
(4) |<----- NR(1,1)----|
| |
| |
(5) | (Recovery) |
|----- DNR(1,1)--->| (6)
|<--- DNR(1,1)---->|
| |
| |
| (SF on P(A->Z)) | (7)
(8) |<--- SF-P(0,0)----|
|---- NR(0,0)----->|
| |
| |
| (Recovery) | (9)
|<----- NR(0,0)----|
| |
]]>
The protected domain is operating without any defect, and the
working entity is used for delivering the normal traffic.
Signal Fail occurs on the working entity in the Z to A direction.
Selector and bridge of node A select the protection entity. Node A
generates an SF(1,1) message.
Upon receiving SF(1,1), node Z sets selector and bridge to
protection entity. As there is no local request in node Z, node Z
generates an NR(1,1) message.
Node A confirms that the far end is also selecting protection
entity.
Node A detects clearing of the SF condition and sends a DNR(1,1)
message.
Upon receiving DNR(1,1), node Z also generates a DNR(1,1)
message.
Signal Fail occurs on the protection entity in the A to Z
direction. Selector and bridge of node Z select the working entity.
Node Z generates an SF-P(0,0) message.
Upon receiving SF-P(0,0), node A sets selector and bridge to
working entity and generates an NR(0,0) message.
Node Z detects clearing of the SF condition and sends an NR(0,0)
message.
Exmaple 5. 1:1 bidirectional protection switching (non-revertive
mode) - Bidirectional SF on working followed by bidirectional SF on
protection
| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(A<->Z)) | (2)
(3) |<---- SF(1,1)---->| (3)
| |
| |
(4) | (Recovery) | (4)
(5) |<---- NR(1,1)---->| (5)
|<--- DNR(1,1)---->|
| |
| |
(6) | (SF on P(A<->Z)) | (6)
(7) |<--- SF-P(0,0)--->| (7)
| |
| |
(8) | (Recovery) | (8)
|<---- NR(0,0)---->|
| |
]]>
The protected domain is operating without any defect, and the
working entity is used for delivering the normal traffic.
Nodes A and Z detect local SF conditions on the working
entity, set selector and bridge to protection entity, and generate
SF(1,1) messages.
Upon receiving SF(1,1), each node confirms that the far end
is also selecting protection entity.
Each node detects clearing of the SF condition and sends an NR(1,1) message
as the last received APS message was SF.
Upon receiving NR(1,1), each node sends DNR(1,1).
Signal Fail occurs on the protection entity in both directions.
Selector and bridge of each node selects the working entity. Each
node generates an SF-P(0,0) message.
Upon receiving SF-P(0,0), each node confirms that the far
end is also selecting working entity.
Each node detects clearing of the SF condition and sends an NR(0,0) message.