"Shared M:N". If Extra Traffic is supported over a set of the
protection links, then the bandwidth parameters for the set of
protection links MUST also be announced. The differentiation
between bandwidth for working and protect links is made using
priority mechanisms.
If there is a failure on a working link, then the affected
LSP(s) MUST be switched to a protection link, pre-empting Extra
Traffic if necessary. The bandwidth for the protection link
MUST be adjusted accordingly.
o Signaling: To establish an LSP on the working link, the Link
Protection object/TLV indicating "Shared M:N" SHOULD be
included in the signaling request message for that LSP. To
establish an LSP on the protection link, the appropriate
priority (indicating Extra Traffic) SHOULD be used. These
objects/TLVs are defined in [RFC3471]. If the Link Protection
object/TLV is not used, link selection is a matter of local
policy.
o For link management, both nodes MUST have a consistent view of
the link protection association for the links. This can be
done using LMP [RFC4204] or via manual configuration.
2.5. Messages
The following messages are used in local span protection procedures.
These messages SHOULD be delivered reliably. Therefore, the protocol
mechanisms used to deliver these messages SHOULD provide sequencing,
acknowledgement, and retransmission. The protocol SHOULD also handle
situations where the message(s) cannot be delivered.
The messages described in the following subsections are abstract;
their format and encoding will be described in separate documents.
2.5.1. Failure Indication Message
This message is sent from the slave to the master to indicate the
identities of one or more failed working links. This message MAY not
be necessary when the transport plane technology itself provides for
such a notification.
The number of links included in the message depends on the number of
failures detected within a window of time by the sending node. A
node MAY choose to send separate failure indication messages in the
interest of completing the recovery for a given link within an
implementation-dependent time constraint.
2.5.2. Switchover Request Message
Under bi-directional 1+1 span protection, this message is used to
coordinate the selecting function at both nodes. This message
originated at the node that detected the failure.
Under dedicated 1:1 and shared M:N span protection, this message is
used as an LSP Switchover Request. This message is sent from the
master node to the slave node (reliably) to indicate that the LSP(s)
on the (failed) working link can be switched to an available
protection link. If so, the ID of the protection link, as well as
the LSP labels (if necessary), MUST be indicated. These identifiers
MUST be consistent with those used in GMPLS signaling.
A working link may carry multiple LSPs. Since the normal traffic
carried over the working link is switched to the protection link, it
MAY be possible for the LSPs on the working link to be mapped to the
protection link without re-signaling each individual LSP. For
example, if link bundling [RFC4201] is used where the working and
protect links are mapped to component links, and the labels are the
same on the working and protection links, it MAY be possible to
change the component links without needing to re-signal each
individual LSP. Optionally, the labels MAY need to be explicitly
coordinated between the two nodes. In this case, the Switchover
Request message SHOULD carry the new label mappings.
The master may not be able to find protection links to accommodate
all failed working links. Thus, if this message is generated in
response to a Failure Indication message from the slave, then the set
of failed links in the message MAY be a sub-set of the links received
in the Failure Indication message. Depending on time constraints,
the master may switch the normal traffic from the set of failed links
in smaller batches. Thus, a single failure indication message MAY
result in the master sending more than one Switchover Request message
to the same slave node.
2.5.3. Switchover Response Message
This message is sent from the slave to the master (reliably) to
indicate the completion (or failure) of switchover at the slave. In
this message, the slave MAY indicate that it cannot switch over to
the corresponding free link for some reason. In this case, the
master and slave notify the user (operator) of the failed switchover.
A notification of the failure MAY also be used as a trigger in an
end-to-end recovery.
2.6. Preventing Unintended Connections
An unintended connection occurs when traffic from the wrong source is
delivered to a receiver. This MUST be prevented during protection
switching. This is primarily a concern when the protection link is
being used to carry Extra Traffic. In this case, it MUST be ensured
that the LSP traffic being switched from the (failed) working link to
the protection link is not delivered to the receiver of the pre-
empted traffic. Thus, in the message flow described above, the
master node MUST disconnect (any) pre-empted traffic on the selected
protection link before sending the Switchover Request. The slave
node MUST also disconnect pre-empted traffic before sending the
Switchover Response. In addition, the master node SHOULD start
receiving traffic for the protected LSP from the protection link.
Finally, the master node SHOULD start sending protected traffic on
the protection link upon receipt of the Switchover Response.
3. End-to-End (Path) Protection and Restoration
End-to-end path protection and restoration refer to the recovery of
an entire LSP from the initiator to the terminator. Suppose the
primary path of an LSP is routed from the initiator (Node A) to the
terminator (Node B) through a set of intermediate nodes.
The following subsections describe three previously proposed end-to-
end protection schemes and the functional steps needed to implement
them.
3.1. Unidirectional 1+1 Protection
A dedicated, resource-disjoint alternate path is pre-established to
protect the LSP. Traffic is simultaneously sent on both paths and
received from one of the functional paths by the end nodes A and B.
There is no explicit signaling involved with this mode of protection.
3.2. Bi-directional 1+1 Protection
A dedicated, resource-disjoint alternate path is pre-established to
protect the LSP. Traffic is simultaneously sent on both paths; under
normal conditions, the traffic from the working path is received by
nodes A and B (in the appropriate directions). A failure affecting
the working path results in both A and B switching to the traffic on
the protection path in the respective directions.
Note that this requires coordination between the end nodes to switch
to the protection path.
The basic steps in bi-directional 1+1 path protection are as follows:
o Failure detection: There are two possibilities for this.
1. A node in the working path detects a failure event. Such
a node MUST send a Failure Indication message toward the
upstream or/and downstream end node of the LSP (node A or
B). This message MAY be forwarded along the working path
or routed over a different path if the network has
general routing intelligence.
Mechanisms provided by the data transport plane MAY also
be used for this, if available.
2. The end nodes (A or B) detect the failure themselves
(e.g., loss of signal).
o Switchover: The action taken when an end node detects a failure
in the working path is as follows: Start receiving from the
protection path; at the same time, send a Switchover Request
message to the other end node to enable switching at the other
end.
The action taken when an end node receives a Switchover Request
message is as follows:
- Start receiving from the protection path; at the same
time, send a Switchover Response message to the other end
node.
GMPLS signaling mechanisms MAY be used to (reliably) signal the
Failure Indication message, as well as the Switchover Request and
Response message. These messages MAY be forwarded along the
protection path if no other routing intelligence is available in the
network.
3.2.1. Identifiers
LSP Identifier: A unique identifier for each LSP. The LSP identifier
is within the scope of the Source ID and Destination ID.
Source ID: ID of the source (e.g., IP address).
Destination ID: ID of the destination (e.g., IP address).
3.2.2. Nodal Information
Each node that is on the working or protection path of an LSP MUST
have knowledge of the LSP identifier. If the network does not
provide routing intelligence, nodal information MAY also include
previous and next nodes in the LSP so that restoration-related
messages can be forwarded properly. When the network provides
general routing intelligence, messages MAY be forwarded along paths
other than that of the LSP.
At the end-point nodes, the working and protection paths MUST be
associated. The association of these paths MAY be either provisioned
using signaling or MAY be configured when LSP provisioning does not
involve signaling (e.g., provisioning through a management system).
The related association information MUST remain until the LSP is
explicitly de-provisioned.
3.2.3. End-to-End Failure Indication Message
This message is sent (reliably) by an intermediate node toward the
source of an LSP. For instance, such a node might have attempted
local span protection and failed. This message MAY not be necessary
if the data transport layer provides mechanisms for the notification
of LSP failure by the endpoints (i.e., if LSP endpoints are co-
located with a corresponding data (transport) maintenance/recovery
domain).
Consider a node that detects a link failure. The node MUST determine
the identities of all LSPs that are affected by the failure of the
link and send an End-to-End Failure Indication message to the source
of each LSP. For scalability reasons, Failure Indication messages
MAY contain the identity and the status of multiple LSPs rather than
a single one. Each intermediate node receiving such a message MUST
forward the message to the appropriate next node such that the
message would ultimately reach the LSP source. However, there is no
requirement that this message flows toward the source along the same
path as the failed LSP. Furthermore, if an intermediate node is
itself generating a Failure Indication message, there SHOULD be a
mechanism to suppress all but one source of Failure Indication
messages. Finally, the Failure Indication message MUST be sent
reliably from the node detecting the failure to the LSP source.
Reliability MAY be achieved, for example, by retransmitting the
message until an acknowledgement is received. However,
retransmission of Failure Indication messages SHOULD not cause
further message drops. This MAY be achieved through the appropriate
configuration and use of congestion and flow control mechanisms.
3.2.4. End-to-End Failure Acknowledgement Message
This message is sent by the source node to acknowledge the receipt of
an End-to-End Failure Indication message. This message is sent to
the originator of the Failure Indication message. The Acknowledge
message SHOULD be sent for each Failure Indication Message received.
Each intermediate node receiving the Failure Acknowledgement message
MUST forward it toward the destination of the message. However,
there is no requirement that this message flows toward the
destination along the same path as the failed LSP.
This message MAY not be required if other means of ensuring reliable
message delivery are used.
3.2.5. End-to-End Switchover Request Message
This message is generated by the source node receiving an indication
of failure in an LSP. It is sent to the LSP destination, and it
carries the identifier of the LSP being restored. The End-to-End
Switchover Request message MUST be sent reliably from the source to
the destination of the LSP.
3.2.6. End-to-End Switchover Response Message
This message is sent by the destination node receiving an End-to-End
Switchover Request message toward the source of the LSP. This
message SHOULD identify the LSP being switched over. This message
MUST be transmitted in response to each End-to-End Switchover Request
message received and MAY indicate either a positive or negative
outcome.
3.3. Shared Mesh Restoration
Shared mesh restoration refers to schemes under which protection
paths for multiple LSPs share common link and node resources. Under
these schemes, the protection capacity is pre-reserved, i.e., link
capacity is allocated to protect one or more LSPs, but explicit
action is required to instantiate a specific protection LSP. This
requires restoration signaling along the protection path. Typically,
the protection capacity is shared only amongst LSPs whose working
paths are physically diverse. This criterion can be enforced when
provisioning the protection path. Specifically, provisioning-related
signaling messages may carry information about the working path to
nodes along the protection path. This can be used as call admission
control to accept/reject connections along the protection path based
on the identification of the resources used for the primary path.
Thus, shared mesh restoration is designed to protect an LSP after a
single failure event, i.e., a failure that affects the working path
of at most one LSP sharing the protection capacity. It is possible
that a protection path may not be successfully activated when
multiple, concurrent failure events occur. In this case, shared mesh
restoration capacity may be claimed for more than one failed LSP and
the protection path can be activated only for one of them (at most).
For implementing shared mesh restoration, the identifier and nodal
information related to signaling along the control path are as
defined for 1+1 protection in Sections 3.2.1 and 3.2.2. In addition,
each node MUST also keep (local) information needed to establish the
data plane of the protection path. This information MUST indicate
the local resources to be allocated, the fabric cross-connect to be
established to activate the path, etc. The precise nature of this
information would depend on the type of node and LSP (the GMPLS
signaling document describes different type of switches [RFC3471]).
It would also depend on whether the information is fine or coarse-
grained. For example, fine-grained information would indicate pre-
selection of all details pertaining to protection path activation,
such as outgoing link, labels, etc. Coarse-grained information, on
the other hand, would allow some details to be determined during
protection path activation. For example, protection resources may be
pre-selected at the level of a TE link, while the selection of the
specific component link and label occurs during protection path
activation.
While the coarser specification allows some flexibility in the
selection of the precise resource to activate, it also adds
complexity in decision making and signaling during the time-critical
restoration phase. Furthermore, the procedures for the assignment of
bandwidth to protection paths MUST take into account the total
resources in a TE link so that single-failure survivability
requirements are satisfied.
3.3.1. End-to-End Failure Indication and Acknowledgement Message
The End-to-End failure indication and acknowledgement procedures and
messages are as defined in Sections 3.2.3 and 3.2.4.
3.3.2. End-to-End Switchover Request Message
This message is generated by the source node receiving an indication
of failure in an LSP. It is sent to the LSP destination along the
protection path, and it identifies the LSP being restored. If any
intermediate node is unable to establish cross-connects for the
protection path, then it is desirable that no other node in the path
establishes cross-connects for the path. This would allow shared
mesh restoration paths to be efficiently utilized.
The End-to-End Switchover message MUST be sent reliably from the
source to the destination of the LSP along the protection path.
3.3.3. End-to-End Switchover Response Message
This message is sent by the destination node receiving an End-to-End
Switchover Request message toward the source of the LSP, along the
protection path. This message SHOULD identify the LSP that is being
switched over. Prior to activating the secondary bandwidth at each
hop along the path, Extra Traffic (if used) MUST be dropped and not
forwarded.
This message MUST be transmitted in response to each End-to-End
Switchover Request message received.
4. Reversion and Other Administrative Procedures
Reversion refers to the process of moving an LSP back to the original
working path after a failure is cleared and the path is repaired.
Reversion applies both to local span and end-to-end path-protected
LSPs. Reversion is desired for the following reasons. First, the
protection path may not be optimal in comparison to the working path
from a routing and resource consumption point of view. Second,
moving an LSP to its working path allows the protection resources to
be used to protect other LSPs. Reversion has the disadvantage of
causing a second service disruption. Use of reversion is at the
option of the operator. Reversion implies that a working path
remains allocated to the LSP that was originally routed over it, even
after a failure. It is important to have mechanisms that allow
reversion to be performed with minimal service disruption to the
customer. This can be achieved using a "bridge-and-switch" approach
(often referred to as make-before-break).
The basic steps involved in bridge-and-switch are as follows:
1. The source node commences the process by "bridging" the normal
traffic onto both the working and the protection paths (or
links in the case of span protection).
2. Once the bridging process is complete, the source node sends a
Bridge and Switch Request message to the destination,
identifying the LSP and other information necessary to perform
reversion. Upon receipt of this message, the destination
selects the traffic from the working path. At the same time,
it bridges the transmitted traffic onto both the working and
protection paths.
3. The destination then sends a Bridge and Switch Response message
to the source confirming the completion of the operation.
4. When the source receives this message, it switches to receive
from the working path, and stops transmitting traffic on the
protection path. The source then sends a Bridge and Switch
Completed message to the destination confirming that the LSP
has been reverted.
5. Upon receipt of this message, the destination stops
transmitting along the protection path and de-activates the LSP
along this path. The de-activation procedure should remove the
crossed connections along the protection path (and frees the
resources to be used for restoring other failures).
Administrative procedures other than reversion include the ability to
force a switchover (from working to protection or vice versa) and
locking out switchover, i.e., preventing an LSP from moving from
working to protection administratively. These administrative
conditions have to be supported by signaling.
5. Discussion
5.1. LSP Priorities During Protection
Under span protection, a failure event could affect more than one
working link and there could be fewer protection links than the
number of failed working links. Furthermore, a working link may
contain multiple LSPs of varying priority. Under this scenario, a
decision must be made as to which working links (and therefore LSPs)
should be protected. This decision MAY be based on LSP priorities.
In general, a node might detect failures sequentially, i.e., all
failed working links may not be detected simultaneously, but only
sequentially. In this case, as per the proposed signaling
procedures, LSPs on a working link MAY be switched over to a given
protection link, but another failure (of a working link carrying
higher priority LSPs) may be detected soon afterward. In this case,
the new LSPs may bump the ones previously switched over the
protection link.
In the case of end-to-end shared mesh restoration, priorities MAY be
implemented for allocating shared link resources under multiple
failure scenarios. As described in Section 3.3, more than one LSP
can claim shared resources under multiple failure scenarios. If such
resources are first allocated to a lower-priority LSP, they MAY have
to be reclaimed and allocated to a higher-priority LSP.
6. Security Considerations
There are a number of security threats that MAY be experienced due to
the exchange of messages and information, as detailed in this
document. Some examples include interception, spoofing,
modification, and replay of control messages. Therefore, the
following security requirements are applicable to the mechanisms of
this document.
o Signaling MUST be able to provide authentication, integrity,
and protection against replay attacks.
o Privacy and confidentiality are not required. Only
authentication is required to ensure that the signaling
messages are originating from the right place and have not been
modified in transit.
o Protection of the identity of the data plane end-points (in
Failure Indication messages) is not required
The consequences of poorly secured protection may increase the risk
of triggering recovery actions under false Failure Indication
messages, including LSP identifiers that are not under failure. Such
information could subsequently trigger the initiation of "false"
recovery actions while there are no reasons to do so. Additionally,
if the identification of the LSP is tampered with from a Failure
Indication message, recovery actions will involve nodes for which the
LSPs do not indicate any failure condition or for which no Failure
Indication message has been received. The consequences of such
actions is unpredictable and MAY lead to de-synchronisation between
the control and the data plane, as well as increase the risk of
misconnections. Moreover, the consequences of poorly applied
protection may increase the risk of misconnection. In particular,
when Extra Traffic is involved, it is easily possible to deliver the
wrong traffic to the wrong destination. Similarly, an intrusion that
sets up what appears to be a valid protection LSP and then causes a
fault may be able to divert traffic.
Moreover, tampering with a routing information exchange may also have
an effect on traffic engineering. Therefore, any mechanisms used for
securing and authenticating the transmission of routing information
SHOULD be applied in the present context.
7. Contributors
This document was the product of many individuals working together in
the CCAMP WG Protection and Restoration design team. The following
are the authors that contributed to this document:
Deborah Brungard (AT&T)
200 S. Laurel Ave.
Middletown, NJ 07748, USA
EMail: dbrungard@att.com
Sudheer Dharanikota
EMail: sudheer@ieee.org
Jonathan P. Lang (Sonos)
223 East De La Guerra Street
Santa Barbara, CA 93101, USA
EMail: jplang@ieee.org