Transcript MPLS + Transport Profile

MPLS Architectural Considerations
for a
Transport Profile
ITU-T - IETF Joint Working Team
Dave Ward, Malcolm Betts, ed.
March 25, 2008
1
What am I reading?

This presentation is a collection of assumptions, discussion points and
decisions that the combined group has had during the month of March, 2008

This represents the agreed upon starting point for the technical analysis of
the T-MPLS requirements from the ITU-T and the MPLS architecture

The output of the technical analysis will be the recommendation given to SG
15 on how to reply to the IETF’s liaison of July 2007
– IETF requested decision on whether the SDOs work together and extend MPLS
aka “option 1: or
– ITU-T choose another ethertype and rename T-MPLS to not include the MPLS
moniker aka “option 2”

The starting point of the analysis is to attempt to satisfy option 1 by showing
the high level architecture, any showstoppers and the design points that
would need to be addressed after the decision has been made to work
together.
2
Some Initial Participants and contributors of this set
 BT










Ben Niven-Jenkins, Tom Nadeau
Verizon
Andy Malis
ATT
Deborah Brungard
NTT
Shin Miyakawa
Comcast
John Leddy
Consultants
Loa Anderson, Adrian Farrel
Alcatel-Lucent
Vach Kompella, Marc Lasserre, Matthew Bocci, Italo Busi, Kevin Sparks, Sunil Khandekar,
Bruce Nelson, Martin Vigoureux, Vincenzo Sestito, Lieven Levrau
Cisco
Stewart Bryant, Luca Martini, George Swallow, Ali Sajassi, Simon Spraggs, Mark Townsley,
Joe Wojtal, Dave Ward
Ericsson
Dave Sinicrope
Juniper
Ross Callon, Kireeti Kompella, Rahul Aggarwal, Thomas Walsh
Nortel
Malcolm Betts, Stephen Shew
3
How is the effort organized?
1. In ITU-T
TMPLS ad hoc group
2. In IETF
MPLS interoperability design team
3. DMZ between the SDOs: Joint Working Team

Segmented into groups looking at
1. Forwarding
2. OAM
3. Protection
4. Control Plane
5. Network Management

Goal: Produce technical analysis that MPLS architecture can perform
functionality required by a transport profile.
Compare w/ ITU-T requirements and identify showstoppers
Find any obvious design points in MPLS architecture that may need extensions
4
MPLS + Transport Profile: What are the problems?
1
 Ability to statically configure LSPs and PWEs via the management plane i.e. not a
control (routing/signaling) plane
If a control plane is used for configuration of LSPs/PWEs failure and recovery of the control
plane must not impact forwarding plane (a la NSR/NSF)
 Transport OAM capabilities for LSP and PWE independent of configuration
mechanism (management plane or GMPLS or PWE control plane)
Full transport FCAPS - AIS, RDI, Connection verification (aka connectivity
supervision in G.806), loss of connectivity (aka continuity supervision in G.806),
support of MCC and SCC etc
Recent drafts to IETF demonstrate some issues
 Service Providers are requesting consistent OAM capabilities for multi-layered
network and interworking of the different layers/technologies (L2, PWE, LSP)
Include functionality of Y.1711 and Y.1731 into one architecture
5
MPLS + Transport Profile: What are the problems?
2
 Service Providers want to be able to offer MPLS LSPs and PWEs as a part of their transport
offerings and not just associated with higher level services (e.g. VPNs)
 Service Providers want LSPs/PWEs tandem connections to be able to be managed
at the different nested levels seamlessly (path, segment, multiple segments)
e.g. where a LSP/PWE crosses multiple administrations
 Service Providers want additional protection mechanisms or clear statements on how typical
“transport” protection switching designs can be met by the MPLS architecture
 Service Providers are requesting that OAM and traffic are congruent when traversing LAG or
ECMP
Or create LSP/PWEs that don’t traverse links with LAG/ECMP
6
MPLS - Transport Profile (TP) Requirements
Overview
 Meet functional requirements stated earlier by service providers
 No modification to MPLS forwarding architecture
 Solution Based on existing Pseudo-wire and LSP constructs
 Bi-directional congruent p2p LSPs
 No LSP path merge
 Multicast is point to multipoint NOT MP2MP
 OAM function responsible for monitoring the LSP/PWE
Initiates path recovery actions
 No requirement on IP for forwarding of OAM and data traffic
OOB management and signalling network running IP is outside scope
 Can be used with static provisioning systems or with control plane
With static provisioning, no dependency on routing or signaling (e.g. GMPLS or,
IGP, RSVP, BGP, LDP)
 Mechanisms and capabilities must be able to interoperate with existing MPLS control
plane and forwarding planes
7
MPLS-TP Major Solution Constructs
1. Definition of Label For yoU (LFU) and generic Associated Channel (PWE
ACH)
Allows OAM packets to be directed to an intermediated node on a LSP/PWE
Via label stacking for TCM MEP addressing
Via proper TTL setting for MIP addressing
Reuse Label 14 or define a new reserved label:
It is believed that Label 14 can be reused since the functionality defined at that codepoint
is supported in this architecture and it has not been deployed
2. Generic Channel Association function supports the FCAPS functions by
carrying OAM, APS, SCC/MCC etc. packets across the network
Use of PWE-3 Associated Channel to carry OAM packets
Generic Channel Association are codepoints from PWE ACH space but, not necessarily for
PWE purposes
ACH now present for OAM of all LSPs
8
High Level Architecture
9
MPLS-TP service spectrum
MPLS-TP solution must exist
over this spectrum
Connectionless
L3 only
Node/Link addressing
IP
Integrated control Plane
IP based / LDP or TE
LSP creation
Dynamic only
Label space
Dynamic label space
Load Balancing
ECMP only
Penultimate Hop Popping
PHP or non PHP
L2 signalling
Not required
Connection
Orientated
Multi-service
(Connectionless and Connection Orientated)
L1, L2, L3 Services
Pt-Pt, Pt-MPt, MPt-MPt
Node /Link addressing
IP
Control plane
IP based / LDP or TE
External NMS
LSP creation
Dynamic and static coexistence
Label Space
Split label space (static / dynamic)
Load Balancing
ECMP and Non ECMP support
Penultimate Hop Popping
PHP or non PHP
L2 Signalling
L1, L2 Services
Pt-Pt and Pt-MPt
Node /Link addressing
Multiple
Control plane
External NMS or GMPLS
LSP creation
Static and dynamic coexistence
Label Space
Static/dynamic label space
Load Balancing
Non ECMP support
Penultimate Hop Popping
non PHP
L2 Signalling
Static or Targeted LDP
Static or Targeted LDP
10
MPLS+TP Static Provisioning
Network Management System
Control Plane for PT2PT services
OAM
Edge
Forwarding
Tables
OAM
Forwarding
Tables
OAM
Forwarding
Tables
Edge
 Static provisioning and dynamic control plane
Anticipated that initial solutions will be based on static provisioning
Dynamic Control plane will be based on IETF solutions (G-MPLS, IP/MPLS)
 Control Plane responsible for:
End to End, Segment LSPs and PWE-3 application labels (programming the LFIB)
Determining and defining primary and backup paths
Configuring the OAM function along the path
Others : Defining the UNI etc
 OAM responsible for monitoring end to end and tandem paths and driving
switches between primary and backup paths
11
MPLS Transport Profile - Terminology
Emulated Service
Pseudo-wire
Multi-node PSN cloud
CE1
Attachment
Circuit
Attachment
Circuit
PE1
PW1
PE2
CE2
 Definition of an MPLS Transport Profile within IETF MPLS standards
Based on PWE-3 and LSP forwarding architecture
IETF MPLS architecture concepts
 Questions <<NEED to clarify the questions>>
How do we signal end to end : PWE-3 uses T-LDP to signal, exchange capabilities etc. Is this done entirely statically in
MPLS-TP and use internal OAM mechanisms to drive emulated service status. Need to define the connection pieces TBD by NMS/OAM subgroups
How are the devices identified and how does the NMS communicate with them outside DCC?
12
Multi segment Transport LSP example
Service Provider
Carrier 1
CE UNI
or
or
PE? NNI?
PE
P
Carrier 2
PE
NNI
PE
PE
UNI CE
or
or
NNI? PE?
MIP
MEP
MEP MEP
MEP
P
end to end OAM
MEP
MIP
MIP
MIP
per carrier OAM
MEP
•
•
•
•
MEP MEP
MIP
MEP MEP
MEP MEP
MIP
<<We need to discuss/review the differences between segment and tandem connection.
A segment is between MEPs It seems that they are used as synonymous in this slide.
OAM is end to end or per segment
The reference network scenario is not very clear.>>
The OAM in each segment is independent of any other segment
Recovery actions (Protection or restoration) are always between MEPs i.e. per segment or end to end
MEP: Maintenance End Point
MIP: Maintenance Intermediate Point
Note: A policing function (traffic management/shaping) is normally co located
with a MEP at a business boundary (UNI/NNI)
13
MEP/MIP architecture updated
Nested segment example
Carrier 1
Region 1
PE1
NNI
PE2
P
Region 2
PE3
INNI
PE4
P
PE5
NNI
PE6
end to end OAM
MIP
MIP
MIP
MIP
per carrier OAM
MEP
MIP
MIP
MEP
per region OAM
MEP
MIP
MEP MEP
MEP MEP
MIP
MEP
3 OAM levels
• end to end + 2 nested segment levels
• Nested segments are supported by Tandem Connection Monitoring (TCM) in SDH/OTN and Y.1731
14
Bi directional Paths
 External Static Provisioning
NMS responsible for configuration and ensuring bi-directional congruency
 If Dynamic Control Plane
GMPLS bidir RSVP for LSP path establishment
15
Node identification
 Will need to work through identification requirements
What about algorithmically derived label from the IP identifier
What IP identifier if we do not need IP to support forwarding or OAM?
Need to be able to rearrange the DCC without disturbing the forwarding/OAM?
NMS/OAM subteam to clarify that we have a Node Identification scheme
A node has multiple identifiers including the following:
 Management identifier – normally user friendly, based on the location
 MEP/MIP identifier
 DCC address - how do management messages reach this node
 Control plane identifiers - how are the various control components identified
 Forwarding plane identifier - end points and intermediate points - e.g. NNIs
These are design issues, not “show stoppers”.
16
OAM requirements
17
OAM Requirements
 Must be able to monitor Section, LSP, PWE-3
– Inter layer fault correlation
– failure indication propagation across multiple segments
 Packet loss rather than bit error based measurements/metrics for L2, LSP,
PWE-3
 Per segment <<(tandem connection?)>> and end-to-end
– Fault detection/isolation
– Recovery - protection switch
 A security architecture
18
What is segment recovery?
End to End Protection
A
B
C
D
E
F
Segment Protection
 End to End protection :
Fault detection and protection of the end to end pseudo-wire
Fault detection and protection of the end to end LSP
 Segment protection : Fault detection and protection of a segment (arbitrary
portion of an LSP, aka sub-network connection in G.805, or a segment of an
MS-PW, aka link connection in G.805) <<NOT CLEAR>>
 Segment could be provided by a hierarchical nested LSP, pseudo-wire
stitching function <<NOT CLEAR>> or a nested pseudo-wire function
No concept of nested pseudo-wires in IETF: Future if necessary
Already clear concept of nested LSPs
Initial solution will be based nested LSPs or pseudo-wire stitching <<NOT
CLEAR>>
19
OAM mechanisms
20
OAM hierarchy and mechanisms
A
B
L1/L2
C
D
L1/L2
L1/L2
E
L1/L2
F
L1/L2
Segment LSP
Midpoint
End to End LSP
Pseudo-wire
 L0/L1 : Loss of Light; G.709, SONET/SDH LoS, LoF, ES, SES (NOT DISCUSSED)
 L2 connectivity : Native L2 solution 802.1ag, Section OAM (e.g. non IP BFD)
<<Do we mean interworking between L2 service OAM and PW OAM or do we mean failure propagation
across layers?>> OAM of L2 and L2 interworking can be met by this architecture
 General LSPs : Generic Exception Label and Generic Associated Channel
Includes End to End and segment LSPs
Used to carry a variety of OAM, Mgmt, signalling protocols.
 Pseudo-wires : PWE-3 Associated Channel
21
LSP monitoring and alarming
Generic Exception Label and Generic Associated Channel Proposal
MAC Header L1
L2
LFU/BoS Generic ACH
Channel payload
000x | Ver | resv | Channel Type
 Assign a new label as a Label For youU (LFU)
Should this be the same as PWE-3 format?
From reserved label space:
Label 13 has been proposed, or
Label 14 because this has been allocated to Y.1711
Huub checking if it is deployed and can be reclaimed as Y.1711 arch fits into new construct
 Bottom of Stack is always set on LFU
In transport case this is always true
 Define a Generic Associated Channel function
Similar to the PWE-3 Associated Channel but doesn’t have to be associated with a pseudo-wire
Important the first nibble tells system not to load balance (so not 06 or 04)
 Generic Associated Channel is always under a Generic Exception Label if endpoint
 Generalised Associated Channel defines what packet function using “channel type” field
Examples : What OAM function is carried, DCC, etc
22
Pseudo-wire monitoring and alarming
PWE-3 Control Word and PW-Associated Channel : (RFC4385)
MAC Header L1
L2
PWL/BOS
Control Word
Payload
0000 | Specified by encapsulation
MAC Header L1
L2
PWL/BOS
PWE-3 ACH
Channel payload
0001 | Ver | resv | Channel Type
To be completed
23
Associated Channel
Level (ACH)
24
Associated Channel Level ACH: Overview
 Generalised mechanism for carrying management / OAM information
OAM capabilities :- Connectivity Checks (CC) and “Connectivity Verification” (CV)
Management information:- Management Communication Channel (MCC) and
Signalling Communication Channel (SCC)
APS information
Maybe even signalling information in non IP environments
 Associated Channel Capabilities
Multiple channels can exist between end points
Channel Type Indicates what protocol that is carried
To service an MPLS-TP network new channel types will need to be defined
 Management and Control Plane Information (MCC and SCC)
Via routed IP or Associated channel where IP is not configured
 Generic ACH contains a “channel Type” field
Need for a registry of protocols
This needs to be blocked for different functions
(IP-Free BFD is currently 7)
Do we define a vendor specific range?
25
Protocols within Associated Channel




CV : Connectivity Verification (misconfiguration detection)
PM: Performance of the path
AIS: Alarm suppression
CC : Continuity Check :- Is the path present (reuse vanilla BFD here)
Light weight
Role is as a CC protocol, it is not a CV protocol
Not a connectivity verification protocol
VCCV-BFD provides capabilities over pseudo-wire
 MCC
Management communication
 SCC
Control plane communications
 APS
Protection switching coordination
 Accounting/Billing information
 Security exchange
 Define new or use existing protocols for other functions
26
LSPs / OAM and Label
Stacks
27
Scope of next (label stack example) slides
 Slides focus on MEP to MEP monitoring
Detailed OAM packet walkthrough not yet covered in this slideset
Examples of potential PWE stacking at end of slideset
 MEP to MIP is not covered in this slide set
MEP sets the TTL of the MEP to MEP tunnel label so that it will
expire when the target MIP is reached
Detail packet walkthrough to be added
28
SS-PW, LSP and TCM-LSP OAM
A
Section OAM
B
LFU
ACh
TCM-LSP OAM
E2E (A to E)
LSP OAM
E2E (A to E)
PW OAM
C
LFU
ACh
BC
LFU
ACh
D
LFU
ACh
E
LFU
ACh
CD
LFU
ACh
AB
LFU
ACh
BC
BD
LFU
ACh
CD
BD
LFU
ACh
DE
LFU
ACh
AB
AE
ACh
BC
BD
AE
ACh
CD
BD
AE
ACh
DE
AE
ACh
AB
AE
CW
BC
BD
AE
CW
CD
BD
AE
CW
Non OAM Data Frames
LFU – Label For You (label 13|14)
ACh – Associated Channel
CW – Control Word
DE
AE
CW
TCM-LSPs
E2E LSP
SS-PW
29
LFU – Label For You (label 13|14)
ACh – Associated Channel
CW – Control Word
SS-PW over inter-domain LSP
Domain A
A
Section OAM
B
LFU
ACh
C
LFU
ACh
TCM-LSP OAM
AB
LFU
ACh
BC
LFU
ACh
E2E LSP OAM
AB
AC
LFU
ACh
BC
AC
LFU
ACh
AB
AC
AF
ACh
BC
AC
AF
ACh
AB
AC
AF
CW
BC
AC
AF
CW
E2E PW OAM
Non OAM Data Frames
D
LFU
ACh
Domain B
E
LFU
ACh
F
LFU
ACh
DE
LFU
ACh
EF
LFU
ACh
CD
LFU
ACh
DE
DF
LFU
ACh
EF
DF
LFU
ACh
CD
AF
ACh
DE
DF
AF
ACh
EF
DF
AF
ACh
CD
AF
CW
DE
DF
AF
CW
EF
DF
AF
CW
One hop TCMLSP OAM and
Section OAM
would
traditionally not
run concurrently
Manual
stiching in C
and D
TCM-LSPs
E2E LSP
SS-PW
30
OAM operations
31
Pseudo-wire OAM processing
A
B
C
D
E
F
Pseudo-wire
Pseudo-wire Label
Pseudo-wire Associated Channel
Pseudo-wire Channel Type
OAM function
MAC Header
PWE-3 L
PWE-3 ACH
OAM message
0001 | Ver | resv | Channel Type

Processed by the pseudo-wire function on the end-points
End point or Pseudo-wire stitch point

Verifies the operational status of the pseudo-wire

Working with the native attachment circuit technology
An inter-working function with the native attachment circuit OAM.
Transport and act upon native attachment circuit OAM technology
32
LSP End Point processing
A
B
C
D
E
F
Pseudo-wire
Generates OAM packet
Label For yoU
Generic Associated Channel
Generic Channel Type
OAM function
MAC Header
LFU
GE-ACH
OAM message
0001 | Ver | resv | Channel Type
 Label For yoU with Generic Channel Association
 Processed by the LSP end point
End to End LSP or Segment LSP

Verifies the operational status of the LSP
Many options including Non IP BFD is an option encapsulation of Y.1731 pdu
33
End to End LSP operations
LFIB:AB-BC
LFIB:CD-DE
LSP OAM
DE, PW-L
Primary Path
PW-L, AB
E
LFIB:BC-CD
A
YZ, PW-L
LFIB:XY-YZ
PW-L, AW
LFIB:AW-WX
Backup Path
LFIB:WX-XY
LSP OAM
 Path diversity is not part of the OAM process. It is the responsibility of the Control
Plane
 OAM function uses LFU with Generic Channel Association
 Pre-provisioned primary and backup paths
 LSP OAM running on primary and back-up paths
 OAM failure on backup path  Alert NMS
 OAM failure on primary path A and E updating LFIB to send and receive PW-L
traffic over backup path
34
Segment LSP operations
LFIB:CD-DE
D
LFIB:AB-BC
DE, PW-L
B
Segment Primary Path
E
LFIB:BC-CD
PW-L, AB
A
YZ, PW-L
LFIB:XY-YZ
PW-L, AW
Segment Backup Path
LFIB:AW-WX
LFIB:WX-XY
Primary Path
LSP OAM
 Path diversity is not part of the OAM process. It is the responsibility of the Control or
Management Plane
 OAM function uses LFU with Generic Channel Association
 Pre-provisioned segment primary and backup paths
 LSP OAM running on segment primary and back-up paths via LSP nesting
 OAM failure on backup path  Alert NMS
 OAM failure on primary path results in B and D updating LFIB to send traffic labelled for BD via
segment backup path
 End to End traffic labelled for BD now pushed onto segment backup path
35
Control Plane
36
Discussion/Decisions
 Transport profile should meet the requirements of the ASON
architecture
Decision: Use IETF - GMPLS protocol suite given it is used for ASON
 In none GMPLS cases need DCC for control
 ACH defines MCC
Can have as many channels and protocols as necessary and
therefore could support the ASON SCN
Must have policing for DCC/SCC
ISIS running in DCC for topology information
37
Protection and
Switchover
38
Discussion/Decision
 Nested LSPs (potentially PWEs) provide levels of
hierarchy to support per segment and path recovery
Must draw up PWE requirements
 Most of the time intermediate nodes to not process the
entire stack
This follows the model of GMPLS nesting and hierarchy exactly
Thus, if MPLS label stack not useful in this scenarios demonstrates
critical flaw in GMPLS architecture.
 Each segment can act independently
Multiple potential solutions including
Native IETF mechanisms
Carry G.8131/G.8132 pdus in an ACH
39
Discussion/Decisions.2
 We found that MPLS local repair, wrap and 1:1 detour
mechanisms met required functionality
Also provided optimized exit to prevent use of 2x bandwidth in transport
wrapping repair technologies
No need for Q9 mechanism as described there
Must add notion of DOWN and ADMINDOWN (e.g. standby bit)
Must add use case diagramming
40
Network Management
41
Discussion/Decisions
 We had discussion of network management requirements
 We must map ITU-T requirements into IETF architecture
IETF architecture is a layered one that has functionality in many different
processes, e.g.
Netflow/Ipfix = performance management
SNMP traps,informs, BFD and syslog = fault management
Netconf, SNMP = configuration management
IPsec, tls, eap, etc = security
Radius, TACACS, netflow, ippm, ppml = accounting
 IETF doesn’t have TMF or Corba definitions
 Need to be able to “stitch” a service where some segments use
IETF/netconf and others use ITU/TMF management interfaces
Need to draw IETF arch and map
42
Summary
To date we have found no showstoppers and everyone is in agreement
that we have a viable solution
It appears that the existing MPLS architecture can be extended to meet
the requirements of a Transport profile
The architecture allows for a single OAM technology for LSPs, PWE and
a deeply nested network
This architecture also appears to consume Y.1711 and those
requirements can be met
43
Some open discussion points
1. One way delay measurement techniques are just emerging
and very hard to solve. Decision: architecture can not
preclude it
No issues w/ 2-way delay
2. Appears we can’t use PHP in transport profile as you need
context of the “previous nexthop” to perform all OAM
Think if this is always the rule
3. Measurement of packet loss to support PMs and detection of
degraded performance is difficult
One approach is to encapsulate the appropriate Y.1731 pdus in an ACH
44
The End
45
ECMP considerations
MAC Header L1
L2
Control Word
PWE-L/BOS
Payload
0000 | Specified by encapsulation
MAC Header L1
L2
PWE-L/BOS
PWE-3 ACH
OAM message
0001 | Ver | resv | Channel Type
 Static Control Plane
Under the control of an external NMS therefore should not be an issue
Single discrete LSPs defined through static provisioning system
 Dynamic Control Plane environment
Routing protocols and LDP may set-up ECMP routes
Traffic Engineering can as well (auto-route)
 Recognised in IETF
This is a start of ECMP
considerations and a place
to discuss load-balance
labels
RFC 4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks : 0 or 1 in the first nibble of the payload
RFC 4385 PW3 Control Word for Use over an MPLS PSN : Defines “Generic PWE-3 control word” and “PW
Associated Channel” formats
 A consistent approach required for MPLS with a transport profile - Vach/Stewart to define LB Label
RFC 4928 implemented through use of control word and PWE-3 ACH
RFC 4385 for Control Word and PW associated Channel formats
46
LSPs / OAM and Label Stacks
Alternate approach using stacked PWs
Not currently supported
These are sketches of what the label stack would look like if we went forward with a stacked PWE
approach in the IETF
Just for reference
This work is NOT a requirement of MPLS-TP option 1|2 decision making
47
LFU – Label For You (label 13|14)
ACh – Associated Channel
CW – Control Word
TCM-MS-PW OAM
A
Section OAM
B
LFU
ACh
C
LFU
ACh
D
LFU
ACh
E
B and D are S-PEs
LFU
ACh
LFU a priori not
needed because
BD2 is bottom of
stack and Ach
has been
negotiated
LSP OAM not
shown here
TCM-PWE (B to D)
OAM
E2E (A to E)
PW OAM
Non OAM Data Frames
AB
AB
ACh
AB
AB
CW
BC
BD2
ACh
CD
BD2
ACh
BC
BD2
BD
ACh
CD
BD2
BD
ACh
BC
BD2
BD
CW
CD
BD2
BD
CW
DE
DE
ACh
DE
DE
CW
Use of pseudo-wide Label
stacking* to be further
specified.
* : not pseudo-wire nesting
LSPs
TCM-PWE
MS-PW
AB-BD pw label swap
BD2 pw label push
BC lsp label push
48
LFU – Label For You (label 1314)
ACh – Associated Channel
CW – Control Word
Combined LSP OAM and
TCM-MS-PW
A
Section OAM
LSP OAM
B
LFU
ACh
AB
LFU
ACh
TCM-PWE (B to D)
OAM
E2E (A to E)
PW OAM
Non OAM Data Frames
AB
AB
ACh
AB
AB
CW
C
LFU
ACh
D
LFU
ACh
BC
LFU
ACh
CD
LFU
ACh
BC
BD2
ACh
CD
BD2
ACh
BC
BD2
BD
ACh
CD
BD2
BD
ACh
BC
BD2
BD
CW
CD
BD2
BD
CW
E
LFU
ACh
DE
LFU
ACh
B and D are S-PEs
One hop LSP OAM
and Section OAM
would traditionally
not run concurrently
Use of pseudo-wide Label
stacking* to be further
specified.
* : not pseudo-wire nesting
DE
DE
ACh
DE
DE
CW
LSPs
TCM-PWE
MS-PW
LFU a priori not
needed because
BD2 bottom of
stack and
negotiated Ach
49