draft-ietf-mpls-tp-linear-protection-06.txt   draft-ietf-mpls-tp-linear-protection-07.txt 
Network Working Group S. Bryant, Ed. Network Working Group S. Bryant
Internet-Draft E. Osborne Internet-Draft E. Osborne
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: September 14, 2011 N. Sprecher, Ed. Expires: December 4, 2011 N. Sprecher
Nokia Siemens Networks Nokia Siemens Networks
A. Fulignoli, Ed. A. Fulignoli, Ed.
Ericsson Ericsson
Y. Weingarten Y. Weingarten, Ed.
Nokia Siemens Networks Nokia Siemens Networks
March 13, 2011 June 2, 2011
MPLS-TP Linear Protection MPLS-TP Linear Protection
draft-ietf-mpls-tp-linear-protection-06.txt draft-ietf-mpls-tp-linear-protection-07.txt
Abstract Abstract
The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is
being specified jointly by IETF and ITU-T. This document addresses being specified jointly by IETF and ITU-T. This document addresses
the functionality described in the MPLS-TP Survivability Framework the functionality described in the MPLS-TP Survivability Framework
document [SurvivFwk] and defines a protocol that may be used to document [SurvivFwk] and defines a protocol that may be used to
fulfill the function of the Protection State Coordination for linear fulfill the function of the Protection State Coordination for linear
protection, as described in that document. protection, as described in that document.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2011. This Internet-Draft will expire on December 4, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 21 skipping to change at page 3, line 21
2. Conventions used in this document . . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 6
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Definitions and Terminology . . . . . . . . . . . . . . . 7 2.2. Definitions and Terminology . . . . . . . . . . . . . . . 7
3. Protection switching control logic . . . . . . . . . . . . . . 7 3. Protection switching control logic . . . . . . . . . . . . . . 7
3.1. Local Request Logic . . . . . . . . . . . . . . . . . . . 8 3.1. Local Request Logic . . . . . . . . . . . . . . . . . . . 8
3.2. Remote Requests . . . . . . . . . . . . . . . . . . . . . 10 3.2. Remote Requests . . . . . . . . . . . . . . . . . . . . . 10
3.3. PSC Control Logic . . . . . . . . . . . . . . . . . . . . 11 3.3. PSC Control Logic . . . . . . . . . . . . . . . . . . . . 11
3.4. PSC Message Generator . . . . . . . . . . . . . . . . . . 12 3.4. PSC Message Generator . . . . . . . . . . . . . . . . . . 12
3.5. Wait-to-Restore (WTR) timer . . . . . . . . . . . . . . . 12 3.5. Wait-to-Restore (WTR) timer . . . . . . . . . . . . . . . 12
3.6. PSC Control States . . . . . . . . . . . . . . . . . . . . 12 3.6. PSC Control States . . . . . . . . . . . . . . . . . . . . 12
3.6.1. Local and Remote state . . . . . . . . . . . . . . . . 13 3.6.1. Local and Remote state . . . . . . . . . . . . . . . . 14
4. Protection state coordination (PSC) protocol . . . . . . . . . 14 4. Protection state coordination (PSC) protocol . . . . . . . . . 14
4.1. Transmission and acceptance of PSC control packets . . . . 15 4.1. Transmission and acceptance of PSC control packets . . . . 15
4.2. Protocol format . . . . . . . . . . . . . . . . . . . . . 15 4.2. Protocol format . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. PSC Ver field . . . . . . . . . . . . . . . . . . . . 16 4.2.1. PSC Ver field . . . . . . . . . . . . . . . . . . . . 16
4.2.2. PSC Request field . . . . . . . . . . . . . . . . . . 16 4.2.2. PSC Request field . . . . . . . . . . . . . . . . . . 16
4.2.3. Protection Type (PT) . . . . . . . . . . . . . . . . . 17 4.2.3. Protection Type (PT) . . . . . . . . . . . . . . . . . 17
4.2.4. Revertive (R) field . . . . . . . . . . . . . . . . . 18 4.2.4. Revertive (R) field . . . . . . . . . . . . . . . . . 18
4.2.5. Fault path (FPath) field . . . . . . . . . . . . . . . 18 4.2.5. Fault path (FPath) field . . . . . . . . . . . . . . . 18
4.2.6. Data path (Path) field . . . . . . . . . . . . . . . . 18 4.2.6. Data path (Path) field . . . . . . . . . . . . . . . . 18
4.2.7. Additional TLV information . . . . . . . . . . . . . . 19
4.3. Principles of Operation . . . . . . . . . . . . . . . . . 19 4.3. Principles of Operation . . . . . . . . . . . . . . . . . 19
4.3.1. Basic operation . . . . . . . . . . . . . . . . . . . 19 4.3.1. Basic operation . . . . . . . . . . . . . . . . . . . 19
4.3.2. Priority of inputs . . . . . . . . . . . . . . . . . . 20 4.3.2. Priority of inputs . . . . . . . . . . . . . . . . . . 20
4.3.3. Operation of PSC States . . . . . . . . . . . . . . . 21 4.3.3. Operation of PSC States . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 5.1. Pseudowire Associated Channel Type . . . . . . . . . . . . 32
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 5.2. PSC Request Field . . . . . . . . . . . . . . . . . . . . 32
Appendix A. PSC state machine tables . . . . . . . . . . . . . . 31 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . . 36 8.1. Normative References . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 8.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. PSC state machine tables . . . . . . . . . . . . . . 35
Appendix B. Exercising the protection domain . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
The MPLS Transport Profile (MPLS-TP) [TPFwk] is a framework for the The MPLS Transport Profile (MPLS-TP) [TPFwk] is a framework for the
construction and operation of packet-switched transport networks construction and operation of packet-switched transport networks
based on the architectures for MPLS ([RFC3031] and [RFC3032]) and for based on the architectures for MPLS ([RFC3031] and [RFC3032]) and for
Pseudowires (PWs) ([RFC3985] and [RFC5659]) and the requirements of Pseudowires (PWs) ([RFC3985] and [RFC5659]) and the requirements of
[RFC5654]. [RFC5654].
Network survivability is the ability of a network to recover traffic Network survivability is the ability of a network to recover traffic
skipping to change at page 4, line 43 skipping to change at page 4, line 43
the protection path is reserved for a selected working path or set of the protection path is reserved for a selected working path or set of
working paths. It provides a fast and simple survivability working paths. It provides a fast and simple survivability
mechanism, that allows the network operator to easily grasp the mechanism, that allows the network operator to easily grasp the
active state of the network, compared to other survivability active state of the network, compared to other survivability
mechanisms. mechanisms.
As specified in the Survivability Framework document [SurvivFwk], As specified in the Survivability Framework document [SurvivFwk],
protection switching is applied to a protection domain. For the protection switching is applied to a protection domain. For the
purposes of this document, we define the protection domain of a P2P purposes of this document, we define the protection domain of a P2P
LSP as consisting of two Label Edge Routers (LER) and the transport LSP as consisting of two Label Edge Routers (LER) and the transport
paths that connect them. For a P2MP LSP the protection domain paths that connect them (see Figure 3 below). For a P2MP LSP the
includes the root (or source) LER, the destination (or sink) LERs, protection domain includes the root (or source) LER, the destination
and the transport paths that connect them. (or sink) LERs, and the transport paths that connect them.
In 1+1 unidirectional architecture as presented in [SurvivFwk], a In 1+1 unidirectional architecture as presented in [SurvivFwk], a
protection transport path is dedicated to the working transport path. protection transport path is dedicated to the working transport path.
Normal traffic is bridged (as defined in [RFC4427])and fed to both Normal traffic is bridged (as defined in [RFC4427])and fed to both
the working and the protection paths by a permanent bridge at the the working and the protection paths by a permanent bridge at the
source of the protection domain. The sink of the protection domain source of the protection domain. The sink of the protection domain
selects which of the working or protection paths to receive the uses a selector to select either the working or protection paths to
traffic from, based on a predetermined criteria, e.g. server defect receive the traffic from, based on a predetermined criteria, e.g.
indication. When used for bidirectional switching the 1+1 protection server defect indication. When used for bidirectional switching the
architecture must also support a Protection State Coordination (PSC) 1+1 protection architecture must also support a Protection State
protocol. This protocol is used to help coordinate between both ends Coordination (PSC) protocol. This protocol is used to help
of the protection domain in selecting the proper traffic flow. coordinate between both ends of the protection domain in selecting
the proper traffic flow.
In the 1:1 architecture, a protection transport path is dedicated to In the 1:1 architecture, a protection transport path is dedicated to
the working transport path of a single service and the traffic is the working transport path of a single service and the traffic is
only transmitted either on the working or the protection path, by only transmitted either on the working or the protection path, by
using a selector bridge at the source of the protection domain. A using a selector at the source of the protection domain. A selector
selector at the sink of the protection domain then selects the path at the sink of the protection domain then selects the path that
that carries the normal traffic. Since the source and sink need to carries the normal traffic. Since the source and sink need to be
be coordinated to ensure that the selector bridge at both ends select coordinated to ensure that the selector at both ends select the same
the same path, this architecture must support a PSC protocol. path, this architecture must support a PSC protocol.
The 1:n protection architecture extends the 1:1 architecture above by The 1:n protection architecture extends the 1:1 architecture above by
sharing the protection path among n services. Again, the protection sharing the protection path among n services. Again, the protection
path is fully allocated and disjoint from any of the n working path is fully allocated and disjoint from any of the n working
transport paths that it is being used to protect. The normal data transport paths that it is being used to protect. The normal data
traffic for each service is transmitted either on the normal working traffic for each service is transmitted either on the normal working
path for that service or, in cases that trigger protection switching path for that service or, in cases that trigger protection switching
(as defined in [SurvivFwk]), may be sent on the protection path. The (as defined in [SurvivFwk]), may be sent on the protection path. The
switching action is similar to the 1:1 case where a selector bridge switching action is similar to the 1:1 case where a selector is used
is used at the source. It should be noted that in cases where at the source. It should be noted that in cases where multiple
multiple working path services have triggered protection switching working path services have triggered protection switching that some
that some services, dependent upon their Service Level Agreement services, dependent upon their Service Level Agreement (SLA), may not
(SLA), may not be transmitted as a result of limited resources on the be transmitted as a result of limited resources on the protection
protection path. In this architecture there may be a need for path. In this architecture there may be a need for coordination of
coordination of the protection switching, and also for resource the protection switching, and also for resource allocation
allocation negotiation. The procedures for this are for further negotiation. The procedures for this are for further study and may
study and may be addressed in future documents. be addressed in future documents.
1.2. Scope of the document 1.2. Scope of the document
As was pointed out in the Survivability Framework [SurvivFwk] and As was pointed out in the Survivability Framework [SurvivFwk] and
highlighted above, there is a need for coordination between the end highlighted above, there is a need for coordination between the end
points of the protection domain when employing bidirectional points of the protection domain when employing bidirectional
protection schemes. This is especially true when there is a need to protection schemes. This is especially true when there is a need to
maintain traffic over a co-routed bidirectional LSP. maintain traffic over a co-routed bidirectional LSP.
The scope of this draft is to present a protocol for the Protection The scope of this draft is to present a protocol for the Protection
skipping to change at page 7, line 11 skipping to change at page 7, line 11
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.1. Acronyms 2.1. Acronyms
This draft uses the following acronyms: This draft uses the following acronyms:
DNR Do not revert DNR Do not revert
FS Forced Switch FS Forced Switch
G-ACh Generic Associated Channel Header G-ACh Generic Associated Channel
LER Label Edge Router LER Label Edge Router
LO Lockout of protection LO Lockout of protection
MPLS-TP Transport Profile for MPLS MPLS-TP Transport Profile for MPLS
MS Manual Switch MS Manual Switch
NR No Request NR No Request
P2P Point-to-point P2P Point-to-point
P2MP Point-to-multipoint P2MP Point-to-multipoint
PSC Protection State Coordination Protocol PSC Protection State Coordination Protocol
SD Signal Degrade SD Signal Degrade
SF Signal Fail SF Signal Fail
skipping to change at page 7, line 37 skipping to change at page 7, line 37
The terminology used in this document is based on the terminology The terminology used in this document is based on the terminology
defined in [RFC4427] and further adapted for MPLS-TP in [SurvivFwk]. defined in [RFC4427] and further adapted for MPLS-TP in [SurvivFwk].
In addition, we use the term LER to refer to a MPLS-TP Network In addition, we use the term LER to refer to a MPLS-TP Network
Element, whether it is a LSR, LER, T-PE, or S-PE. Element, whether it is a LSR, LER, T-PE, or S-PE.
3. Protection switching control logic 3. Protection switching control logic
Protection switching processes the local triggers described in Protection switching processes the local triggers described in
requirements 74-79 of [RFC5654] together with inputs received from requirements 74-79 of [RFC5654] together with inputs received from
the far-end LER. Based on these inputs the LER will take certain the far-end LER. Based on these inputs the LER will take certain
protection switching actions, e.g. switching the Selector Bridge to protection switching actions, e.g. switching the selector to transmit
select the working or protection path, and transmit different on the working or protection path for 1:1 protection or switching the
protocol messages. selector to receive the traffic for either 1:1 or 1+1 protection, and
transmit different protocol messages.
The following figure shows the logical decomposition of the The following figure shows the logical decomposition of the
Protection Switching Control Logic into different logical processing Protection Switching Control Logic into different logical processing
units. These processing units are presented in subsequent units. These processing units are presented in subsequent
subsections of this document. This logical decomposition is only subsections of this document. This logical decomposition is only
intended for descriptive purposes, any implementation that produces intended for descriptive purposes, any implementation that produces
the external behavior described in section 4 is acceptable. the external behavior described in section 4 is acceptable.
Server Indication Control Plane Indication Server Indication Control Plane Indication
-----------------+ +------------- -----------------+ +-------------
skipping to change at page 9, line 5 skipping to change at page 9, line 5
end LER, and the current status of the protection domain. end LER, and the current status of the protection domain.
3.1. Local Request Logic 3.1. Local Request Logic
The Local Request logic processes input triggers from five sources: The Local Request logic processes input triggers from five sources:
o Operator command - the network operator may issue local o Operator command - the network operator may issue local
administrative commands on the LER that trigger protection administrative commands on the LER that trigger protection
switching. The supported commands are Forced Switch, Manual switching. The supported commands are Forced Switch, Manual
Switch, Clear, Lockout of Protection, (see definitions in Switch, Clear, Lockout of Protection, (see definitions in
[RFC4427]). [RFC4427]). An implementation MAY provide additional commands for
operator use; providing that these commands do not introduce
incompatable behavior between two arbitrary implementations, they
are outside the scope of this document. For example, an
implementation could provide a command to manually trigger a "WTR
expires" trigger (see below) input without waiting for the
duration of the WTR timer; as this merely hastens the transition
from one state to another and has no impact on the state machine
itself, it would be perfectly valid.
o Server layer alarm indication - the underlying server layer of the o Server layer alarm indication - the underlying server layer of the
network detects failure conditions at the underlying layer and may network detects failure conditions at the underlying layer and may
issue an indication to the MPLS-TP layer. The server layer may issue an indication to the MPLS-TP layer. The server layer may
employ its own protection switching mechanism, and therefore this employ its own protection switching mechanism, and therefore this
input MAY be controlled by a holdoff-timer that SHOULD be input MAY be controlled by a holdoff-timer that SHOULD be
configurable by the network operator. configurable by the network operator. The holdoff-timer is
described in greater detail in [SurvivFwk].
o Control plane - if there is a control plane active in the network o Control plane - if there is a control plane active in the network
(either signaling or routing), it MAY trigger protection switching (either signaling or routing), it MAY trigger protection switching
based on conditions detected by the control plane. If the control based on conditions detected by the control plane. If the control
plane is based on GMPLS [RFC3945] then the recovery process SHALL plane is based on GMPLS [RFC3945] then the recovery process SHALL
comply with the process described in [RFC4872]. comply with the process described in [RFC4872].
o OAM indication - OAM fault management or performance measurement o OAM indication - OAM fault management or performance measurement
tools may detect a failure or degrade condition on either the tools may detect a failure or degrade condition on either the
working or protection transport path and this SHOULD input an working or protection transport path and this SHOULD input an
skipping to change at page 12, line 9 skipping to change at page 12, line 17
The new state information SHALL be retained by the PSC Control Logic, The new state information SHALL be retained by the PSC Control Logic,
while the requested action should be sent to the PSC Message while the requested action should be sent to the PSC Message
Generator (see subsection 3.4) to generate and transmit the proper Generator (see subsection 3.4) to generate and transmit the proper
PSC message to be transmitted to the remote end point of the PSC message to be transmitted to the remote end point of the
protection domain. protection domain.
3.4. PSC Message Generator 3.4. PSC Message Generator
Based on the action output from the PSC Control Logic this unit Based on the action output from the PSC Control Logic this unit
formats the PSC protocol message that is transmitted to the remote formats the PSC protocol message that is transmitted to the remote
end point of the protection domain. When the PSC control state (see end point of the protection domain. This message may either be the
section 3.6) has changed, three PSC messages SHOULD be transmitted in same as the previously transmitted message or change when the PSC
quick succession, and subsequent messages should be transmitted control state (see section 3.6) has changed. The messages should be
continually at a lower frequency. transmitted as described in section 4.1 of this document.
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.
3.5. Wait-to-Restore (WTR) timer 3.5. Wait-to-Restore (WTR) timer
The WTR timer is used to delay reversion to Normal state when The WTR timer is used to delay reversion to Normal state when
recovering from a failure condition on the working path and the recovering from a failure condition on the working path and the
protection domain is configured for revertive behavior. The length protection domain is configured for revertive behavior. The length
of the timer may be provisioned by the operator. The WTR may be in of the timer may be provisioned by the operator. The WTR may be in
one of two states - either Running or Stopped. The control of the one of two states - either Running or Stopped. The control of the
WTR timer is managed by the PSC Control Logic, by use of internal WTR timer is managed by the PSC Control Logic, by use of internal
signals to start and stop, i.e. reset, the WTR timer. signals to start and stop, i.e. reset, the WTR timer.
skipping to change at page 15, line 19 skipping to change at page 15, line 21
the normal data traffic in the most prevalent case, i.e. the Normal the normal data traffic in the most prevalent case, i.e. the Normal
state. In addition, limiting the transmission to a single path state. In addition, limiting the transmission to a single path
avoids possible conflicts and race conditions that could develop if avoids possible conflicts and race conditions that could develop if
the PSC messages were sent on both paths. the PSC messages were sent on both paths.
When the protection domain state is changed due to a local input, When the protection domain state is changed due to a local input,
three PSC messages SHOULD be transmitted as quickly as possible, to three PSC messages SHOULD be transmitted as quickly as possible, to
allow for rapid protection switching. This set of three rapid allow for rapid protection switching. This set of three rapid
messages allows for fast protection switching even if one or two of messages allows for fast protection switching even if one or two of
these packets are lost or corrupted. When the protection domain these packets are lost or corrupted. When the protection domain
state changes due to a remote message there is no need for the state changes due to a remote message the LER MAY send the three
aforementioned rapid transmission of three messages. The exception rapid messages, but is not required to. However, when the LER
(e.g. when the rapid transmission is still required) is when going tranfers from WTR state to Normal state as a result of a remote NR
from WTR state to Normal state as a result of a remote NR message. message, the three rapid messages SHOULD be transmitted.
The frequency of the three rapid messages and the separate frequency The frequency of the three rapid messages and the separate frequency
of the continual transmission SHOULD be configurable by the operator. of the continual transmission SHOULD be configurable by the operator.
For protection switching within 50ms, it is RECOMMENDED that the For protection switching within 50ms, it is RECOMMENDED that the
default interval of the first three PSC messages SHOULD be no larger default interval of the first three PSC messages SHOULD be no larger
than 3.3ms. The subsequent messages SHOULD be continuously than 3.3ms. The subsequent messages SHOULD be continuously
transmitted with an interval of 5 seconds. transmitted with an interval of 5 seconds.
If no valid PSC message is received, the last valid received message If no valid PSC message is received, the last valid received message
remains applicable. remains applicable.
4.2. Protocol format 4.2. Protocol format
The protocol messages SHALL be sent over the G-ACh as described in The protocol messages SHALL be sent over the G-ACh as described in
[RFC5586]. There is a single channel type for the set of PSC [RFC5586]. There is a single channel type for the set of PSC
messages [to be assigned by IANA]. The actual message function SHALL messages. The actual message function SHALL be identified by the
be identified by the Request field of the ACH payload as described Request field of the ACH payload as described below.
below. The following figure shows the format for the complete PSC
message:. The channel type for the PSC messages SHALL be PSC-CT=0xHH (to be
assigned by IANA)
The following figure shows the format for the complete PSC message:
0 1 2 3 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 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 | |0 0 0 1|Version| Reserved | PSC-CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header | |Ver|Request|PT |R| Reserved | FPath | Path |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~ | TLV Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|Request|PT |R| Reserved | FPath | Path | ~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of PSC packet with a G-ACh header Figure 2: Format of PSC packet with a G-ACh header
Where: Where:
o MPLS-TP PSC Channel Code is the G-ACh channel number assigned to
the PSC = TBD
o The ACH TLV Header is described in [RFC5586]
o The following subsections describe the fields of the PSC payload. o The following subsections describe the fields of the PSC payload.
4.2.1. PSC Ver field 4.2.1. PSC Ver field
The Ver field identifies the version of the protocol. For this The Ver field identifies the version of the protocol. For this
version the value SHALL be 0. version of the document the value SHALL be 1.
4.2.2. PSC Request field 4.2.2. PSC Request field
The PSC protocol SHALL support transmission of the following requests The PSC protocol SHALL support transmission of the following requests
between the two end points of the protection domain: between the two end points of the protection domain:
o (1110) Lockout of protection - indicates that the end point has o (1110) Lockout of protection - indicates that the end point has
disabled the protection path as a result of an administrative disabled the protection path as a result of an administrative
command. Both the FPath and Path fields SHALL be set to 0. command. Both the FPath and Path fields SHALL be set to 0.
o (1101) Forced switch - indicates that the transmitting end point o (1100) Forced switch - indicates that the transmitting end point
has switched traffic to the protection path as a result of an has switched traffic to the protection path as a result of an
administrative command. The Fpath field SHALL indicate that the administrative command. The Fpath field SHALL indicate that the
working path is being blocked (i.e. Fpath set to 1), and the Path working path is being blocked (i.e. Fpath set to 1), and the Path
field SHALL indicate that user data traffic is being transported field SHALL indicate that user data traffic is being transported
on the protection path (i.e. Path set to 1). on the protection path (i.e. Path set to 1).
o (0110) Signal Fail - indicates that the transmitting end point has o (1010) Signal Fail - indicates that the transmitting end point has
identified a signal fail condition on either the working or identified a signal fail condition on either the working or
protection path. The Fpath field SHALL identify the path that is protection path. The Fpath field SHALL identify the path that is
reporting the failure condition (i.e. if protection path then reporting the failure condition (i.e. if protection path then
Fpath is set to 0 and if working path then Fpath is set to 1), and Fpath is set to 0 and if working path then Fpath is set to 1), and
the Path field SHALL indicate where the data traffic is being the Path field SHALL indicate where the data traffic is being
transported (i.e. if protection path is blocked then Path is set transported (i.e. if protection path is blocked then Path is set
to 0 and if working path is blocked then Path is set to 1). to 0 and if working path is blocked then Path is set to 1).
o (0101) Signal Degrade - indicates that that the transmitting end o (0111) Signal Degrade - indicates that that the transmitting end
point has identified a degradation of the signal, or integrity of point has identified a degradation of the signal, or integrity of
the packet transmission on either the working or protection path. the packet transmission on either the working or protection path.
This request is presented here only as a place-holder. The This request is presented here only as a place-holder. The
specifics for the method of identifying this degradation is out- specifics for the method of identifying this degradation is out-
of-scope for this document. The details of the actions to be of-scope for this document. The details of the actions to be
taken for this situation is left for future specification. taken for this situation is left for future specification.
o (0100) Manual switch - indicates that the transmitting end point o (0101) Manual switch - indicates that the transmitting end point
has switched traffic to the protection path as a result of an has switched traffic to the protection path as a result of an
administrative Manual Switch command. The Fpath field SHALL administrative Manual Switch command. The Fpath field SHALL
indicate that the working path is being blocked (i.e. Fpath set indicate that the working path is being blocked (i.e. Fpath set
to 1), and the Path field SHALL indicate that user data traffic is to 1), and the Path field SHALL indicate that user data traffic is
being transported on the protection path (i.e. Path set to 1). being transported on the protection path (i.e. Path set to 1).
o (0011) Wait to restore - indicates that the transmitting end point o (0100) Wait to restore - indicates that the transmitting end point
is recovering from a failure condition of the working path and has is recovering from a failure condition of the working path and has
started the Wait-to-Restore timer. Fpath SHALL be set to 0 and started the Wait-to-Restore timer. Fpath SHALL be set to 0 and
ignored upon receipt. Path SHALL indicate the working path that ignored upon receipt. Path SHALL indicate the working path that
is currently being protected (i.e. Path set to 1). is currently being protected (i.e. Path set to 1).
o (0010) Do not revert - indicates that the transmitting end point o (0001) Do not revert - indicates that the transmitting end point
is recovering from a failure/blocked condition, but due to the is recovering from a failure/blocked condition, but due to the
local settings is requesting that the protection domain continues local settings is requesting that the protection domain continues
to transmit data over the protection path, rather than revert to to transmit data over the protection path, rather than revert to
the Normal state. Fpath SHALL be set to 0 and ignored upon the Normal state. Fpath SHALL be set to 0 and ignored upon
receipt. Path SHALL indicate the working path that is currently receipt. Path SHALL indicate the working path that is currently
being protected (i.e. Path set to 1). being protected (i.e. Path set to 1).
o (0000) No request - indicates that the transmitting end point has o (0000) No request - indicates that the transmitting end point has
nothing to report, Fpath and Path fields SHALL be set to according nothing to report, Fpath and Path fields SHALL be set to according
to the state of the end point, see section 4.3.3 for detailed to the state of the end point, see section 4.3.3 for detailed
skipping to change at page 19, line 14 skipping to change at page 19, line 7
o 0: indicates that the protection path is not transporting user o 0: indicates that the protection path is not transporting user
data traffic (in 1:n architecture) or transporting redundant user data traffic (in 1:n architecture) or transporting redundant user
data traffic (in 1+1 architecture). data traffic (in 1+1 architecture).
o 1: indicates that the protection path is transmitting user traffic o 1: indicates that the protection path is transmitting user traffic
replacing the use of the working path. replacing the use of the working path.
o 2-255: for future extensions o 2-255: for future extensions
4.2.7. Additional TLV information
It may be necessary for future applications of the protocol to
include additional information for the proper processing of the
requests. For this purpose, we provide for optional additional
information to be included in the PSC payload. This information MUST
include a header that indicates the total length (in bytes) of the
additional information.
This information includes the following fields:
o TLV Length -- indicates the number of bytes included in the
optional TLV information. For the basic PSC protocol operation
described in this document this value SHOULD be 0.
o Reserved -- this field SHALL be 0.
o Optional TLVs -- this includes any additional information
formatted as TLV units. There are no TLV units defined for the
basic PSC operation.
4.3. Principles of Operation 4.3. Principles of Operation
In all of the following subsections, assume a protection domain In all of the following subsections, assume a protection domain
between LER-A and LER-Z, using paths W (working) and P (protection) between LER-A and LER-Z, using paths W (working) and P (protection)
as shown in figure 3. as shown in figure 3.
+-----+ //=======================\\ +-----+ +-----+ //=======================\\ +-----+
|LER-A|// Working Path \\|LER-Z| |LER-A|// Working Path \\|LER-Z|
| /| |\ | | /| |\ |
| ?< | | >? | | ?< | | >? |
skipping to change at page 21, line 32 skipping to change at page 21, line 46
possible input - either the highest priority local input or the PSC possible input - either the highest priority local input or the PSC
message from the remote LER. It should be noted that the new state message from the remote LER. It should be noted that the new state
of the protection domain is described from the point of view of the of the protection domain is described from the point of view of the
LER that is reporting the state, therefore, the language of "the LER LER that is reporting the state, therefore, the language of "the LER
goes into a state" is referring to the LER reporting that the goes into a state" is referring to the LER reporting that the
protection domain is now in this new state. If the definition states protection domain is now in this new state. If the definition states
to "ignore" the message, the intention is that the protection domain to "ignore" the message, the intention is that the protection domain
should remain in its current state and the LER should continue should remain in its current state and the LER should continue
transmitting (as presented in section 4.1) the current PSC message. transmitting (as presented in section 4.1) the current PSC message.
When a LER is in a remote state, i.e. state transition in reaction to
a PSC message recieved from the far-end LER, and receives a new PSC
message from the far-end LER that indicates a contradictory state,
e.g. in remote Unavailable state receiving a remote FS(1,1) message,
then the PSC Control Logic should reevaluate all inputs (both the
local input and the remote message) as if the LER is in the Normal
state.
4.3.3.1. Normal State 4.3.3.1. Normal State
When the protection domain has no special condition in effect, the When the protection domain has no special condition in effect, the
ingress LER SHALL forward the user data along the working path, and, ingress LER SHALL forward the user data along the working path, and,
in the case of 1+1 protection, the Permanent Bridge will bridge the in the case of 1+1 protection, the Permanent Bridge will bridge the
data to the protection path as well. The receiving LER SHALL read data to the protection path as well. The receiving LER SHALL read
the data from the working path. the data from the working path.
When the protection domain is in Normal State the end-point SHALL When the protection domain is in Normal State the end-point SHALL
transmit a NR(0,0) message, indicating - Nothing to report and data transmit a NR(0,0) message, indicating - Nothing to report and data
skipping to change at page 24, line 24 skipping to change at page 24, line 43
path, then it will now be in remote Unavailable state) and path, then it will now be in remote Unavailable state) and
continue transmission of the current message (either NR(0,0) or continue transmission of the current message (either NR(0,0) or
LO(0,0) or SF(0,0)) LO(0,0) or SF(0,0))
o A remote Signal Fail message that indicates that the failure is on o A remote Signal Fail message that indicates that the failure is on
the protection path SHALL cause the LER to remain in Unavailable the protection path SHALL cause the LER to remain in Unavailable
state and continue transmission of the current message (either state and continue transmission of the current message (either
NR(0,0) or SF(0,0) or LO(0,0)). NR(0,0) or SF(0,0) or LO(0,0)).
o A remote No Request, when the LER is in remote Unavailable state o A remote No Request, when the LER is in remote Unavailable state
SHALL cause the LER to go into Normal state and continue and there is no active local Signal Fail SHALL cause the LER to go
transmission of the current message (either NR(0,0) or SF(0,0)). into Normal state and continue transmission of the current
If there is a local SF indicator this may cause an immediate state message. If there is a local Signal Fail on the protection path,
change after switching into Normal state. When in local the LER SHALL remain in local Unavailable state and transmit a
Unavailable state, the remote message SHALL be ignored. SF(0,0) message. If there is a local Signal Fail on the working
path, the LER SHALL go into local Protecting Failure state and
transmit a SF(1,1) message. When in local Unavailable state, the
remote message SHALL be ignored.
o All other remote messages SHALL be ignored. o All other remote messages SHALL be ignored.
4.3.3.3. Protecting administrative state 4.3.3.3. Protecting administrative state
In the protecting state the user data traffic is being transported on In the protecting state the user data traffic is being transported on
the protection path, while the working path is blocked due to an the protection path, while the working path is blocked due to an
operator command, i.e. Forced Switch or Manual Switch. The operator command, i.e. Forced Switch or Manual Switch. The
difference between a local FS and local MS affects what local difference between a local FS and local MS affects what local
indicators may be received - the Local request logic will block any indicators may be received - the Local request logic will block any
skipping to change at page 26, line 42 skipping to change at page 27, line 15
Protecting administrative state and continue transmission of the Protecting administrative state and continue transmission of the
MS(1,1) message. MS(1,1) message.
o A remote DNR(0,1) message SHALL be ignored if in local Protecting o A remote DNR(0,1) message SHALL be ignored if in local Protecting
administrative state. If in remote Protecting administrative administrative state. If in remote Protecting administrative
state then the LER SHALL go to Do-not-revert state and continue state then the LER SHALL go to Do-not-revert state and continue
transmitting the current message. transmitting the current message.
o A remote NR(0,0) message SHALL be ignored if in local Protecting o A remote NR(0,0) message SHALL be ignored if in local Protecting
administrative state. If in remote Protecting administrative administrative state. If in remote Protecting administrative
state then the LER SHALL go to Normal state and begin transmitting state and there is no active local Signal Fail indication then the
a NR(0,0) message. LER SHALL go to Normal state and begin transmitting a NR(0,0)
message. If there is a local Signal Fail on the working path, the
LER SHALL go to local Protecting failure state and begin
transmitting a SF(1,1) message.
o All other remote messages SHOULD be ignored. o All other remote messages SHOULD be ignored.
4.3.3.4. Protecting failure state 4.3.3.4. Protecting failure state
When the protection mechanism has been triggered and the protection When the protection mechanism has been triggered and the protection
domain has performed a protection switch, the domain is in the domain has performed a protection switch, the domain is in the
protecting failure state. In this state the normal data traffic is protecting failure state. In this state the normal data traffic is
transported on the protection path. When an LER is in this state it transported on the protection path. When an LER is in this state it
implies that there was either a local SF condition or received a implies that there was either a local SF condition or received a
skipping to change at page 31, line 24 skipping to change at page 32, line 4
LER to go into remote Protecting failure state, and begin LER to go into remote Protecting failure state, and begin
transmission of a NR(0,1) message. transmission of a NR(0,1) message.
o A remote Manual switch message SHALL cause the LER to go into o A remote Manual switch message SHALL cause the LER to go into
remote Protecting administrative state and begin transmission of a remote Protecting administrative state and begin transmission of a
NR(0,1) message. NR(0,1) message.
o All other remote messages SHOULD be ignored. o All other remote messages SHOULD be ignored.
5. IANA Considerations 5. IANA Considerations
5.1. Pseudowire Associated Channel Type
This draft requires the allocation of a Channel Code from the G-ACh In the "Pseudowire Name Spaces (PWE3) IANA" maintains the "
repository. Pseudowire Associated Channel Types Registry".
IANA is requested to assign a new code point from this registry. The
code point shall be assigned form the code point space that requires
"IETF Review" as follows:
Registry:
Value Description TLV Follows Reference
----- ----------------------- ----------- ---------------
0xHH Protection State no [this document]
Coordination Protocol -
Channel Type (PSC-CT)
5.2. PSC Request Field
The IANA is instructed to create and maintain a new registry within
the "Multiprotocol Label Switching Architecture (MPLS)" called "MPLS
PSC Request Registry". All code points within this registry shall be
allocated according to the "Standards Action" procedures as specified
in [RFC5226].
The PSC Request Field is 4 bits and the values shall be allocated as
follows:
Value Description Reference
------------- --------------------- ---------------
b0000 No Request [this document]
b0001 Do not revert [this document]
b0010 - b0011 Unassigned
b0100 Wait to restore [this document]
b0101 Manual switch [this document]
b0110 Unassigned
b0111 Signal Degrade [this document]
b1000 - b1001 Unassigned
b1010 Signal Fail [this document]
b1011 Unassigned
b1100 Forced switch [this document]
b1101 Unassigned
b1110 Lockout of protection [this document]
b1111 Unassigned
6. Security Considerations 6. Security Considerations
To be added in future version. The generic security considerations for the data-plane of MPLS-TP are
described in the security framework document [SecureFwk] together
with the required mechanisms needed to address them. The security
considerations for the generic associated control channel are
described in [RFC5586]. The security considerations for protection
and recovery aspects of MPLS-TP are addressed in [SurvivFwk].
The protocol described in this document is based on the use of the
Generic Associated Channel as defined in [RFC5586]. Any new security
risk introduced may be in the treatment of corrupted protocol units.
The main concern is around the Request, FPath and Path fields as a
change to these fields would change the behavior of the peer
endpoint. Although there is no way to avoid a change in network
behavior upon receipt of a message indicating a change in protection
status, the transition between states will converge on a known and
stable behavior in the face of messages which do not match reality.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank all members of the teams (the Joint The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the Working Team, the MPLS Interoperability Design Team in IETF and the
T-MPLS Ad Hoc Group in ITU-T) involved in the definition and T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS Transport Profile. specification of MPLS Transport Profile.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
8.2. Informative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Jan 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, Jan 2001.
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
October 2009.
[RFC3985] Bryant, S. and P. Pate, "Pseudowire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985, March 2005.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
[TPFwk] Bocci, M., Bryant, S., and L. Levrau, "A Framework for
MPLS in Transport Networks",
ID draft-ietf-mpls-tp-framework-06.txt, July 2009.
[RFC5586] Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, R., and
D. Ward, "MPLS Generic Associated Channel", RFC 5586,
May 2009.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery Terminology for
Generalized Multi-Protocol Label Switching", RFC 4427,
Mar 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[SurvivFwk]
Sprecher, N., Farrel, A., and H. Shah, "Multi-protocol
Label Switching Transport Profile Survivability
Framework", ID draft-ietf-mpls-tp-survive-fwk-02.txt,
Feb 2009.
[SecureFwk]
Fang, L., Niven-Jenkins, B., Mansfield, S., Zhang, R.,
Bitar, N., Daikoku, M., and L. Wang, "MPLS-TP Security
Framework",
ID draft-ietf-mpls-tp-security-framework-00.txt, Feb 2011.
[RFC4872] Lang, J., Papadimitriou, D., and Y. Rekhter, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, Oct 2004.
Appendix A. PSC state machine tables Appendix A. PSC state machine tables
The PSC state machine is described in section 4.3.3. This appendix The PSC state machine is described in section 4.3.3. This appendix
provides the same information but in tabular format. In the event of provides the same information but in tabular format. In the event of
a mismatch between these tables and the text in section 4.3.3, the a mismatch between these tables and the text in section 4.3.3, the
text is authoritative. Note that this appendix is intended to be a text is authoritative. Note that this appendix is intended to be a
functional description, not an implementation specification. functional description, not an implementation specification.
For the sake of clarity of the table the six states listed in the For the sake of clarity of the table the six states listed in the
text are split into thirteen states. The logic of the split is to text are split into thirteen states. The logic of the split is to
skipping to change at page 35, line 18 skipping to change at page 38, line 36
--------+-------+------+------+------+------+------+------+------ --------+-------+------+------+------+------+------+------+------
N |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | i N |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | i
UA:LO:L | i | i | i | i | i | i | i | i UA:LO:L | i | i | i | i | i | i | i | i
UA:P:L | [10] | i | i | i | i | i | i | i UA:P:L | [10] | i | i | i | i | i | i | i
UA:LO:R | i | i | i | i | i | i | i | [16] UA:LO:R | i | i | i | i | i | i | i | [16]
UA:P:R |UA:LO:R| i | i | i | i | i | i | [16] UA:P:R |UA:LO:R| i | i | i | i | i | i | [16]
PF:W:L | [11] | [12] |PA:F:R| i | i | i | i | i PF:W:L | [11] | [12] |PA:F:R| i | i | i | i | i
PF:W:R |UA:LO:R|UA:P:R|PA:F:R| i | i | [14] | [15] | N PF:W:R |UA:LO:R|UA:P:R|PA:F:R| i | i | [14] | [15] | N
PA:F:L |UA:LO:R|UA:P:R| i | i | i | i | i | i PA:F:L |UA:LO:R|UA:P:R| i | i | i | i | i | i
PA:M:L |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | i | i PA:M:L |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | i | i
PA:F:R |UA:LO:R|UA:P:R| i | i | i | i | i | N PA:F:R |UA:LO:R|UA:P:R| i | i | i | i | i | [17]
PA:M:R |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | i | N PA:M:R |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | i | N
WTR |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | [17] WTR |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | [18]
DNR |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | i DNR |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | i
The following are the footnotes for the table: The following are the footnotes for the table:
[1] Remain in the current state (UA:LO:R) and transmit SF(0,0) [1] Remain in the current state (UA:LO:R) and transmit SF(0,0)
[2] Remain in the current state (UA:LO:R) and transmit SF(1,0) [2] Remain in the current state (UA:LO:R) and transmit SF(1,0)
[3] Remain in the current state (UA:P:R) and transmit SF(1,0) [3] Remain in the current state (UA:P:R) and transmit SF(1,0)
skipping to change at page 36, line 11 skipping to change at page 39, line 29
[12] Transition to UA and send SF(1,0) [12] Transition to UA and send SF(1,0)
[13] Transition to PF:W:R and send NR(0,1) [13] Transition to PF:W:R and send NR(0,1)
[14] Transition to WTR state and continue to send the current [14] Transition to WTR state and continue to send the current
message. message.
[15] Transition to DNR state and continue to send the current [15] Transition to DNR state and continue to send the current
message. message.
[16] Transition to N state and continue to send the current message. [16] If the local input is SF-P then transition to UA:P:L. If the
local input is SF-W then transition to PF:W:L. Else - transition to N
[17] If the receiving node's WTR timer is running, maintain current state and continue to send the current message.
state and message. If the WTR timer is stopped, transition to N.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
8.2. Informative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Jan 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, Jan 2001.
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
October 2009.
[RFC3985] Bryant, S. and P. Pate, "Pseudowire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985, March 2005.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
[TPFwk] Bocci, M., Bryant, S., and L. Levrau, "A Framework for
MPLS in Transport Networks",
ID draft-ietf-mpls-tp-framework-06.txt, July 2009.
[RFC5586] Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, R., and
D. Ward, "MPLS Generic Associated Channel", RFC 5586,
May 2009.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery Terminology for [17] If the local input is SF-W then transition to PF:W:L. Else -
Generalized Multi-Protocol Label Switching", RFC 4427, transition to N state and continue to send the current message.
Mar 2006.
[SurvivFwk] [18] If the receiving LER's WTR timer is running, maintain current
Sprecher, N., Farrel, A., and H. Shah, "Multi-protocol state and message. If the WTR timer is stopped, transition to N.
Label Switching Transport Profile Survivability
Framework", ID draft-ietf-mpls-tp-survive-fwk-02.txt,
Feb 2009.
[RFC4872] Lang, J., Papadimitriou, D., and Y. Rekhter, "RSVP-TE Appendix B. Exercising the protection domain
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching There is a requirement in [RFC5654] (number 84) that discusses a
(GMPLS) Architecture", RFC 3945, Oct 2004. requirement to verify that the protection path is viable. While the
PSC protocol does not define a specific operation for this
functionality, it is possible to perform this operation by combining
operations of the PSC and other OAM functionalities. One such
possible combination would be to issue a Lockout of Protection
operation and then use the OAM function for diagnostic testing of the
protection path. Similarly, to test the paths when the working path
is not active would involve performing a Forced Switch to protection
and then perform the diagnostic function on either the working or
protection path.
Authors' Addresses Authors' Addresses
Stewart Bryant (editor) Stewart Bryant
Cisco Cisco
United Kingdom United Kingdom
Email: stbryant@cisco.com Email: stbryant@cisco.com
Eric Osborne Eric Osborne
Cisco Cisco
United States United States
Email: eosborne@cisco.com Email: eosborne@cisco.com
Nurit Sprecher (editor) Nurit Sprecher
Nokia Siemens Networks Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B 3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241 Hod Hasharon, 45241
Israel Israel
Email: nurit.sprecher@nsn.com Email: nurit.sprecher@nsn.com
Annamaria Fulignoli (editor) Annamaria Fulignoli (editor)
Ericsson Ericsson
Italy Italy
Phone:
Email: annamaria.fulignoli@ericsson.com Email: annamaria.fulignoli@ericsson.com
Yaacov Weingarten Yaacov Weingarten (editor)
Nokia Siemens Networks Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B 3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241 Hod Hasharon, 45241
Israel Israel
Phone: +972-9-775 1827
Email: yaacov.weingarten@nsn.com Email: yaacov.weingarten@nsn.com
 End of changes. 53 change blocks. 
152 lines changed or deleted 277 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/