1. MPLS Architectural Considerations for a Transport Profile
ITU-T - IETF Joint Working Team
Dave Ward, Malcolm Betts, ed.
March 25, 2008

2. 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. .

3. Some Initial Participants and contributors of this setBT
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 .

4. How is the effort organized?
In ITU-T
TMPLS ad hoc group
In IETF
MPLS interoperability design team
DMZ between the SDOs: Joint Working Team
Segmented into groups looking at
Forwarding
OAM
Protection
Control Plane
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
The Q.3/15, Q.9/15, Q.11/15, Q.12/15, Q.14/15 and Q.5/13 will be involved from the ITU-T side, and MPLS, CCAMP, BFD, PWE3, L2VPN WGs will be involved from the IETF side. IETF co-chair provided a verbal report on the status of the IETF MPLS Interoperability Design Team (DT), which is the IETF side of JWT, and the first DT meeting is expected to be held during the week of Feb 24th.
During the ad hoc group meeting, the ITU-T provided overview of its Recommendations in each area and the IETF provided overview of its corresponding IETF technologies. The key points in each area were noted and will be furthered discussed at the next ad hoc group and JWT meetings.

5. 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 .

6. 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 .

7. 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

8. MPLS-TP Major Solution Constructs
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
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 .

9. High Level Architecture

10. MPLS-TP service spectrum
MPLS-TP solution must exist
over this spectrum
Connection
Orientated
Connectionless
Multi-service
(Connectionless and Connection Orientated)
L3 only
L1, L2, L3 Services
Pt-Pt, Pt-MPt, MPt-MPt
L1, L2 Services
Pt-Pt and Pt-MPt
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
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
Static or Targeted LDP
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 .

11. MPLS+TP Static Provisioning
Network Management System
Control Plane for PT2PT services
OAM
OAM
OAM
Edge
Forwarding
Tables
Forwarding
Tables
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

12. MPLS Transport Profile - Terminology
Emulated Service
Pseudo-wire
Multi-node PSN cloud
Attachment
Circuit
Attachment
Circuit
CE1
CE2
PE1
PW1
PE2
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? .

13. Multi segment Transport LSP example
Service Provider
Carrier 1
Carrier 2 CE or
PE? PE P PE PE P PE CE or
PE?
UNI or
NNI?
NNI
UNI or
NNI?
end to end OAM
MEP
MIP
MIP
MIP
MIP
MEP
per carrier OAM
MEP
MEP
MIP
MEP
MEP
MIP
MEP
MEP
<<We need to discuss/review the differences between segment and tandem connection.
It seems that they are used as synonymous in this slide.
The reference network scenario is not very clear.>>
A segment is between MEPs
OAM is end to end or per segment
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)

14. Nested segment example
MEP/MIP architecture updated
Carrier 1
Region 1
Region 2
PE1
PE2 P
PE3
PE4 P
PE5
PE6
NNI
INNI
NNI
end to end OAM
MIP
MIP
MIP
MIP
per carrier OAM
MEP
MIP
MIP
MEP
per region OAM
MEP
MIP
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

15. Bi directional Paths External Static Provisioning.
External Static Provisioning
NMS responsible for configuration and ensuring bi-directional congruency
If Dynamic Control Plane
GMPLS bidir RSVP for LSP path establishment

16. 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”. .

17. OAM requirements

18. 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 .

19. 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>> .

20. OAM mechanisms

21. OAM hierarchy and mechanismsB A D C F E
L1/L2
L1/L2
L1/L2
L1/L2
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 .

22. Should this be the same as PWE-3 format?
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)
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
Should this be the same as PWE-3 format? .

23. 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

24. Associated Channel Level (ACH)

25. 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? .

26. 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 .

27. LSPs / OAM and Label Stacks

28. Scope of next (label stack example) slides
Slides focus on MEP to MEP monitoring
Detailed OAM packet walkthrough not yet covered in this slide-set
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

29. SS-PW, LSP and TCM-LSP OAM
LFU – Label For You (label 13|14)
ACh – Associated Channel
CW – Control Word
SS-PW, LSP and TCM-LSP OAM A B C D E
Section OAM
LFU
LFU
LFU
LFU
ACh
ACh
ACh
ACh
TCM-LSP OAM BC CD
LFU
LFU
ACh
ACh
E2E (A to E)
LSP OAM BC CD AB BD BD DE
LFU
LFU
LFU
LFU
ACh
ACh
ACh
ACh
E2E (A to E)
PW OAM BC CD AB BD BD DE AE AE AE AE
ACh
ACh
ACh
ACh
Non OAM Data Frames
TCM-LSPs BC CD AB BD BD DE
E2E LSP AE AE AE AE
SS-PW CW CW CW CW

30. SS-PW over inter-domain LSP
LFU – Label For You (label 13|14)
ACh – Associated Channel
CW – Control Word
SS-PW over inter-domain LSP
Domain A
Domain B A B C D E F
Section OAM
LFU
LFU
LFU
LFU
LFU
ACh
ACh
ACh
ACh
ACh
One hop TCM-LSP OAM and Section OAM would traditionally not run concurrently
TCM-LSP OAM AB BC DE EF
LFU
LFU
LFU
LFU
ACh
ACh
ACh
ACh
Manual stiching in C and D
E2E LSP OAM AB BC DE EF AC AC CD DF DF
LFU
LFU
LFU
LFU
LFU
ACh
ACh
ACh
ACh
ACh
E2E PW OAM AB BC DE EF AC AC CD DF DF AF AF AF AF AF
ACh
ACh
ACh
ACh
ACh
Non OAM Data Frames
TCM-LSPs AB BC DE EF AC AC CD DF DF
E2E LSP AF AF AF AF AF
SS-PW CW CW CW CW CW

31. OAM operations

32. Pseudo-wire OAM processingB 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

33. LSP End Point processingA 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

34. End to End LSP operations
LFIB:CD-DE
LFIB:AB-BC
LSP OAM
DE, PW-L E
Primary Path
LFIB:BC-CD
PW-L, AB A
YZ, PW-L
LFIB:XY-YZ
PW-L, AW
LFIB:WX-XY
LFIB:AW-WX
Backup Path
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 .

35. Segment LSP operations
LSP OAM
LFIB:AB-BC
LFIB:BC-CD
LFIB:CD-DE
PW-L, AB
DE, PW-L
LFIB:AW-WX
LFIB:WX-XY
LFIB:XY-YZ A E
Segment Backup Path
PW-L, AW
YZ, PW-L
Segment Primary Path B D
Primary Path
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 .

36. Control Plane

37. 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

38. Protection and Switchover

39. 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

40. 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

41. Network Management

42. 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

43. 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

44. Some open discussion points
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
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
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 .

45. The End

46. ECMP considerations This is a start of ECMP considerations and a place
MAC Header L1 L2
PWE-L/BOS
Control Word
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
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
This is a start of ECMP
considerations and a place
to discuss load-balance
labels .

47. LSPs / OAM and Label Stacks. Alternate approach using stacked PWs
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

48. TCM-MS-PW OAM B and D are S-PEs LSP OAM not shown here
LFU – Label For You (label 13|14)
ACh – Associated Channel
CW – Control Word
TCM-MS-PW OAM
B and D are S-PEs A B C D E
Section OAM
LFU
LFU
LFU
LFU
LFU a priori not needed because BD2 is bottom of stack and Ach has been negotiated
ACh
ACh
ACh
ACh
LSP OAM not shown here
TCM-PWE (B to D) OAM BC CD
BD2
BD2
Use of pseudo-wide Label stacking* to be further specified.
* : not pseudo-wire nesting
ACh
ACh
E2E (A to E)
PW OAM BC CD AB
BD2
BD2 DE AB BD BD DE
ACh
ACh
ACh
ACh
AB-BD pw label swap
BD2 pw label push
BC lsp label push
Non OAM Data Frames
LSPs AB BC CD DE
BD2
BD2
TCM-PWE AB BD BD DE
MS-PW CW CW CW CW

49. Combined LSP OAM and TCM-MS-PW
LFU – Label For You (label 1314)
ACh – Associated Channel
CW – Control Word
B and D are S-PEs A B C D E
Section OAM
LFU
LFU
LFU
LFU
ACh
ACh
ACh
ACh
One hop LSP OAM and Section OAM would traditionally not run concurrently
LSP OAM AB BC CD DE
LFU
LFU
LFU
LFU
ACh
ACh
ACh
ACh
TCM-PWE (B to D) OAM
Use of pseudo-wide Label stacking* to be further specified.
* : not pseudo-wire nesting BC CD
BD2
BD2
ACh
ACh
E2E (A to E)
PW OAM BC CD AB
BD2
BD2 DE AB BD BD DE
ACh
ACh
ACh
ACh
LFU a priori not needed because BD2 bottom of stack and negotiated Ach
Non OAM Data Frames
LSPs AB BC CD DE
BD2
BD2
TCM-PWE AB BD BD DE
MS-PW CW CW CW CW