draft-ietf-mpls-tp-linear-protection-01.txt   draft-ietf-mpls-tp-linear-protection-02.txt 
Network Working Group S. Bryant, Ed. Network Working Group S. Bryant, Ed.
Internet-Draft Cisco Internet-Draft E. Osborne
Intended status: Standards Track N. Sprecher, Ed. Intended status: Standards Track Cisco
Expires: September 8, 2010 Nokia Siemens Networks Expires: January 27, 2011 N. Sprecher, Ed.
H. van Helvoort, Ed. Nokia Siemens Networks
Huawei
A. Fulignoli, Ed. A. Fulignoli, Ed.
Ericsson Ericsson
Y. Weingarten Y. Weingarten
Nokia Siemens Networks Nokia Siemens Networks
March 7, 2010 July 26, 2010
MPLS-TP Linear Protection MPLS-TP Linear Protection
draft-ietf-mpls-tp-linear-protection-01.txt draft-ietf-mpls-tp-linear-protection-02.txt
Abstract Abstract
The MPLS Transport Profile (MPLS-TP) being specified jointly by IETF The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is
and ITU-T includes requirements documents and framework documents. being specified jointly by IETF and ITU-T. This document addresses
The framework documents define the basic architecture that is needed the functionality described in the MPLS-TP Survivability Framework
in order to support various aspects of the required behavior. This document [SurvivFwk] and defines a protocol that may be used to
document addresses the functionality described in the MPLS-TP fulfill the function of the Protection State Coordination for linear
Survivability Framework document and defines a protocol that may be protection, as described in that document.
used to fulfill the function of the Protection State Coordination for
linear protection, as described in that document.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications (IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as capabilities and functionalities of a packet transport network as
defined by the ITU-T. defined by the ITU-T.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 8, 2010. This Internet-Draft will expire on January 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Contributing authors . . . . . . . . . . . . . . . . . . . 5 1.1. Protection architectures . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5 1.2. Scope of the document . . . . . . . . . . . . . . . . . . 5
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Contributing authors . . . . . . . . . . . . . . . . . . . 6
2.2. Definitions and Terminology . . . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 6
3. Protection switching logic . . . . . . . . . . . . . . . . . . 6 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Protection switching trigger mechanisms . . . . . . . . . 6 2.2. Definitions and Terminology . . . . . . . . . . . . . . . 7
3.2. Protection switching control logical architecture . . . . 7 3. Protection switching control logic . . . . . . . . . . . . . . 7
3.2.1. PSC Status Module . . . . . . . . . . . . . . . . . . 8 3.1. Protection switching control logical architecture . . . . 7
4. Protection state coordination (PSC) protocol . . . . . . . . . 8 3.1.1. Local Request Logic . . . . . . . . . . . . . . . . . 8
4.1. Transmission and acceptance of PSC control packets . . . . 9 3.1.2. Remote Requests . . . . . . . . . . . . . . . . . . . 10
4.2. Protocol format . . . . . . . . . . . . . . . . . . . . . 10 3.1.3. PSC Process Logic . . . . . . . . . . . . . . . . . . 11
4.2.1. PSC Requests . . . . . . . . . . . . . . . . . . . . . 11 3.1.4. PSC Message Generator . . . . . . . . . . . . . . . . 11
4.2.2. Protection Type (PT) . . . . . . . . . . . . . . . . . 12 3.1.5. Wait-to-Restore (WTR) timer . . . . . . . . . . . . . 12
4.2.3. Path fault identifier (FPath) . . . . . . . . . . . . 12 3.1.6. PSC Control States . . . . . . . . . . . . . . . . . . 12
4.2.4. Active path indicator (Path) . . . . . . . . . . . . . 12 4. Protection state coordination (PSC) protocol . . . . . . . . . 13
4.3. Principles of Operation . . . . . . . . . . . . . . . . . 13 4.1. Transmission and acceptance of PSC control packets . . . . 13
4.3.1. PSC States . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Protocol format . . . . . . . . . . . . . . . . . . . . . 14
4.3.2. Failure or Degraded condition (Working path) . . . . . 14 4.2.1. PSC Ver field . . . . . . . . . . . . . . . . . . . . 15
4.3.3. Lockout of Protection . . . . . . . . . . . . . . . . 15 4.2.2. PSC Request field . . . . . . . . . . . . . . . . . . 15
4.3.4. Failure or Degraded condition (Recovery path) . . . . 16 4.2.3. Protection Type (PT) . . . . . . . . . . . . . . . . . 16
4.3.5. Operator Controlled Switching . . . . . . . . . . . . 16 4.2.4. Revertive (R) field . . . . . . . . . . . . . . . . . 16
4.3.6. Recovery from switching . . . . . . . . . . . . . . . 17 4.2.5. Fault path (FPath) field . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 4.2.6. Data path (Path) field . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4.3. Principles of Operation . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 4.3.1. Basic operation . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3.2. Priority of inputs . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 4.3.3. Operation of PSC States . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
As noted in the architecture for Multi-Protocol Label Switching The MPLS Transport Profile (MPLS-TP) [TPFwk] is a framework for the
Transport Profile (MPLS-TP) [TPFwk], the overall architecture construction and operation of packet-switched transport networks
framework for MPLS-TP is based on a profile of the MPLS and based on the architectures for MPLS ([RFC3031] and [RFC3032]) and for
Pseudowire (PW) procedures as specified for the MPLS and (MS-)PW Pseudowires (PWs) ([RFC3985] and [RFC5659]) and the requirements of
architectures defined in [RFC3031], [RFC3985] and [RFC5085]. One of [RFC5654].
the basic survivability functions, pointed out by the Survivability
Framework document [SurvivFwk], is that of simple and rapid Network survivability is the ability of a network to recover traffic
protection switching mechanisms for Label Switched Paths (LSP) and delivery following failure, or degradation of network resources. The
Pseudo-wires (PW). MPLS-TP Survivability Framework [SurvivFwk] is a framework for
survivability in MPLS-TP networks, and describes recovery elements,
types, methods, and topological considerations, focusing on
mechanisms for recovering MPLS-TP Label Switched Paths (LSPs).
Linear protection in mesh networks - networks with arbitrary
interconnectivity between nodes - is described in Section 4.7 of
[SurvivFwk]. Linear protection provides rapid and simple protection
switching. In a mesh network, linear protection provides a very
suitable protection mechanism because it can operate between any pair
of points within the network. It can protect against a defect in an
intermediate node, a span, a transport path segment, or an end-to-end
transport path.
1.1. Protection architectures
Protection switching is a fully allocated survivability mechanism. Protection switching is a fully allocated survivability mechanism.
It is fully allocated in the sense that the route and bandwidth of It is fully allocated in the sense that the route and bandwidth of
the recovery path is reserved for a selected working path or set of the recovery 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 protected domain. For the protection switching is applied to a protection domain. For the
purposes of this document, we define the protected domain of a P2P purposes of this document, we define the protection domain of a P2P
LSP as consisting of two Label Switching Routers (LSR) and the LSP as consisting of two Label Switching Routers (LER) and the
transport paths that connect them. For a P2MP LSP the protection transport paths that connect them. For a P2MP LSP the protection
domain includes the root (or source) LSR, the destination (or sink) domain includes the root (or source) LER, the destination (or sink)
LSRs, and the transport paths that connect them. LSRs, 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
recovery transport path is dedicated to each working transport path. recovery transport path is dedicated to each 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 recovery transport entities by a permanent bridge the working and the recovery transport entities by a permanent bridge
at the source of the protection domain. The sink of the protection at the source of the protection domain. The sink of the protection
domain selects which of the working or recovery entities to receive domain selects which of the working or recovery entities to receive
the traffic from, based on a predetermined criteria, e.g. server the traffic from, based on a predetermined criteria, e.g. server
defect indication. When used for bidirectional switching the 1+1 defect indication. When used for bidirectional switching the 1+1
skipping to change at page 5, line 11 skipping to change at page 5, line 25
protection domain. A selector at the sink of the protection domain protection domain. A selector at the sink of the protection domain
then selects the path that carries the normal traffic. Since the then selects the path that carries the normal traffic. Since the
source and sink need to be coordinated to ensure that the selector source and sink need to be coordinated to ensure that the selector
bridge at both ends select the same path, this architecture must bridge at both ends select the same path, this architecture must
support a PSC protocol. support a PSC protocol.
The 1:n protection architecture extends this last architecture by The 1:n protection architecture extends this last architecture by
sharing the recovery path amongst n services. Again, the recovery sharing the recovery path amongst n services. Again, the recovery
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 only once, either on the traffic for each service is transmitted only once, similar to the 1:1
normal working path for that service or, in cases that trigger case by using a selector bridge at the source, either on the normal
protection switching (as defined in [SurvivFwk]), may be sent on the working path for that service or, in cases that trigger protection
recovery path. It should be noted that in cases where multiple switching (as defined in [SurvivFwk]), may be sent on the recovery
working path services have triggered protection switching that some path. It should be noted that in cases where multiple working path
services, dependent upon their Service Level Agreement (SLA), may not services have triggered protection switching that some services,
be transmitted as a result of limited resources on the recovery path. dependent upon their Service Level Agreement (SLA), may not be
In this architecture there is a need for coordination of the transmitted as a result of limited resources on the recovery path.
In this architecture there may be a need for coordination of the
protection switching, and in addition there is need for resource protection switching, and in addition there is need for resource
allocation negotiation. Due to the added complexity of this allocation negotiation. Due to the added complexity of this
architecture, the procedures for this will be delayed to a different architecture, the procedures for this will be delayed to a different
document and further study. document and further study.
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. This document maintain traffic over a co-routed bidirectional LSP.
presents a protocol and a set of procedures for activating this
coordination within the protection domain.
1.1. Contributing authors The scope of this draft is to present a protocol for the Protection
State Coordination of Linear Protection. The protocol addresses the
protection of LSPs in an MPLS-TP network as required by [RFC5654] (in
particular requirements 63-67 and 74-79) and described in
[SurvivFwk]. The basic protocol is designed for use in conjunction
with the 1:1 protection architecture (for both unidirectional and
bidirectional protection) and for 1+1 protection of a bidirectional
path (for both unidirectional and bidirectional protection
switching). Applicability of the protocol for 1:n protection schemes
may be documented in a future document. The applicability of this
protocol to additional MPLS-TP constructs and topologies may be
documented in future documents.
Hao Long (Huawei) While the unidirectional 1+1 protection architecture does not require
the use of a coordination protocol, the protocol may be used by the
ingress node of the path to notify the far-side end point that a
switching condition has occurred and verify the consistency of the
end-point configuration. This use may be especially useful for
point-to-multipoint transport paths, that are unidirectional by
definition of [RFC5654].
1.3. Contributing authors
Hao Long (Huawei), Dan Frost (Cisco), Davide Chiara (Ericsson),
Francesco Fondelli (Ericsson),
2. Conventions used in this document 2. Conventions used in this document
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
GACH Generic Associated Channel Header G-ACh Generic Associated Channel Header
LSR Label Switching Router LER Label Switching Router
MPLS-TP Transport Profile for MPLS MPLS-TP Transport Profile for MPLS
MS Manual Switch MS Manual Switch
P2P Point-to-point P2P Point-to-point
P2MP Point-to-multipoint P2MP Point-to-multipoint
PDU Packet Data Unit PDU Packet Data Unit
PSC Protection State Coordination Protocol PSC Protection State Coordination Protocol
PST Path Segment Tunnel PST Path Segment Tunnel
SD Signal Degrade SD Signal Degrade
SF Signal Fail SF Signal Fail
SLA Service Level Agreement SLA Service Level Agreement
WTR Wait-to-Restore WTR Wait-to-Restore
2.2. Definitions and Terminology 2.2. Definitions and Terminology
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 LSR 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 LER, LER, T-PE, or S-PE.
3. Protection switching logic 3. Protection switching control logic
3.1. Protection switching trigger mechanisms 3.1. Protection switching control logical architecture
The protection switching should be initiated in reaction to any of Protection switching processes the local triggers described in
the following triggers: [RFC5654] requirements 74-79 together with inputs received from the
far-end LER. Based on these inputs the LER will take certain
protection switching actions, e.g. switching the Selector Bridge to
select the working or protection path, and transmit different
protocol messages.
o Server layer indication - if the MPLS-TP server layer detects a The following figure shows the logical decomposition of the PSC
failure within its own layer, or due to a failure of its server Control Logic into different logical processing units. These
layer (e.g. the physical layer) notifies the MPLS-TP layer that a processing units are presented in subsequent sub-sections of this
failure has been detected. It should be noted that this trigger document.
will be controlled by a holdoff-timer that should be configured to
allow the server layer to apply any protection procedures that may
be relevant.
o OAM signalling - if, for example, OAM continuity and connectivity Server Indication Control Plane Indication
verification tools detect that there is a loss of continuity or -----------------+ +-------------
mis-connectivity or performance monitoring indicates a degradation Operator Command | | OAM Indication
of the utility of the working path for the current transport path. ----------------+ | | +---------------
In cases of signal degradation, switching to the recovery path | | | |
SHOULD only be activated if the recovery path can guarantee better V V V V
conditions than the degraded working path. +---------------+ +-------+
| Local Request |<--------| WTR |
| logic |WTR Exps | Timer |
+---------------+ +-------+
| ^
Highest local|request |
V | Start/Stop
+-----------------+ |
Remote PSC | PSC Process |------------+
------------>| logic |
Request +-----------------+
|
| Action +------------+
+---------------->| Message |
| Generator |
+------------+
|
Output PSC | Message
V
o Control plane - if there is a control plane active in the network Figure 1: Protection switching control logic
(either signaling or routing), it MAY trigger protection switching
based on conditions detected by the control plane. If the Figure 1 describes the logical architecture of the protection
control-plane is based on GMPLS [RFC3945] then the recovery switching control. The Local Request logic unit accepts the triggers
process should comply with the process described in [RFC4872]. from the OAM, external operator commands, from the local control
plane (when present), and the Wait-to-Restore timer. By considering
all of these local request sources it determines the highest priority
local request. This high-priority request is passed to the PSC
Process logic, that will cross-check this local request with the
information received from the far-end LER. The PSC Process logic
uses this input to determine what actions need to be taken, e.g.
local actions at the LER, or what message should be sent to the far-
end LER, and the current status of the protection domain.
3.1.1. Local Request Logic
The protection switching logic processes input triggers from five
sources:
o Operator command - the network operator may issue commands that o Operator command - the network operator may issue commands that
trigger protection switching. The commands that are supported trigger protection switching. The commands that are supported
include - Forced Switch, Manual Switch, Clear, Lockout of include - Forced Switch, Manual Switch, Clear, Lockout of
Protection, (see definitions in [RFC4427]). Protection, (see definitions in [RFC4427]).
3.2. Protection switching control logical architecture o Server layer alarm indication - the underlying server layer of the
network detects failure conditions at the underlying layer and may
issue an indication to the MPLS-TP layer. The server layer may
employ its own protection switching mechanism, and therefore this
input MAY be controlled by a holdoff-timer that SHOULD be
configurable by the network operator.
Protection switching processes the triggers described above together o Control plane - if there is a control plane active in the network
with the inputs received from the far-end LSR. These inputs cause (either signaling or routing), it MAY trigger protection switching
the LSR to take certain actions, e.g. switching the Selector Bridge based on conditions detected by the control plane. If the
to select the working or recovery path, and to transmit different control-plane is based on GMPLS [RFC3945] then the recovery
protocol messages. process SHALL comply with the process described in [RFC4872].
+-------------+ Operator Command Local PSC +-----------+ o OAM indication - OAM fault management or performance measurement
| External |-----------------+ +-----------------| PSC Status| tools may detect a failure or degrade condition on the MPLS-TP
| Interface | | | request +---| Module | transport path and this SHOULD input an indication to the Local
+-------------+ | | | +-----------+ Request Logic.
V V V Prot. Stat. ^
+----------+ Local OAM +---------------+Highest +------------+ |
| OAM |----------->| Local Request |------->| PSC Mess. | |
| Module | request | logic |local R.| Generator | |
+----------+ +------->+---------------+ +------------+ |
+----------+ | | | |
| Svr/CP |---+ Highest local|request | |
+----------+ V V |
+-------------+ +-----------------+ PSC Message |
| Remote Req. | Remote PSC | global Request | |
| Receiver |------------>| logic | |
+-------------+ Request +-----------------+ |
^ | |
| Highest global request| |
| V |
| +-----------------+ PSC status |
Remote PSC message | PSC Process |-----------------+
| logic |--------> Action
| |
+-----------------+
Figure 1: Protection switching control logic o WTR expires - The Wait-to-Restore timer is used in conjunction
with recovery from failure conditions on the working path in
revertive mode. The timer SHALL signal the PSC control process
when it expires and the end-point SHOULD revert to the normal
transmission of the user data traffic.
Figure 1 describes the logical architecture of the protection The Local request logic SHALL process these different input sources
switching control. The Local Request logic unit accepts the triggers and, based on the priorities between them, SHOULD produce a current
from the OAM, external operator commands, and from the local control local request. The different local requests that may be output from
plane (when present) and determines the highest priority request. the Local Request Logic are:
This high-priority request is passed to both the PSC Message
generator, that will generate the appropriate protocol message to be
sent to the far-end LSR, and the Global Request logic, that will
cross-check this local request with the information received from the
far-LSR. The Global Request logic then processes these two PSC
requests that determines the highest priority request that is passed
to the PSC Process logic. The PSC Process logic uses this input to
determine what actions need to be taken, e.g. switching the Selector
Bridge, and the current status of the protection domain.
3.2.1. PSC Status Module o Clear - if the opeartor cancels an active local administrative
command, i.e. LO/FS/MS.
The PSC Control Logic must retain the status of the protection o Lockout of Protection (LO) - if the operator requested to disable
domain. The possible different states indicate the current status of the protection path.
the protection environment, and can be in one of three states:
o Normal (Idle) state - When both the recovery and the working paths o Signal Fail (SF) - if any of the Server Layer, Control plane, or
are fully allocated and active, data traffic is being transmitted OAM indications signaled a failure condition on either the
over the working path, and there are no trigger events reported protection path or one of the working paths.
within the domain.
o Protecting state - When either the working path has reported a o Signal Degrade (SD) - if any of the Server Layer, Control plane,
signal failure (SF) or degradation of signal (SD), or the operator or OAM indications signaled a degraded transmission condition on
has issued an operator command and the data traffic has been either the protection path or one of the working paths
redirected to the recovery path.
o Unavailable state - When the recovery path is unavailable, either o Clear Signal Fail - if all of the Server Layer, Control plane, or
as a result of reporting a SF or SD condition, or as a result of OAM indications are no longer indicating a failure condition on a
an administrative Lockout command. path that was peviously indicating a failure condition.
This state may affect the actions taken by the control logic, and o Forced Switch (FS) - if the operator requested that traffic be
therefore, the PSC Status Module transfers the current status to the switched from one of the working paths to the protection path.
Local Request Logic.
See section 4.3.1 for details on what actions are affected by the PSC o Manual Switch (MS) - if the operator requested that traffic be
state. switched from its current path to the other path. This is only
relevant if there is no currently active Fault condition or
Operator command.
o WTR Expires - generated by the WTR timer completing its period.
If none of the input sources have generated any input then the
current local request SHALL be a No Request (NR) request.
3.1.2. Remote Requests
In addition to the local requests generated as a result of the local
triggers indicated in the previous sub-section, the PSC Control Logic
SHALL accept PSC messages from the far-end LER of the transport path.
These remote messages indicate the status of the transport path from
the viewpoint of the far-end LER, and may indicate if the local MEP
SHOULD initiate a protection switch operation.
The following remote requests may be received by the PSC process:
o Remote LO - indicates that the remote end-point is in Unavailable
state due to a Lockout of Protection operator command.
o Remote SF - indicates that the remote end-point has detected a
Signal Fail condition on one of the transport paths in the
protection domain. This remote message SHALL include an
indication of which transport path is affected by the SF
condition. In addition, it should be noted that the SF condition
may be either unidirectional or bidirectional failure, even if the
transport path is bidirectional.
o Remote SD - indicates that the remote end-point has detected a
Signal Degrade condition on one of the transport paths in the
protection domain. This remote message SHALL include an
indication of which transport path is affected by the SD
condition. In addition, it should be noted that the SD condition
may be either unidirectional or bidirectional failure, even if the
transport path is bidirectional.
o Remote FS - indicates that the remote end point is operating under
an operator command to switch the traffic to the protection path.
o Remote MS - indicates that the remote end point is operating under
an operator command to switch the traffic to the path that was not
being used previously.
o Remote WTR - indicates that the remote end-point has determined
that the failure condition has recovered and has started its WTR
timer in preparation for reverting to the Normal state.
o Remote DNR - indicates that the remote end-point has determined
that the failure condition has recovered and will continue
transporting traffic on the protection path due to operator
configuration that prevents automatic reversion to the Normal
state.
o Remote NR - indicates that the remote end-point has no abnormal
condition to report.
3.1.3. PSC Process Logic
The PSC Process Logic SHALL accept as input - a. the Local request
output from the Local Request Logic, b. the remote request message
from the remote end-point of the transport path, and c. the current
state of the PSC Control Logic (maintained internally by the PSC
Control Logic). Based on the priorities between the different
inputs, the PSC Process Logic SHALL determine the new state of the
PSC Control Logic and what actions need to be taken.
The new state information SHALL be sent for retention by the State
Manager, while the requested action SHALL be sent to the PSC Message
Generator (see subsection 3.1.4) to generate and transmit the proper
PSC message to be transmitted to the remote end-point of the
protection domain.
3.1.4. PSC Message Generator
Based on the action output from the Process Logic this unit formats
the PSC protocol message that is transmitted to the remote end-point
of the protection domain. When the PSC information has changed three
PSC messages SHOULD be transmitted in quick succession, and
subsequent messages should be transmitted continually at a slower
rate.
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.1.5. Wait-to-Restore (WTR) timer
The WTR timer is used to delay reversion to Normal state when
recovering from a failure condition on the working path and the
protection domain is configured for revertive behavior. The WTR
timer MAY be started, stopped, or expire. If the WTR timer is
running, sending a Stop command SHALL reset the timer but SHALL NOT
generate a WTR Expires local signal. If the WTR timer is not
running, a Stop command SHALL be ignored.
3.1.6. PSC Control States
The PSC Control Logic SHOULD maintain information on the current
state of the protection domain. The state information SHALL include
information of the current state and an indication of the cause for
the current state (e.g. unavailable due to local LO command,
protecting due to remote FS). In particular, the state information
SHOULD include an indication if the state is related to a remote or
local condition.
The states that are supported by the PSC Control Logic include:
o Normal state - Both the protection and working paths are fully
allocated and active, data traffic is being transmitted over the
working path, and no trigger events are reported within the
domain.
o Unavailable state - The protection path is unavailable - either as
a result of an operator Lockout command or a failure/degrade
condition detected on the protection path.
o Protecting failure state - The working path has reported a
failure/degrade condition and the user traffic is being
transmitted on the protection path.
o Protecting administrative state - The operator has issued a
command switching the user traffic to the protection path.
o Wait-to-restore state - The protection domain is recovering from a
SF/SD condition on the working path that is being controlled by
the Wait-to-Restore (WTR) timer.
o Do-not-revert state - The protection domain is recovering from a
Protecting state, but the operator has configured the protection
domain to not automatically revert to the Normal state upon
recovery. The protection domain SHALL remain in this state until
the operator issues a command to revert to the Normal state or
there is a new trigger to switch to a different state.
See section 4.3.1 for details on what actions are taken by the PSC
Process Logic for each state and the relevant input.
4. Protection state coordination (PSC) protocol 4. Protection state coordination (PSC) protocol
Bidirectional protection switching, as well as unidirectional 1:1 Bidirectional protection switching, as well as unidirectional 1:1
protection, requires coordination between the two end-points in protection, requires coordination between the two end-points in
determining which of the two possible paths, the working or recovery determining which of the two possible paths, the working or recovery
path, is transmitting the data traffic in any given situation. When path, is transmitting the data traffic in any given situation. When
protection switching is triggered as described in section 3.1, the protection switching is triggered as described in section 3.1, the
end-points must inform each other of the switch-over from one path to end-points must inform each other of the switch-over from one path to
the other in a coordinated fashion. the other in a coordinated fashion.
There are different possibilities for the type of coordinating There are different possibilities for the type of coordinating
protocol. One possibility is a two-phased coordination in which the protocol. One possibility is a two-phased coordination in which the
MEP that is initiating the protection switching sends a protocol LER that is initiating the protection switching sends a protocol
message indicating the switch but the actual switch-over is performed message indicating the switch but the actual switch-over is performed
only after receiving an 'Ack' from the far-end MEP. The other only after receiving an 'Ack' from the far-end LER. The other
possibility is a single-phased coordination, in which the initiating possibility is a single-phased coordination, in which the initiating
MEP switches over to the alternate path and informs the far-end MEP LER performs the protection switchover to the alternate path and
of the switch, and the far-end MEP must complete the switch-over. informs the far-end LER of the switch, and the far-end LER must
complete the switchover.
In the following sub-sections we describe the protocol messages that
should be used between the two end-points of the protection domain.
For the sake of simplicity of the protocol, this protocol is based on For the sake of simplicity of the protocol, this protocol is based on
the single-phase approach described above. the single-phase approach described above. In the following sub-
sections we describe the protocol messages that SHALL be used between
the two end-points of the protection domain.
4.1. Transmission and acceptance of PSC control packets 4.1. Transmission and acceptance of PSC control packets
The PSC control packets should be transmitted over the recovery path The PSC control packets SHALL be transmitted over the protection path
only. This allows the transmission of the messages without affecting only. This allows the transmission of the messages without affecting
the normal traffic in the most prevalent case, i.e. the idle state. the normal data traffic in the most prevalent case, i.e. the Normal
In addition, limiting the transmission to a single path avoids state. In addition, limiting the transmission to a single path
possible conflicts and race conditions that could develop if the PSC avoids possible conflicts and race conditions that could develop if
messages were sent on both paths. the PSC messages were sent on both paths.
Any new PSC control packet must be transmitted immediately when a When the PSC information is changed due to a local input, three PSC
change in the transmitted status occurs. messages SHOULD be transmitted as quickly as possible, to allow for
rapid protection switching. This set of three rapid messages allows
for fast protection switching even if one or two of these packets are
lost or corrupted. When the PSC information changes due to a remote
message there is no need for the rapid transmission of three messages
with the following exception - When going from Wait-to-Restore state
to Normal state as a result of a remote NR message.
When the PSC information is changed, three PSC packets should be The frequency of the three rapid messages and the separate frequency
transmitted as quickly as possible, so that fast protection switching of the continual transmission SHOULD be configurable by the operator.
would be possible. Transmission of three rapid packets allows for For protection switching within 50ms, the default interval of the
fast protection switching even if one or two PSC packets are lost or first three PSC messages is RECOMMENDED to be no larger than 3.3ms.
corrupted. The frequency of the first three packets and the separate The continuous transmission interval is RECOMMENDED to be 5 seconds.
frequency of the continual transmission is configurable by the
operator. For protection switching within 50ms, the default interval
of the first three PSC signals should be no larger than 3.3ms. PSC
packets after the first three should be transmitted with an interval
of 5 seconds.
If no valid PSC specific information is received, the last valid If no valid PSC specific information is received, the last valid
received information remains applicable. In the event a signal fail received information remains applicable. In the event a signal fail
condition is detected on the recovery path, the received PSC specific condition is detected on the protection path, the received PSC
information should be evaluated. specific information should be evaluated.
4.2. Protocol format 4.2. Protocol format
The protocol messages SHALL be sent over the GACH 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, each message will be identified by the first field of the messages [to be assigned by IANA]. The actual message function SHALL
ACH payload as described below. PSC messages SHOULD support be identified by the Request field of the ACH payload as described
addressing by use of the method described in [RFC5586]. The below. The following figure shows the format for the complete PSC
following figure shows the format for the full PSC message. 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|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP PSC Channel Code | |0 0 0 1|Version| Reserved | Channel Type = MPLS-TP PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header | | ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ~ Optional TLVs ~
+ Addressing TLV + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : |Ver|Request|PT |R| Reserved | FPath | Path |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ PSC Control Packet ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of PSC packet with a GACH header Figure 2: Format of PSC packet with a G-ACh header
Where: Where:
o MPLS-TP PSC Channel Code is the GACH channel number assigned to o MPLS-TP PSC Channel Code is the G-ACh channel number assigned to
the PSC = TBD the PSC = TBD
o The ACH TLV Header is described in [RFC5586] o The ACH TLV Header is described in [RFC5586]
o The use of an Addressing TLV is for further study o The following subsections will describe the fields of the PSC
payload.
o Figure 3 shows the format of the PSC Control message that is the 4.2.1. PSC Ver field
payload for the PSC packet.
Editor's note: There is a suggestion that this format should be The Ver field identifies the version of the protocol. For this
aligned with the format used by G.8031/G.8131/Y.1731 in ITU. The version the value SHALL be 0.
argument being that this would make it easier to pass review from ITU
and allow easier transfer of technology.
The counter-argument is that the ITU format is based upon an attempt 4.2.2. PSC Request field
to find a common format for different functionality and therefore
involves different fields that are not necessary for the protection
switching. Defining a new dedicated format would make for a simpler
and more intuitive protocol. End of editor's note.
0 1 2 3 The PSC protocol SHALL support transmission of the following requests
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 between the two end-points of the protection domain:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|Request| PT| FPath | Path | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of the PSC control packet o (1110) Lockout of protection - indicates that the endpoint has
disabled the protection path as a result of an administrative
command. Both the FPath and Path fields SHOULD be set to 0.
Where: o (1101) Forced switch - indicates that the transmitting end-point
has switched traffic to the protection path as a result of an
administrative command. The Fpath field SHOULD indicate that the
working path is being blocked, and the Path field SHOULD indicate
that user data traffic is being transmitted on the protection
path.
o Ver: is the version of the protocol, for this version the value o (0110) Signal Fail - indicates that the transmitting end-point has
SHOULD be 0. identified a signal fail condition on either the working or
protection path. The Fpath field SHALL identify the path that is
reporting the failure condition, and the Path field SHALL indicate
where the data traffic is being transmitted.
o Request: this field indicates the specific PSC request that is o (0100) Manual switch - indicates that the transmitting end-point
being transmitted, the details are described in section 4.2.1 has switched traffic as a result of an administrative Manual
Switch command. The Fpath field SHALL indicate the path that is
the manual switch is being applied to and the Path field SHALL
indicate the path being utilized by the endpoint to transmit user
data traffic.
o PT: indicates the type of protection scheme currently supported, o (0011) Wait to restore - indicates that the transmitting endpoint
more details are given in section 4.2.2 is recovering from a failure condition of the working path and has
started the Wait-to-Restore timer. Fpath SHOULD be set to 0 and
ignored upon receipt. Path SHOULD indicate the working path that
is currently being protected.
o FPath: used to indicate the path that is reporting a failure o (0010) Do not revert - indicates that the transmitting endpoint is
condition, the possible values are described in section 4.2.3 recovering from a failure/blocked condition, but due to the local
settings is requesting that the protection domain continues to
transmit data over the protection path, rather than revert to the
Normal state. Fpath SHOULD be set to 0 and ignored upon receipt.
Path SHOULD indicate the working path that is currently being
protected.
o Path: used to indicate the currently active path, possible values o (0000) No request - indicates that the transmitting end-point has
are described in section 4.2.4 nothing to report, Fpath and Path fields SHOULD be set to
according to the state of the end-point.
o Reserved: field is reserved for possible future use. These bits 4.2.3. Protection Type (PT)
MUST be set to zero on transmission, and ignored upon reception.
4.2.1. PSC Requests The PT field indicates the currently configured protection
architecture type, this SHOULD be validated to be consistent for both
ends of the protection domain. If an inconsistency is detected then
an alarm SHALL be sent to the management system. The following are
the possible values:
The Protection State Coordination (PSC) protocol SHALL support the o 11: bidirectional switching using a permanent bridge
following request types, in order of priority from highest to lowest:
o (1111) Clear o 10: bidirectional switching using a selector bridge
o (1110) Lockout protection o 01: unidirectional switching using a permanent bridge
o (1101) Forced switch o 00: unidirectional switching using a selector bridge
o (0110) Signal fault As described in the introduction (section 1.1) a 1+1 protection
architecture is characterized by the use of a permanent bridge at the
source node, whereas the 1:1 and 1:n protection architectures are
characterized by the use of a selector bridge at the source node.
o (0101) Signal degrade 4.2.4. Revertive (R) field
o (0100) Manual switch This field indicates that the transmitting endpoint is configured to
work in revertive mode. If there is an inconsistency between the two
endpoints, i.e. one end-point is configured for revertive action and
the second end-point is in non-revertive mode, then the management
system SHOULD be notified. Possible values are:
o (0011) Wait to restore o 0 - non-revertive mode
o (0010) Do not revert (DNR)
o (0000) No request o 1 - revertive mode
See section 4.3 for a description of the operation of the different 4.2.5. Fault path (FPath) field
requests.
4.2.2. Protection Type (PT) The Fpath field indicates which path (i.e. working or protection) is
identified to be in a fault condition or affected by an
administrative command. The following are the possible values:
The PT field indicates the currently configured protection o 0: indicates that the anomaly condition is on the protection path
architecture type, this should be validated to be consistent for both
ends of the protected domain. If an inconsistency is detected then
an alarm should be raised. The following are the possible values:
o 11: 1+1 bidirectional switching o 1: indicates that the anomaly condition is on the working path
o 2-255: for future extensions
o 10: 1:1 bidirectional switching 4.2.6. Data path (Path) field
o 01: 1+1 unidirectional switching The Path field indicates which data is being transmitted on the
protection path. Under normal conditions, the protection path
(especially in 1:1 or 1:n architecture) does not need to carry any
user data traffic. If there is a failure/degrade condition on one of
the working paths, then that working path's data traffic will be
transmitted over the protection path. The following are the possible
values:
o 00: 1:1 unidirectional switching 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+1 architecture).
4.2.3. Path fault identifier (FPath) o 1: indicates that the protection path is transmitting user traffic
replacing the use of the working path.
The Fpath field of the PSC control SHALL be used only in a Signal o 2-255: for future extensions
fault (0110) or Signal degrade (0101) control packet. Its value
indicates on which path the signal anomaly was detected. The
following are the possible values:
o 0: indicates that the fault condition is on the Recovery path 4.3. Principles of Operation
o 1: indicates that the fault condition is on the Working path In all of the following sub-sections, assume a protection domain
between LER-A and LER-Z, using paths W (working) and P (protection)
as shown in figure 3.
o 2-255: for future extensions +-----+ //=======================\\ +-----+
|LER-A|// Working Path \\|LER-Z|
| /| |\ |
| ?< | | >? |
| \|\\ Protection Path //|/ |
+-----+ \\=======================// +-----+
4.2.4. Active path indicator (Path) |--------Protection Domain--------|
The Path field of the PSC control SHALL be used to indicate which Figure 3: Protection domain
path the source MEP is currently using for data transmission. The
MEP should compare the value of this bit with the path that is
locally selected for data transmission to verify that there is no
inconsistency between the two end-points of the protected domain. If
an inconsistency is detected then an alarm should be raised. The
following are the possible values:
o 0: indicates that normal traffic is being transmitted on the 4.3.1. Basic operation
Working path.
o 1: indicates the Recovery path is being used to transmit the The basic operation of the coordination protocol is to allow the end-
normal traffic from the Working path. points to notify their peer of the status that is known to that end-
point. The parameters that are notified between the end-points - the
local condition of the protection domain, the blocked path (if there
is a blockage within the protection domain), and the current usage of
the protection path. It should be noted that the messages exchanged
between the two end-points may not be the same at a given point in
time, although the states of the end-points are coordinated. In
particular it should be noted that a remote message MAY not cause the
end-point to change the Request field that is being transmitted while
it does affect the Path field (see details in the following
subsections).
o 2-255: for future extensions The protocol is a single-phase protocol, although it includes a
possibility to extend the protocol for multiple-phased operation.
Single-phase implies that each end-point notifies its peer of a
change in the operation (switching to or from the protection path)
and makes the switch without waiting for acknowledgement.
4.3. Principles of Operation The following subsections will identify the messages that are
transmitted by the end-point in different scenarios. The messages
are described as REQ(FP, P) - where REQ is the value of the Request
field, FP is the value of the Fpath field, and P is the value of the
Path field. All examples assume a protection domain between LER-A
and LER-Z with a single working path and single protection path (as
shown in figure 3).
In all of the following sub-sections, assume a protected domain 4.3.2. Priority of inputs
between LSR-A and LSR-Z, using paths W (working) and R (recovery) as
shown in figure 4.
+-----+ //=======================\\ +-----+ As noted above (in section 3.1.1) the PSC Control Process accepts
|LSR-A|// Working Path \\|LSR-Z| input from five local input sources. There is a definition of
| /| |\ | priority between the different inputs that may be triggered locally.
| ?< | | >? | The list of local requests in order of priority are (from highest to
| \|\\ Recovery Path //|/ | lowest priority):
+-----+ \\=======================// +-----+
|--------Protected Domain---------| 1. Clear (Operator command)
Figure 4: Protected domain 2. Lockout of protection (Operator command)
4.3.1. PSC States 3. Signal Fail on protection (OAM/Control Plane/Server Indication)
4.3.1.1. Normal State 4. Forced switch (Operator command)
When the protected domain has no special condition in effect, the 5. Signal Fail on working (OAM/Control Plane/Server Indication)
ingress LSR SHOULD forward the user data along the working path, and,
6. Clear Signal Fail (OAM/Control Plane/Server Indication)
7. Manual switch (Operator command)
8. WTR expires (WTR Timer)
The determination of whether a remote message is accepted or ignored
is a function of the current state of the local LER and the current
local request (see section 3.1.3). Part of this consideration will
be included in the following subsections describing the operation in
the different states.
4.3.3. Operation of PSC States
4.3.3.1. Normal State
When the protection domain has no special condition in effect, the
ingress LER SHOULD forward the user data along the working path, and,
in the case of 1+1 protection, the Permanent Bridge will bridge the in the case of 1+1 protection, the Permanent Bridge will bridge the
data to the recovery path as well. The receiving LSR SHOULD read the data to the recovery path as well. The receiving LER SHOULD read the
data from the working path. data from the working path.
The ingress LSR MAY transmit a No Request PSC packet with the Path When the end-point is in Normal State it SHOULD transmit a NR(0,0)
field set to 0 indicating that the normal data traffic should be read message - indicating - Nothing to report and data traffic is being
from the working path. transmitted on the working path.
4.3.1.2. Protecting State When the LER (assume LER-A) is in Normal State the following
transitions are relevant in reaction to a local input (new state
SHOULD be marked as local):
When the protection mechanism has been triggered and the protected o A local Lockout of protection input SHALL cause the LER to go into
domain has performed a protection switch, the domain is in the Unavailable State and begin transmission of a LO(0,0) message to
protecting state. In this state the normal data traffic is the far-end LER (LER-Z).
transmitted and received on the recovery path.
If the protection domain is currently in a protecting state, then the o A local Forced switch input SHALL cause the LER to go into
LSRs SHOULD NOT accept a Manual Switch request. Protecting administrative state and begin transmission of a
FS(1,1) message to the far-end LER (LER-Z).
If the protection domain is currently in a protecting state, and a o A local Signal Fail indication on the protection path SHALL cause
Forced Switch is requested then the normal traffic SHALL continue to the LER to go into Unavailable state and begin transmission of a
be transmitted on the recovery path even if the original protection SF(0,0) message to the far-end LER (LER-Z).
trigger is cleared, and the Forced Switch condition will be signalled
by the PSC messages.
4.3.1.3. Unavailable State o A local Signal Fail indication on the working path SHALL cause the
LER to go into Protecting failure state and begin transmission of
a SF(1,1) message to the far-end LER (LER-Z).
When the recovery path is unavailable - either as a result of a o A local Manual switch input SHALL cause the LER to go into
Lockout operator command (see section 4.3.3), or as a result of a SF Protecting administrative state and begin transmission of a
or SD detected on the recovery path (see section 4.3.4) - then the MS(1,1) message to the far-end LER (LER-Z).
protection domain is in the unavailable state. In this state, the
normal traffic is transmitted and received on the working path.
While in unavailable state any event that would trigger a protection o All other local inputs SHOULD be ignored.
switching SHOULD be ignored with the following exception - If a
Signal Degrade request is received, then protection switching will be In Normal state, remote messages would cause the following reaction
activated only if the recovery path can guarantee a better signal from the LER (new state SHOULD be marked as remote):
than the working path.
o A remote Lockout of protection message SHALL cause the LER (LER-A)
to go into Unavailable state, while continuing to transmit the
NR(0,0) message.
o A remote Forced switch message SHALL cause the LER (LER-A) to go
into Protecting administrative state, and transmit a NR(0,1)
message.
o A remote Signal Fail message that indicates that the failure is on
the protection path SHALL cause the LER (LER-A) to go into
Unavailable state, while continuing to transmit the NR(0,0)
message.
o A remote Signal Fail message that indicates that the failure is on
the working path SHALL cause the LER (LER-A) to go into Protecting
failure state, and transmit a NR(0,1) message.
o A remote Manual switch message SHALL cause the LER (LER-A) to go
into Protecting administrative state, and transmit a NR(0,1)
message.
o All other remote messages SHOULD be ignored.
4.3.3.2. Unavailable State
When the protection path is unavailable - either as a result of a
Lockout operator command, or as a result of a SF or SD detected on
the protection path - then the protection domain is in the
unavailable state. In this state, the data traffic is transmitted
and received on the working path.
The protection domain will exit the unavailable state and revert to The protection domain will exit the unavailable state and revert to
the normal state when, either the operator clears the Lockout command the normal state when, either the operator clears the Lockout command
or the recovery path recovers from the signal fault or degraded or the protection path recovers from the signal fail or degraded
situation. Both ends will resume sending the PCS packets over the situation. Both ends will resume sending the PSC packets over the
recovery path, as a result of this recovery. protection path, as a result of this recovery.
4.3.2. Failure or Degraded condition (Working path) When in unavailable state the data traffic is being transmitted on
the working path and is not protected. In many cases the remote
messages will not be received (since the protection path is blocked)
and the main effect will be as a result of local inputs.
If one of the LSRs (for example, LSR-A) detects a failure condition When the LER (assume LER-A) is in Unavailable State the following
or a serious degradation condition on the working path that warrants transitions are relevant in reaction to a local input (new state
invoking protection switching, then it SHOULD take the following SHOULD be marked as local):
actions:
o (For 1:1 protection) Switch all traffic for LSR-Z to the recovery o A local Clear input SHOULD be ignored if the LER is in remote
path only. Unavailable state. If in local Unavailable state due to a Lockout
command, then the input SHALL cause the LER to go to Normal state
and begin transmitting a NR(0,0) message.
o Transmit a PCS control packet, using GACH, with the appropriate o A local Lockout of protection input SHALL cause the LER to remain
Request code (either Signal fault or Signal degrade), the Fpath in Unavailable State and begin transmission of a LO(0,0) message
set to 1, to indicate that the fault/degrade was detected on the to the far-end LER (LER-Z).
working path, and the Path set to 1, indicating that normal
traffic is now being transmitted on the recovery path.
o Verify that LSR-Z replies with a PCS control packet indicating o A local Clear SF indication SHOULD be ignored if the LER is in
that it has switched to the recovery path. If this is not remote Unavailable state. If in local Unavailable state due to a
received after 2 PSC cycles then send an alarm to the management Signal Fail on the protection path and the Clear SF indicates that
system. the protection path is now cleared, then the input SHALL cause the
LER to go to Normal state and begin transmitting a NR(0,0)
message.
When the far-end LSR (in this example LSR-Z) receives the PCS packet o A local Forced switch input when in Unavailable state due to a
informing it that other LSR (LSR-A) has switched, it SHOULD perform local or remote failure condition on the protection path SHALL
the following actions: cause the LER to go into Protecting administrative state and begin
transmission of a FS(1,1) message. When in Unavailable state due
to local Lockout input - this message SHOULD be filtered out by
the Local Request Logic. If Unavailable due to remote Lockout
input, then this message SHOULD be ignored by the PSC Process
Logic.
o Check priority of the request o A local Signal Fail indication on the protection path SHALL cause
the LER to remain in Unavailable state and begin transmission of a
SF(0,0) message.
o Switch all traffic addressed to LSR-A to the recovery path only o All other local inputs SHOULD be ignored.
(for 1:1 protection).
o Begin transmission of a PCS control packet, using GACH, with the If remote messages are being received over the protection path then
appropriate Request code (either Signal fault or Signal degrade), they would have the following affect:
the Fpath set to 1, to indicate that the fault/degrade was
detected on the working path, and the Path set to 1, indicating
that traffic is now being transmitted on the recovery path.
4.3.3. Lockout of Protection o A remote Lockout of protection message SHALL cause the LER to
remain in Unavailable state, and continue transmission of the
current message (either NR(0,0) or LO(0,0))
If one of the LSRs (for example, LSR-A) receives a management command o A remote Signal Fail message that indicates that the failure is on
indicating that the protection is disabled, then it SHOULD indicate the protection path SHALL cause the LER to remain in Unavailable
this to the far-end LSR (LSR-Z in this example) that it is not state and continue transmission of the current message (either
possible to use the recovery path. The following actions MUST be NR(0,0) or SF(0,0)).
taken:
o Transmit a PCS control packet, using GACH, with the Request code o A remote No Report, when the LER is remote Unavailable state SHALL
set to Lockout of protection (1110), the Fpath may be set to 0, cause the LER to go into Normal state and begin transmission of a
and the Path set to 0. NR(0,0) message. When in local Unavailable state, the message
SHALL be ignored.
o All normal traffic packets should be transmitted on the working o All other remote messages SHOULD be ignored.
path only.
o Verify that the far-end LSR (for example LSR-Z) is forwarding the 4.3.3.3. Protecting administrative state
data packets on the working path. Raise alarm in case of
mismatch.
o The PSC control logic should go into Unavailable state. In the protecting state the user data traffic is being transported on
the protection path, while the working path is blocked due to an
operator command, i.e. Forced Switch or Manual Switch.
When the far-end LSR (in this example LSR-Z) receives the PCS packet The following describe the reaction to local input:
informing it that other LSR (LSR-A) has switched, it SHOULD perform
the following actions:
o Check priority of request o A local Clear SHOULD be ignored if in remote Protecting state. If
in local Protecting administrative state then this input SHALL
cause the LER to go into Normal state and begin transmitting a
NR(0,0) message.
o Switch all normal traffic addressed to LSR-A to the working path o A local Lockout of protection input SHALL cause the LER to go into
only. Unavailable state and begin transmission of a LO(0,0) message.
o The PSC control logic should go into Unavailable status. o A local Forced switch input SHALL cause the LER to remain in
Protecting administrative state and begin transmission of a
FS(1,1) message.
o Begin transmission of a PCS control packet, using GACH, with the o A local Signal Fail indication on the protection path SHALL cause
appropriate Request code (Lockout of protection), the Fpath set to the LER to go into Unavailable state and begin transmission of a
0, and the Path set to 0, indicating that traffic is now being SF(0,0) message.
transmitted on the working path only.
4.3.4. Failure or Degraded condition (Recovery path) o A local Signal Fail indication on the working path SHOULD be
filtered by the Local Request Logic if the protecting state was
entered due to an active local Forced switch operator command. If
the protecting state is due to a remote Forced switch message,
then this local indication SHOULD be filtered by the PSC Process
Logic. If the current state is due to a (local or remote) Manual
switch operator command, it shall cause the LER to go into
Protecting failure state and begin transmitting a SF(1,1) message.
If one of the LSRs (for example, LSR-A) detects a failure condition o A local Manual switch input SHALL be filtered by the Local Request
or a serious degradation condition on the recovery path, then it Logic if there is an active local Forced switch. If the
SHOULD take the following actions: protecting state is due to a remote Forced switch command, then
this local indication SHOULD be filtered by the PSC Process Logic.
If the current state is due to a (local or remote) Manual switch
operator command, it shall cause the LER to remain in Protecting
administrative state and begin transmission of a MS(1,1) message.
o Begin transmission of a PCS control packet with the appropriate o All other local inputs SHOULD be ignored.
Request code (either Signal fault or Signal degrade), the Fpath
set to 0, to indicate that the fault/degrade was detected on the
recovery path, and the Path set to 0, indicating that traffic is
now being forwarded on the working path. Note that this will
actually reach the far-end if this is a unidirectional fault or
recovery path is possibly in a degraded situation.
o The PSC control logic should go into Unavailable state. While in Protecting administrative state the LER may receive and
react as follows to remote PSC messages:
o All traffic MUST be transmitted on the working path for the o A remote Lockout of protection message SHALL cause the LER to go
duration of the SF/SD condition. into Unavailable state and begin transmitting a NR(0,0) message.
When the far-end LSR (in this example LSR-Z) receives the PCS packet It should be noted that this automatically cancels the current
informing it that other LSR (LSR-A) has become Unavailable, it SHOULD Forced switch or Manual switch command and data traffic is
perform the following actions: reverted to the working path.
o Transmit all traffic on the working path for the duration of the o A remote Forced switch message SHOULD be ignored by the PSC
SF/SD condition Process Logic if there is an active local Forced switch operator
command. If the Protecting state is due to a remote Forced switch
message then the LER SHALL remain in Protecting administrative
state and continue transmission of the last message. If the
Protecting state is due to either a local or remote Manual switch
then the LER SHALL remain in Protecting administrative state
(updating the state information with the proper relevant
information) and begin transmitting a NR(0,1) message.
o The PSC Control logic should go into Unavailable state. o A remote Signal Fail message indicating a failure on the
protection path SHALL cause the LER to go into Unavailable state
and begin transmitting a NR(0,0) message. It should be noted that
this automatically cancels the current Forced switch or Manual
switch command and data traffic is reverted to the working path.
4.3.5. Operator Controlled Switching o A remote Signal Fail message indicating a failure on the working
path SHALL be ignored if there is an active local Forced switch
command. If the Protecting state is due to a local or remote
Manual switch then the LER SHALL go to Protecting failure state
and begin transmitting a NR(0,1) message.
If the management system indicated to one of the LSRs (for example o A remote Manual switch message SHALL be ignored by the PSC Process
LSR-A) that a switch is necessary, e.g. either a Forced Switch or a Logic if in Protecting state due to a local or remote Forced
Manual Switch, then the LSR SHOULD switch the traffic to the recovery switch. If in Protecting state due to a remote Manual switch then
path and perform the following actions: the LER SHALL remain in Protecting administrative state and
continue transmitting the current message. If in Protecting state
due to an active local Manual switch then the LER SHALL remain in
Protecting administrative state and continue transmission of the
MS(1,1) message.
o Switch all data traffic to the recovery path only. o A remote DNR(0,0) message SHALL be ignored if in Protecting state
due to a local input. If in Protecting state due to a remote
message then the LER SHALL go to Do-not-revert state and begin
transmitting a NR(0,0) message.
o Transmit a PCS control packet, using GACH, with the appropriate o A remote NR(0,0) message SHALL be ignored if in Protecting state
Request code (either Manual switch or Forced switch), the Fpath due to a local input. If in Protecting state due to a remote
may be set to 1, to indicate that there is an event that affects message then the LER SHALL go to Normal state and begin
the working path, and the Path set to 1, indicating that traffic transmitting a NR(0,0) message.
is now being forwarded on the recovery path.
o Verify that LSR-Z replies with a PCS control packet indicating o All other remote messages SHALL be ignored.
that it has switched to the recovery path. If this is not
received after 2 PSC cycles then send an alarm to the management
system.
When the far-end LSR (in this example LSR-Z) receives the PCS packet 4.3.3.4. Protecting failure state
informing it that other LSR (LSR-A) has switched, it SHOULD perform
the following actions:
o Check priority of the request When the protection mechanism has been triggered and the protection
domain has performed a protection switch, the domain is in the
protecting failure state. In this state the normal data traffic is
transmitted and received on the protection path.
o Switch all normal traffic addressed to LSR-A to the recovery path The following describe the reaction to local input:
only.
o Begin transmission of a PCS control packet, using GACH, with the o A local Clear SF SHOULD be ignored if in remote Protecting state.
appropriate Request code (either Manual switch of Forced switch), If the Clear SF indicates that the protection path is now cleared
the Fpath may be set to 1, to indicate that there is an event that (but working is still in SF condition) then the indicateion SHOULD
affects the working path, and the Path set to 1, indicating that be ignored. If in local Protecting failure state and the LER is
traffic is now being forwarded on the recovery path. configured for revertive behavior then this input SHALL cause the
LER to go into Wait-to-restore state, start the WTR timer, and
begin transmitting a WTR(0,1) message. If in local Protecting
failure state and the LER is configured for non-revertive behavior
then this input SHALL cause the LER to go into Do-not-revert state
and begin transmitting a DNR(0,1) message.
4.3.5.1. Clearing operator commands o A local Lockout of protection input SHALL cause the LER to go into
Unavailable state and begin transmission of a LO(0,0) message.
The operator may clear the switching condition by issuing a Clear o A local Forced switch input SHALL cause the LER to go into
request. This command will cause immediate recovery from the switch Protecting administrative state and begin transmission of a
that was initiated by any of the previous operator commands, i.e. FS(1,1) message.
Forced Switch or Manual Switch. In addition, a Clear command after a
Lockout Protection command should clear the Unavailable state and
return the protection domain to the normal state.
If the Clear request is issued in the absence of a Manual Switch, o A local Signal Fail indication on the protection path SHALL cause
Forced Switch, or Lockout protection, then it SHALL be ignored. In the LER to go into Unavailable state and begin transmission of a
the presence of any of these commands, the Clear request SHALL clear SF(0,0) message.
the state affected by the operator command.
4.3.6. Recovery from switching o A local Signal Fail indication on the working path SHALL cause the
LER to remain in Protecting failure state and begin transmitting a
SF(1,1) message.
When the condition that triggered the protection switching clears, o All other local inputs SHOULD be ignored.
e.g. the cause of the failure condition has been corrected, or the
operator clears a Manual Switch, then the protection domain SHOULD
follow the following procedures:
o If the network is configured for non-revertive behaviour, then the While in Protecting failure state the LER may receive and react as
two LSRs SHOULD transmit DNR (Request code 0010) messages. follows to remote PSC messages:
o If the network is recovering from an operator switching command o A remote Lockout of protection message SHALL cause the LER to go
(in revertive mode), then both LSRs SHOULD return to using the into Unavailable state and if in protecting failure state due to a
working transport path and transmit No request (Request code 0000) local SF condition begin transmitting a SF(1,0) message, otherwise
messages. transmit a NR(0,0) message. It should be noted that this may
cause loss of user data since the working path is still in a
failure condition.
o If the network is recovering from a failure or degraded condition o A remote Forced switch message SHALL cause the LER go into
(in revertive mode), then the LSR that detects this recovery SHALL Protecting administrative state and if in protecting failure state
activate a local Wait-to-restore (WTR) timer (see section 4.3.6.1) due to a local SF condition begin transmitting the SF(1,1)
to verify that there is not an intermittent failure. After the message, otherwise begin transmitting NR(0,0).
WTR expires, the LSR SHOULD return to using the working transport
path and transmit No request (Request code 0000) messages.
4.3.6.1. Wait-to-restore timer o A remote Signal Fail message indicating a failure on the
protection path SHALL cause the LER to go into Unavailable state
and if in protecting failure state due to a local SF condition
begin transmitting a SF(1,0) message, otherwise begin transmitting
NR(0,0) message. It should be noted that this may cause loss of
user data since the working path is still in a failure condition.
In revertive mode, in order to prevent frequent activation of o If in Protecting state due to a remote message, a remote Wait-to-
protection switching due to an intermittent defect, the working Restore message SHOULD cause the LER to go into Wait-to-Restore
transport path must become stable and fault-free before reverting to state and continue transmission of the current message.
the normal condition. In order to verify that this is the case a
fixed period of time must elapse before the normal traffic uses the
working transport path. This period, called the Wait-to-restore
(WTR) period, should be configurable by the operator in 1-minute
intervals within the range 1-12 minutes. The default value is 5
minutes.
During this period, if a failure condition is detected on the working o If in Protecting state due to a remote message, a remote Do-not-
transport path, then the WTR timer is cleared and the normal traffic revert message SHOULD cause the LER to go into Do-not-revert state
SHALL continue to be transported over the recovery transport path. and continue transmission of the current message.
If the WTR timer expires without being pre-empted by a failure, then
the traffic SHOULD be returned to use the working transport path (as o All other remote messages SHALL be ignored.
above).
4.3.3.5. Wait-to-restore state
The Wait-to-Restore state is used by the PSC protocol to delay
reverting to the normal state, when recovering from a failure
condition on the working path, for the period of the WTR timer to
allow the recovering failure to stabilize. While in the Wait-to-
Restore state the data traffic SHALL continue to be transmitted on
the protection path. The natural transition from the Wait-to-Restore
state to Normal state will occur when the WTR timer expires.
When in Wait-to-Restore state the following describe the reaction to
local inputs:
o A local Lockout of protection command SHALL cause the LER to Stop
the WTR timer, go into Unavailable state, and begin transmitting a
LO(0,0) message.
o A local Forced switch command SHALL cause the LER to Stop the WTR
timer, go into Protecting administrative state, and begin
transmission of a FS(1,1) message.
o A local Signal Fail indication on the protection path SHALL cause
the LER to Stop the WTR timer, go into Unavailable state, and
begin transmission of a SF(0,0) message.
o A local Signal Fail indication on the working path SHALL cause the
LER to Stop the WTR timer, go into Protecting failure state, and
begin transmission of a SF(1,1) message.
o A local Manual switch input SHALL cause the LER to Stop the WTR
timer, go into Protecting administrative state and begin
transmission of a MS(1,1) message.
o A local WTR expires input SHALL cause the LER to remain in Wait-
to-Restore state and begin transmitting a NR(0,1) message.
o All other local inputs SHOULD be ignored.
When in Wait-to-Restore state the following describe the reaction to
remote messages:
o A remote Lockout of protection message SHALL cause the LER to Stop
the WTR timer, go into Unavailable state, and begin transmitting a
NR(0,0) message.
o A remote Forced switch message SHALL cause the LER to Stop the WTR
timer, go into Protecting administrative state, and begin
transmission of a NR(0,1) message.
o A remote Signal Fail message for the protection path SHALL cause
the LER to Stop the WTR timer, go into Unavailable state, and
begin transmission of a NR(0,0) message.
o A remote Signal Fail message for the working path SHALL cause the
LER to Stop the WTR timer, go into Protecting failure state, and
begin transmission of a NR(0,1) message.
o A remote Manual switch message SHALL cause the LER to Stop the WTR
timer, go into Protecting administrative state and begin
transmission of a NR(0,1) message.
o If the WTR timer is running then a remote NR message SHALL be
ignored. If the WTR timer is no longer running then a remote NR
message SHALL cause the LER to go into Normal state and begin
transmitting a NR(0,0) message.
o All other remote messages SHOULD be ignored.
4.3.3.6. Do-not-revert state
Do-not-revert state is a continuation of the protecting state when
the protection domain is configured for non-revertive behavior.
While in Do-not-revert state data traffic continues to be transmitted
on the protection path until the administrator sends a command to
revert to the Normal state. It should be noted that there is a
fundemental difference between this state and Normal - whereas Forced
Switch in Normal state actually causes a switch in the transport path
used, in Do-not-revert state the Forced switch just switches the
state but the traffic would continue to be transmitted on the
protection path! The command to revert back to Normal state could
either be a Lockout of protection (followed be a Clear command), a
Clear command, or a new form of the Manual switch command [note: This
would also require some kind of agreement, although it seems to have
been adopted by ITU-T in G.8031 for Ethernet]. The following
description of operation is based on the Lockout/Clear option
mentioned!
When in Do-not-revert state the following describe the reaction to
local input:
o A local Lockout of protection command SHALL cause the LER to go
into Unavailable state and begin transmitting a LO(0,0) message.
o A local Forced switch command SHALL cause the LER to go into
Protecting administrative state and begin transmission of a
FS(1,1) message.
o A local Signal Fail indication on the protection path SHALL cause
the LER to go into Unavailable state and begin transmission of a
SF(0,0) message.
o A local Signal Fail indication on the working path SHALL cause the
LER to go into Protecting failure state and begin transmission of
a SF(1,1) message.
o A local Manual switch input SHALL cause the LER to go into
Protecting administrative state and begin transmission of a
MS(1,1) message.
o All other local inputs SHOULD be ignored.
When in Do-not-revert state the following describe the reaction to
remote messages:
o A remote Lockout of protection message SHALL cause the LER to go
into Unavailable state and begin transmitting a NR(0,0) message.
o A remote Forced switch message SHALL cause the LER to go into
Protecting administrative state and begin transmission of a
NR(0,1) message.
o A remote Signal Fail message for the protection path SHALL cause
the LER to go into Unavailable state and begin transmission of a
NR(0,0) message.
o A remote Signal Fail message for the working path SHALL cause the
LER to go into Protecting failure state, and begin transmission of
a NR(0,1) message.
o A remote Manual switch message SHALL cause the LER to go into
Protecting administrative state and begin transmission of a
NR(0,1) message.
o All other remote messages SHOULD be ignored.
5. IANA Considerations 5. IANA Considerations
To be added in future version. To be added in future version.
6. Security Considerations 6. Security Considerations
To be added in future version. To be added in future version.
7. Acknowledgements 7. Acknowledgements
skipping to change at page 19, line 4 skipping to change at page 28, line 35
To be added in future version. To be added in future version.
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. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 8.2. Informative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Jan 2001. 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 [RFC3985] Bryant, S. and P. Pate, "Pseudowire Emulation Edge-to-Edge
(PWE3) Architecture", RFC 3985, March 2005. (PWE3) Architecture", RFC 3985, March 2005.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007. Pseudowires", RFC 5085, December 2007.
[TPFwk] Bocci, M., Bryant, S., and L. Levrau, "A Framework for [TPFwk] Bocci, M., Bryant, S., and L. Levrau, "A Framework for
MPLS in Transport Networks", MPLS in Transport Networks",
ID draft-ietf-mpls-tp-framework-06.txt, July 2009. ID draft-ietf-mpls-tp-framework-06.txt, July 2009.
skipping to change at page 20, line 13 skipping to change at page 30, line 13
(GMPLS) Architecture", RFC 3945, Oct 2004. (GMPLS) Architecture", RFC 3945, Oct 2004.
Authors' Addresses Authors' Addresses
Stewart Bryant (editor) Stewart Bryant (editor)
Cisco Cisco
United Kingdom United Kingdom
Email: stbryant@cisco.com Email: stbryant@cisco.com
Eric Osborne
Cisco
United States
Email: eosborne@cisco.com
Nurit Sprecher (editor) Nurit Sprecher (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
Email: nurit.sprecher@nsn.com Email: nurit.sprecher@nsn.com
Huub van Helvoort (editor)
Huawei
Kolkgriend 38, 1356 BC Almere
Netherlands
Phone: +31 36 5316076
Email: hhelvoort@huawei.com
Annamaria Fulignoli (editor) Annamaria Fulignoli (editor)
Ericsson Ericsson
Italy Italy
Phone: Phone:
Email: annamaria.fulignoli@ericsson.com Email: annamaria.fulignoli@ericsson.com
Yaacov Weingarten Yaacov Weingarten
Nokia Siemens Networks Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B 3 Hanagar St. Neve Ne'eman B
 End of changes. 163 change blocks. 
492 lines changed or deleted 945 lines changed or added

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