MPLS Architectural Considerations

for a Transport Profile

O
  O 
   




 !!
"#$



ecutive Overview
± Recommendation
ntroduction and Background Material
igh Level Architecture
OAM Requirements
OAM Mechanisms and Baseline Use Cases
Associated Channel Level (AC
orwarding and OAM
± LSP/PW OAM
± Use Case Scenario and Label Stack Diagrams
± Use of TTL for MP OAM alert
± Packet Contet
Control Plane
Survivability
etwork Management
Summary
4

ecutive Summary

:
 ' 
 
Î Consensus on recommendation of Option 1
± Jointly agree to work together and bring transport requirements into the 
T and etend

T MPLS forwarding, OAM, survivability, network management and control plane
protocols to meet those requirements through the 
T Standards Process
± The Joint Working Team believes this would fulfill the mutual goal of improving the
functionality of the transport networks and the internet and guaranteeing complete
interoperability and architectural soundness
± Refer to the technology as the Transport Profile for MPLS (MPLS-TP
± Therefore, we recommend that future work should focus on:
n the 
T: Definition of the MPLS ³Transport Profile´ (MPLS-TP
n the TU-T:
± ntegration of MPLS-TP into the transport network
± Alignment of the current T-MPLS Recommendations with MPLS-TP and,
± Terminate the work on current T-MPLS

Î The technical feasibility analysis demonstrated there were no ³show

stopper´ issues in the recommendation of Option 1 and that the 
T MPLS
and Pseudowire architecture could be etended to support transport
functional requirements
± Therefore the team believed that there was no need for the analysis of any other option
Ë
 %
%
&' (
 
%
%
Î t is proposed that the MPLS interop design team, JWT and ad hoc T-
MPLS groups continue as described in SG1* TD*1*/PL
 with the
following roles:
± acilitate the rapid echange of information between the 
T and TU-T
±
nsure that the work is progressing with a consistent set of priorities
± dentify gaps/inconsistencies in the solutions under development
Propose solutions for consideration by the appropriate WG/Question
± Provide guidance when work on a topic is stalled or technical decision must
be mediated
Î one of these groups has the authority to create or modify 
T RCs or
TU-T Recommendations
± Any such work will be progressed via the normal process of the respective
standards body
± Direct participation in the work by eperts from the 
T and TU-T is
required

*
'#
)O *+&O
"
,  
Î The 
T MPLS nteroperability Design Team should be chartered to produce an
MPLS-TP architectural documentation hierarchy
± All documents would progress in appropriate 
T WGs according to the normal process
± The list of specific documents to be written in the 
T will be created by the Design
Team
To allow rapid development of the architectural foundation documents no additional
work on MPLS-TP will be taken on until the architectural foundation RCs have
progressed into WG LC
± The Design Team is the group sponsored by the Routing Area Directors to facilitate rapid
communication and coherent and consistent decision making on the Transport Profile for
MPLS
± An eample of such a tree (by functional area is below:

Requirements
(MPLS WG

Transport Profile Architectural ramework

(MPLS WG

Alert Label Definition AC Definition Survivability Control Plane etwork Management
(MPLS WG (PW
: WG (MPLS WG (CCAMP WG (MPLS WG
†
 
#'$ *+& *
Î Work areas will be assigned to the appropriate 
T Working Groups to
develop the RCs
± Working group charters and milestones will be updated to reflect the new
work

pected to be completed before 
T 4 (July 4 
This will include the list of documents in the architectural hierarchy
± WGs will appoint authors and where appropriate form design teams to
develop the RCs
t is assumed that TU-T participants will be active members of these
design teams
The draft will be reviewed by the TU-T prior to completion of WG last call
± TU-T review will be by correspondence, the results of this review will
be conveyed via a liaison statement
» Review by correspondence will avoid delaying WG last call to align
with an TU-T SG/eperts meeting
»
arly communication via liaisons and the JWT should allow us to
avoid major comments on the final documents
v

  
     

 
 
  






#O
 ' 
  *+& *
Î The normative definition of the MPLS-TP that supports the TU-T transport
network requirements will be captured in 
T RCs
Î The TU-T will:
± Develop Recommendations to allow MPLS-TP to be integrated with current
transport equipment and networks
ncluding in agreement with the 
T, the definition of any TU-T specific
functionality within the MPLS-TP architecture
± Via the MPLS change process (RC Ë 4 
Revise eisting Recommendations to align with MPLS-TP
± t is anticipated that following areas will be in scope. The actual
Recommendations will be identified by the questions responsible for the topic
areas.
Architecture (e.g. G. 11.1

quipment (e.g. G. 141
Protection (e.g. G. 1:1, G. 1:4
OAM (e.g. G. 11:, G. 11Ë
etwork management (e.g. G.1, G.14, G. 1*1, «
Control plane (e.g. G.1:, G.1*, «
± TU-T Recommendations will make normative references to the appropriate

RCs

#O
 ' 
  *+& *
Î Work areas will be assigned to the Questions as defined in COM 1* - C1
(Questions allocated to SG1*
± Work will be progressed in each question
Direct participation by interested parties from the 
T is strongly
encouraged
Draft versions of Recommendations will be provided to the 
T for
review via a liaison to a WG and/or via the JWT
± t is anticipated that approval will be using AAP as defined in
Recommendation A.
nterim WP meetings may be required to allow timely consent of
Recommendations that rely on normative references to RCs
inal tet for consent will be provided to the 
T for review
± nitiation of the AAP process should be timed such that members can
base AAP comments on an appropriate 
T WG consensus review
of the consented tet
±
arly communication via liaisons and the JWT should allow us to
avoid major comments on the final documents
» e.g. the draft Recommendation for consent should be sent to the

T for review prior to the SG meeting
 %

 )%
Î irst draft of the Transport Profile Architectural ramework
± 
T 4 (July 4 
± WG last call completion Q4/4

Î Draft to request new reserved label for MPLS TP alert

± 
T 4 (July 4 

Î RCs on Alert Label and AC definition

± WG last call completion Q4/4

Î Updated TU-T Recommendations

± Q4/4 (may need to schedule eperts meeting/WP plenary to
avoid delaying consent to the October 4 meeting of SG 1*

A significant amount of work is required to achieve these milestones

We need to start immediately (May 4 
eed a commitment from interested parties to edit and drive the drafts

1
ntroduction and
Background Material

11
 )
O -
Î This presentation is a collection of assumptions, discussion points and
decisions that the combined group has had during the months of March and
April, 4
This represents the agreed upon starting point for the technical analysis of the T-
MPLS requirements from the TU-T and the MPLS architecture to meet those
requirements

Î The output of this technical analysis is the recommendation given to SG 1*

on how to reply to the 
T
s liaison of July 4
± 
T requested decision on whether the SDOs work together and etend MPLS
aka ³option 1: or
± TU-T choose another ethertype and rename T-MPLS to not include the MPLS
moniker aka ³option 4´

Î 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.
Option 1 was stated as preferred by the 
T and if it can be met; Option 4 will not
be eplored 14
&
"%


))

%

Î BT
Î Verizon
Î ATT
Î TT
Î Comcast
Î Acreo AB
Î Alcatel-Lucent
Î Cisco
Î
ricsson
Î uawei
Î Juniper
Î ortel
Î Old Dog Consulting

1:
 ±.
)##
 (-

1. n TU-T
TMPLS ad hoc group
4. n 
T
MPLS interoperability design team
:. DMZ between the SDOs: Joint Working Team
Î Segmented into groups looking at
1. orwarding
4. OAM
:. Protection
Ë. Control Plane
*. etwork Management
Î Goal: Produce a technical analysis showing that MPLS architecture can
perform functionality required by a transport profile.
Compare w/ TU-T requirements and identify showstoppers
ind any obvious design points in MPLS architecture that may need etensions 1Ë
*+&  
*#/)

)"-
Î Desire to statically configure LSPs and PW
s via the management plane
± ot solely via control (routing/signaling plane
± f a control plane is used for configuration of LSPs/PW
s failure and recovery of the control
plane must not impact forwarding plane (a la SR/S

Î Transport OAM capabilities don

t eist for LSP and PW
independent of configuration
mechanism (management plane or GMPLS or PW
control plane
± ull transport CAPS - AS, RD, Connection verification (aka connectivity supervision in
G. †, loss of connectivity (aka continuity supervision in G. †, support of MCC and SCC
etc
± Recent drafts to 
T demonstrate some issues

Î Service Providers are requesting consistent OAM capabilities for multi-layered

network and interworking of the different layers/technologies (L4, PW
, LSP
± nclude functionality of Y.111 and Y.1:1 into one architecture

1*
*+& */)

)"-
Î Service Providers want to be able to offer MPLS LSPs and PW
s as a part of their
transport offerings and not just associated with higher level services (e.g. VPs

Î Service Providers want LSPs/PW
s to be able to be managed at the different nested

levels seamlessly (path, segment, multiple segments
aka Tandem Connection Monitoring (TCM, this is used for eample when a
LSP/PW
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
ncluding scenarios of LAG or
CMP
Or create LSP/PW
s that don
t traverse links with LAG/
CMP

1†
*+& *'0%
'.

Î Meet functional requirements stated earlier by service providers

Î o modification to MPLS forwarding architecture

Î Solution Based on eisting Pseudo-wire and LSP constructs

Î Bi-directional congruent p4p LSPs

Î o LSP merging (e.g. no use of LDP mp4p signaling in order to avoid losing
LSP head-end information

Î Multicast is point to multipoint not MP4MP

1
*+& *'0%
'.
Î OAM function responsible for monitoring the LSP/PW

nitiates path recovery actions

Î P forwarding is not required to support of OAM or data packets

OOB management network running P is outside scope of feasibility study
Î Can be used with static provisioning systems or with control plane
With static provisioning, no dependency on routing or signaling (e.g.
GMPLS or, GP, RSVP, BGP, LDP
Î Mechanisms and capabilities must be able to interoperate with eisting MPLS
and PW
control and forwarding planes

1
*+& *1&%
 $ 
%

OT
: These two constructs were used as the basis for the Technical easibility study performed
by the ad hoc team, JWT and 
T MPLS nteroperability Design Team

1. Definition of MPLS-TP alert label (TAL and a Generic Associated Channel

(G
AC
Allows OAM packets to be directed to an intermediated node on a LSP/PW

Via label stacking or proper TTL setting
Define a new reserved label (1: is suggested:
t is believed that Label 1Ë cannot be reused at this point

4. Generic Associated Channel (G
AC functionality supports the CAPS

functions by carrying OAM, APS,
CC etc. packets across the network
Use of PW
-: Associated Channel to carry OAM packets
G
AC are codepoints from PW
AC space but, not necessarily, for PW
purposes
G
AC would be present for OAM of all LSPs

1
*+& *1&%
 '"
 

1. Bringing AC functionality into LSPs begins to blur the architectural line
between an MPLS LSP and an MPLS Pseudowire
The functional differences between an MPLS LSP and MPLS PW must be retained
in the architecture

4. The same OAM mechanism (e.g. AC can be unified for LSPs and PW


nabling the same functionality for both and ease of implementation
Avoid breaking anything (e.g.
CMP
There may be specific differences that are discovered in design phase
AC functionality for LSPs should be limited to only OAM, APS &
CC
management channel data

:. A great deal of 
T protocol, design and architectural reuse can be

employed to solve the requirements
o fundamental change to the 
T MPLS architecture was found to be necessary

4
 *+& *
+"'"
  

Î The JWT has established that to create an MPLS-TP there is a need for an
associated channel that shares fate and coeists with data

Î One possibility would be to use the OAM Alert Label (label 1Ë to establish
this channel but:

Î 
T WGs and TU-T SGs were polled to find out the state of
implementation and deployment of Y.111 and RC:Ë4
± The conclusion was that there are enough implementations and deployments
so that it is not possible to immediately deprecate Y.111 and RC:Ë4

41
 *+& *
+"'"
 
Î The JWT has concluded that a new reserved label may be
needed for the MPLS TP alert
Î This label would be requested from the pool of un-allocated
reserved MPLS labels
Label 1: has been suggested.
Î The suggested roadmap is to gradually move all OAM
functionality defined by label 1Ë over to the new reserved label
Î The specification of the new OAM channel must be
accompanied with a decision to stop further etension of OAM
based on label 1Ë
Only maintenance operations continue

44
igh Level Architecture

4:
*+& *
% MPLS-TP solution must eist
over this spectrum

Connection
Connectionless Multi-service Oriented
(Connectionless and Connection Oriented (The label is the service

L: only L1, L4, L: Services L1, L4 Services

Pt-Pt, Pt-MPt, MPt-MPt Pt-Pt and Pt-MPt
ode/Link addressing ode/Link addressing ode/Link addressing
P P Multiple
Tunnel provisioning mechanisms
Tunnel provisioning mechanisms Tunnel provisioning mechanisms
P based
RSVP-T
(RC :4 or RC :˝: RSVP-T
(RC :˝:
LDP or RSVP-T
(RC :4 
LSP creation
ternal MS
ternal MS
Dynamic only LSP creation LSP creation
Label space Dynamic and static coeistence Static and dynamic coeistence
Dynamic label space Label Space Label Space
Load Balancing
Split label space (static / dynamic Static/dynamic label space

CMP only
Load Balancing Load Balancing
Penultimate op Popping
PP or no PP
CMP and on
CMP support on
CMP support
LSP creation Penultimate op Popping Penultimate op Popping
Static and dynamic coeistence PP or no PP o PP
PW setup mechanisms PW setup mechanisms Determine if PP can be used
Static
Static PW setup mechanisms
PW control protocol (RC ËË˝
PW control protocol (RC ËË˝ Static
PW control protocol (RC ËË˝

MP
RATV
MPLS-TP MUST B
ABL
TO T
ROP
RAT
 A L: 
TWORK

MPLS-TP MUST ALSO SUPPORT AD CO-
ST WT
STG PW
-: SOLUTOS 4Ë
 *+&2 *&

*  
etwork Management System
Control Plane for PT4PT services

' ' '

 .  .  .  
" " "

Î Static provisioning and dynamic control plane

Requirements state that the solution must include static only provisioning
Any dynamic Control plane will be based on 
T solutions (GMPLS, P/MPLS
Î Control Plane responsible for:

nd to
nd, Segment LSPs and PW
-: application labels (programming the LB
Determining and defining primary and backup paths
Configuring the OAM function along the path
Others : Defining the U etc
Î OAM responsible for monitoring and driving switches between primary and
backup paths for the end to end path and path segments
4*
 *+&  
*#  ,

mulated Service
Pseudo-wire
Multi-node PS cloud

Attachment Attachment
Circuit Circuit
$ $
* PW1 *

Î Definition of an MPLS Transport Profile (TP within 
T MPLS standards

Based on PW
: and LSP forwarding architecture

T MPLS architecture concepts
Î The major construct of the transport profile for MPLS are LSPs
PW are a client layer

4†
 +&*3
  
   
 

P
Carrier 1 Carrier 4 P

  

P
P P P
P
P P

end to end LSP OAM

M
P MP MP MP MP M
P

segment
segment LSP OAM LSP OAM segment LSP OAM
(carrier 1 (inter carrier (carrier 4
M
P MP MP M
P M
P M
P M
P MP M
P

A segment is between M
Ps

OAM is end to end or per segment
n SD/OT and
thernet segment OAM is implemented using Tandem Connection Monitoring (TCM
The OAM in each segment is independent of any other segment
Recovery actions (Protection or restoration are always between M
Ps i.e. per segment or end to end

ote: A policing function (traffic management/shaping is normally co M
P: Maintenance
nd Point
located with a M
P at a business boundary (U/ MP: Maintenance ntermediate Point 4
 
 *
)

Î
ternal Static Provisioning

MS responsible for configuration and ensuring bi-direction congruency
Î f Dynamic Control Plane
GMPLS bidirectional RSVP for LSP path establishment

4
OAM requirements

4
 ''0%


Î Must be able to monitor LSP, PW
:

± nter layer fault correlation
± ailure indication propagation across multiple segments
± Monitoring of Physical layer, layer 1, layer 4 is out of scope

Î Packet loss rather than bit error based measurements/metrics for L4, LSP,
PW
:

Î Per segment (aka tandem connection and end to end

± ault detection/isolation
± Recovery - protection switch or restoration

Î A security architecture

:
 )

,-

nd to
nd Protection

A B C D


Segment Protection

Î
nd to
nd recovery:

± ault detection and recovery of the end to end pseudo-wire
± ault detection and recovery of the end to end LSP Segment recovery:
Î ault detection and recovery of a segment
± The recovery mechanism used in a segment is independent of other segments
Î Segment constructs
± ierarchical nested LSP:
isting construct
± MS-PW segment: Currently defined construct in PW
:
± Stacked TCM label (mapped 1:1 with corresponding LSP/PW

:1
 
#


Î Will need to work through identification requirements

What about algorithmically derived label from the P identifier
What P identifier if we do not need P to support forwarding or OAM?
eed to be able to rearrange the DCC without disturbing the forwarding/OAM?

A node has multiple identifiers including the following:

Î Management identifier ± normally user friendly, based on the location
Î M
P/MP identifier
Î DCC address - how do management messages reach this node
Î Control plane identifiers - how are the various control components identified
Î orwarding plane identifier - end points and intermediate points - e.g. s
—



 

   



:4
OAM mechanisms

::
'./')), ) 

A B C D

L1/L4 L1/L4 L1/L4 L1/L4 L1/L4

Segment LSP

Midpoint

nd to
nd LSP
Pseudo-wire

Î L/L1 : Loss of Light; G. , SO
T/SD LoS, Lo,
S, S
S (OT DSCUSS
D

Î on MPLS L4 connectivity : ative L4 solution 4.1ag (ot Discussed , on P BD
ailure propagation across layers is supported by this architecture

Î General LSPs : Generic
ception Label and Generic Associated Channel

ncludes
nd to
nd and segment LSPs
Used to carry a variety of OAM, Mgmt, signalling protocols.

Î Pseudo-wires : PW
: Associated Channel :Ë

+&* 
 3
  
 .
) 

Carrier 1

Region 1 Region 4

  

P
P
P P
P
P P
P

end to end LSP OAM

M
P MP MP MP

segment LSP
OAM
Carrier 1 LSP OAM segment (inter carrier
M
P MP MP M
P M
P M
P

carrier 1 region 1 carrier 1 region 4

LSP OAM segment LSP OAM segment
M
P MP M
P M
P MP M
P

4+&*'2*'
end to end LSP + 4 nested segment LSP levels (Carrier 1 + regions 1/4
ested segments are supported by Tandem Connection Monitoring (TCM in SD/OT and Y.1:1
:*
 $3*5O*
 )
+3/$
Carrier 1 LSP segment OAM

& &
*%)  ."

)*&

,


)

 
.) 
)"

)*&

MP[1] verifies M
PSo connectivity to M
PySk

MP[4] verifies M
PSo connectivity to M
PzSo

MP [1] MP [4]

+,/$'  +(/$' 

region 1 OAM region 4 OAM

& & &
&

M
P O*%
%
 
  
) 
6,"#
)".7
 

 ,
 ,%
 O*
 

)

±


 
MP

Trail
:†
*+&* 
 3
Attachment circuit
C
Attachment circuit C

Carrier 1 Carrier 4

U  U

P
P P P
P
P P

PW OAM (end to end no switching

M
P M
P

end to end LSP OAM

M
P MP MP M
P

segment
segment LSP OAM LSP OAM segment LSP OAM
(carrier 1 (inter carrier (carrier 4
M
P MP MP M
P M
P M
P M
P MP M
P

end to end LSP OAM is used since PW OAM cannot create MPs at the inter carrier boundary without a
PW switching function

ote: A policing function (traffic management/shaping is normally co M
P: Maintenance
nd Point
located with a M
P at a business boundary (U/ MP: Maintenance ntermediate Point :
*+&*3.
)*.
) 
Attachment circuit
C
Attachment circuit C

Carrier 1 Carrier 4

U  U

P
P P P
-S P
-S P P

end to end PW OAM (with PW switching

M
P MP MP M
P

segment
segment LSP OAM LSP OAM segment LSP OAM
(carrier 1 (inter carrier (carrier 4
M
P MP MP M
P M
P M
P M
P MP M
P

end to end LSP OAM is not requires since the PW switching points can support a MP

ote: A policing function (traffic management/shaping is normally co M
P: Maintenance
nd Point
located with a M
P at a business boundary (U/ MP: Maintenance ntermediate Point :
Associated Channel
Level (AC

:

$) +$±/'.
Î Generalised mechanism for carrying management / OAM information
OAM capabilities : Connectivity Checks (CC and ³Connectivity Verification´ (CV
Management information:
mbedded Control Channel (
CC
To support the Data Communications etwork (DC and the Signalling Communication
etwork (SC ± see G.14
APS information
Î Associated Channel Capabilities
Multiple channels can eist between end points
Channel Type ndicates what protocol that is carried
To service an MPLS-TP network new channel types will need to be defined
Î Management and Control Plane nformation (DC and SC connectivity
Via
CC where P is not configured
Î Generic AC contains a ³channel Type´ field
eed for a registry of protocols
This needs to be blocked for different functions
(P-ree BD is currently 
We may want to define a vendor specific and eperimental range
 
  
Ë
 +&* 
   
8 3
 +" 8 
$) *

Y
      

 





 

Î Assign a Transport Alert Label as a Label or yoU (LU from reserved label space:
Label 1: has been proposed because,
Label 1Ë has been allocated to Y.111
Y.111 arch fits within ³AC´ architecture
Î Bottom of Stack is always set on LU in the transport profile

Î Define a Generic Associated Channel function

Similar to the PW
-: Associated Channel but doesn
t have to be associated with a PW
mportant the first nibble tells system not to load balance (so not † or Ë
Î Generic Associated Channel is always under a Generic
ception Label if endpoint (M
P
Î Generalised Associated Channel defines what packet function using ³channel type´ field

amples : What OAM function is carried, DCC, etc

Ë1
 *%. 
   
*4$
 *
$) 

Y
   !"
&

!  



' '&()

Y
   !" !#$%

 





 


This is a representation of what is in RC Ë: *

Ë4
'0%% 
 
, ",

$) 
Î CV : Connectivity Verification (detection of configuration errors
Î PM: Performance of the path
Î AS: Alarm suppression
Î CC : Continuity Check : s the path present (may reuse vanilla BD here
Light weight
Role is as a CC protocol, it is not a CV protocol
ot a connectivity verification protocol
VCCV-BD provides capabilities over pseudo-wire
Î
CC
OSS and control plane communication
Î APS
Protection switching coordination
Î Accounting/Billing information
Î Security echange
Î
tra codepoint space to define new or use eisting protocols for other
functions Ë:

$) % 
 
,
'"
 
Î   !""!#  ! 
 
  

# 
   
 $
% &&'(
% )    
 
  
* 
!""!# 
  



Î #    


 
 # 
 

  
 
% + #  '

 
, 
% -
"!*! .-
 $ 

ËË
 *%.' 

A B C D

Pseudo-wire

*%.+"

*%.
$) 

*%.$)  ,

'#% 


Y
 !#$% !#$%
 " Y*'


 

Î Processed by the pseudo-wire function on the end-points

nd 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
Ë*
 +&* *
 

A B C D

Pseudo-wire

8 
' 
+",

8 
$) 

8 $)  ,

'#% 


Y
  #$
 " Y*'


 


Î Label or yoU with Generic Channel Association

Î Processed by the LSP end point

nd to
nd LSP or Segment LSP
Î Verifies the operational status of the LSP
Many options including on P BD is an option encapsulation of Y.1:1 pdu
ˆ
orwarding and OAM:
LSPs / PW
OAM and Label Stacks

˝
 &# 3


Î Slides cover on M
P to M
P and M
P to MP monitoring

Detailed OAM packet walkthrough not yet covered in this slide-set
or MP monitoring traceroute or loopback is eecuted and TTL set accordingly
Î ntroduce concept of LSP/PW TCM label:
This is a label to indicate a tandem monitoring session contet
Label is stacked above label of LSP or PW being monitored
1 for 1 mapping between an LSP / PW and its TCM session. i.e. no multipleing
eed mechanism to bind TCM label to underlying LSP or PW being monitored
Î M
P to MP
M
P sets the TTL of the LSP, TCM or PW label so that it will epire when the target
MP is reached
Î PP
 
  

Ë


   
 
v [Destination][(using label provided by][optional
C]/[StackBit]
v Thus D(
/ means Destination is D, using label provided by (
 - i.e. c is
the tunnel net hop and the Sbit is  - i.e. not bottom of stack.
v Thus
(
p/1 means Destination is
, using label provided by (
 the 
C
is a pseudowire and the Sbit is 1, i.e. bottom of stack
v Special Labels and terms
LU = Label or yoU - OAM alert label
Ach = Associated Channel eader
CW = Control Word
P = PW 
C
2
2  

 






 





 
 


  
2
Ë
& 
Î SS-PW over intra-domain LSP
± o TCM OAM
±TCM-LSP OAM
Î SS-PW over inter-domain LSP
±LSP, TCM LSP & PW OAM
Î ntra-domain MS-PW
±MS-PW TCM OAM
Î ntra-domain MS-PW
±LSP OAM and TCM-MS-PW OAM
Î nter-provider MS-PW
±PW
4
and PW TCM OAM
Î SS-PW over ntra-domain LSP
±LSP M
P->MP OAM using TTL
Î ntra-domain MS-PW
±MS-PW OAM: PW M
P-MP, o TCM
Î ntra-domain MS-PW
±MS-PW OAM: TCM M
P->MP, plus
4
PW

*
 &
+&*
%

Starting Point
A B C D

L1/L4 L1/L4 L1/L4 L1/L4

end-to-end LSP
Pseudo-wire

inal Point
A B C D

L1/L4 L1/L4 L1/L4 L1/L4

Segment LSP

ew end-to-end (tunnelled LSP

Pseudo-wire

Objective:
Use bridge-and-roll with make-before-break mechanism
to ensure transition *1
&
+&*
%9 8!:.
Starting Point

nd to
nd LSP

A B C D

LC LC LC LC

inal Point
ew end-to-end (tunnelled LSP

A B D

LC LC LC
Segment LSP

C
LC ± Link Connection
LC LC

*4
 *%' '.

Î Step 1 : establish the segment LSP

Question : can segment LSP and eisting end-to-end LSP share bandwidth?
Î Step 4 : establish a new end-to-end LSP and which must be tunnelled in the
segment LSP
Use MBB procedures (for sharing resources between eisting and new end-to-end
LSP.
Î Step : : Perform switchover after Resv is received in A
TU-T mechanisms rely on the creation of a Protection Group between the old and
new (tunnelled end-to-end LSP, the forcing of protection switching via APS and the
tearing down of the Protection Group
Î Step Ë : Tear down the old end-to-end LSP

*:
 ?

?      

   
&&*+&*'6  $7 
 


  ë

V
 ?
 ?
 ?
 ?


   




ë
 ë  ë  ë ë
V ?
 ?
 ?
 ?

   




ë
 ë  ë  ë ë
 ë ë ë ë ë ë ë ë
   

  
ë
 ë  ë  ë ë ëë ?
ë ë ë ë ë ë ë ë 
   
*Ë
&&*
 +&* ?

?      

   

 
+&* $+&*;*'


  ë

ë    ë

 ?     

V
 ?
 ?
 ?
 ?
       ?
   
 ?  !
"#

 V    

?
 ?

 



   
ë
 ë  ë  ë ë
V ?
 ?
 ?
 ?

   



   
ë
 ë  ë  ë ë
 ë ë ë ë ë ë ë ë
   

       ?

ë
 ë  ë  ë ë ëë ?
ë ë ë ë ë ë ë ë 
   
**
&&*
+&* ?

?      

   

 
+&* $+&*;*' 
' $ 
  ?(

$   $ 


  ë

ë  

 ë

V
 ?
 ?
 ?
 ?
 ?


    
  
?  
  
 V 
   ë  %  &
?
 ?
 ?
 ?
   &
   


V 
   ë  ?  
       
?
 ?
 ?
 ?
 ?

   
    
" 
  $ ) ?


 
   ë  #  
        "  
     %  
    

   
   ë  ?

        ëë ?
     
    
*†
 ?

?      
O
 &* 
   

 
&*; $&*'


  ë
 V

T-P
S-P
 S-P
T-P

V
 ?
 ?


?
 ?

    ?
   
    
       " * +
?              
   !  # 
%  
"#

PW TCM
 
    
    
 *  % 
 
    *   ,-



   


     ë ë 
 ë
 ë  ë  ë ë
   

ë
ë  %  
  

     ë ë  ? %
    ë   %   
ë
 ë  ë  ë ë       
   
*
 ?

?      
O
 &* 
   

 
+&*&*; $&*'


  ë
 V

T-P
S-P
S-P
T-P

V
 ?
 ?
 ?
 ?


   
  ? 
   
% &
V

     ë ë
?
 ?
 ?
 ?

   &
   

 
     Use of pseudo-wire TCM
    
labels to be further spec
d
 



   


     ë ë
 ë
 ë  ë  ë ë
   
?
   
   
? " * +
  

     ë ë
    ë   # 
ë
 ë  ë  ë ë  
   
*
 ?

?      
O
&* 
   

 
+&*&*; $&*'
$   $ 


  ë

ë  ë ë  ë

V
 ?
 ?
 ?
 ?
 ?


    
  
?  
  
V 
     ë  %
?
 ?
 ?
 ?
 ?
 & 
       &

  V 
   ë 


  

    %# 
  
  


 
   ë 
      ë 
   ë 
    

   
   ë  ?  

         
     
    
*
&&*O
 +&* ?

?      

   

 
+&**<O*' %  +  ' ?


  ë

ë  ë
ë . ë

V
 ?
 ?
 ?
 ?


   

?   ?

  ë
 ' ë  '
 )  +
?
 ?
    .
V  

? /  0 

+   ëë



 ?  #
ë
 ' ë  ' ë  ' ë ë '
V ?
 ?
 ?
 ?

   




ë
 ë  ë  ë ë
 ë ë ë ë ë ë ë ë
   

  
ë
 ë  ë  ë ë ëë ?
ë ë ë ë ë ë ë ë 
   
†
O
 &* ?

?      

   
&**<O*'%  +ß  
 
 ' ?
ß 


 V


  ë 
 

ë ë ë ë ë
ë . . . ë

V
 ?
 ?


?
 ?

   

?   %    ?    ë .-

 +   ""  &  -
0 "        *
 *   )    * *

 

    
%  #"  %-  1 *
 ë
 ' ë  ' ë  ' %  #"  %$$- 
  






     ë ë 
 ë
 ' ë  ' ë  ' ë ë '
   

  

     ë ë  ?

ë
 ë  ë  ë ë 
   

†1
 ?

?      
O
 &* 
   

 
$&**<O*'%  +  ' ?


  ë
 V

ë ë ë ë
ë ë
. . ë

V
 ?
 ?


?
 ?

 
?   %  

   
 )  +
 


      .
 
 '   '
 

   
 
    


    
 
 '   '   '
 "  ë
  





    

     ë ë 
 ë
 ë  ë  ë ë    
   
%   ë

  

     ë ë  ?


     ë
ë
 ë  ë  ë ë 
   
†4
*
O*'/
+* #* +&*

Î n order to maintain individual levels of OAM and path

detection
Use pipe model per label level
TTL is not copied up the stack on a push
TTL is not copied down the stack on a pop
TTL is decremented on each swap and pop action
Traceroute for a level can be used to trap packets at each node
that processes the label for that level in the label stack

V




/ "! 
0
 /
/ /!+ 1

 0  "23

 
 
 "!

 /
†:
&)
*.
)
 + *±** 

A B C D
 G 

rom the TTL perspective, the

PW treatment for a Pipe Model LSP is
LSP4 LSP: identical to the Short Pipe Model
LSP1 without PP (RC:ËË:.
TTL=n TTL=n-1

Stack going into pipe Stack received at 

TTL=m TTL=m-1 TTL=m-1 TTL=m-4

TTL=k TTL=k-1 TTL=k-4 TTL=k-4 TTL=k-4 TTL=k-4 TTL=k-: TTL=k-:

TTL=j TTL=j TTL=j TTL=j TTL=j TTL=j TTL=j TTL=j

Bottom of stack †Ë
 
+&* +* 67

Î The previous picture shows

PW: Pseudowire
LSP1: Level 1 LSP (PW is carried inside
LSP4: Level 4 LSP (LSP1 is nested inside
LSP:: Level : LSP (LSP4 is nested inside
Î TTL for each level is inserted by the ingress of the level
PW TTL is initialized to j at A
LSP1 TTL is initialized to k at A
LSP4 TTL is initialized to m at C
LSP: TTL is initialized to n at D
Î TTL for a particular level is decremented at each hop that looks at that level
PW TTL is decremented at 
LSP1 TTL is decremented at B, 
LSP4 TTL is decremented at G
LSP: TTL is decremented at
, 

†*
 
+&* +* 6 7 %

f a packet arrives at a node with TTL != 1, then the TTL is decremented

f the LB action for this label is POP, then this node should be a M
P for this label level
f the packet has an LU below the current label
The packet is passed to the control plane module for processing, including validating that the
node is a M
P, the packet contents are consistent
The appropriate OAM actions, as described by the packet, are taken
A reply, if required, is returned to the M
P that originated this message
f the packet doesn
t have an LU below the current label
f the current label is not bottom of stack, continue processing label stack
f the current label is bottom of stack, forward the packet according to egress processing for this
level

††
 
+&* +* 647
 %%

f a packet arrives at a node with TTL = 1, then the TTL is decremented and goes to 
f the packet has no LU below the current label, then the packet may be discarded
Statistics may be maintained for these packets
f the packet has an LU just below the current label
f the LB action for this label is POP, then this node should be a M
P for this level
The packet is passed to the control plane module for processing, including validating
that the node is a M
P, the packet contents are consistent
The appropriate OAM actions, as described by the packet, are taken
A reply, if required, is returned to the M
P that originated this message
f the LB action for this label is SWAP, then this node should be a MP for this level
The packet is passed to the control plane module for processing, including validating
that the node is a MP, the packet contents are consistent
The appropriate OAM actions, as described by the packet, are taken
A reply, if required, is returned to the M
P that originated this message

†
 %
&
* +* 

LSP
PW

A B C D

LSP LSP

PW

Label stack TTLs

used on the wire

TTL=k TTL=k-1 TTL=n TTL=n-1

TTL=j TTL=j TTL=j-1 TTL=j-1
A-B B-C C-D D- «
†
 $+&* +* 

Î The previous picture shows

PW1: Pseudowire
LSP1: Level 1 LSP (PW1 is carried inside
PW4: Pseudowire (PW1 is stitched to PW4
LSP4: Level 1 LSP (PW4 is carried inside
Î TTL for each level is inserted by the ingress of the level
PW1 TTL is initialized to j at A
LSP1 TTL is initialized to k at A
PW4 TTL is initialized to m at C
s m = j-1?
LSP4 TTL is initialized to n at C
Î TTL for a particular level is decremented at each hop that looks at that level
PW1 TTL is decremented at C
LSP1 TTL is decremented at B, C
PW4 TTL is decremented at

LSP4 TTL is decremented at D,

†
 $*$ 
 

Î OAM and Data MUST share fate.

Î PW OAM fate shares with PW through the first nibble mechanism (RCË 4 
and hence is fate shared over any MPLS PS.
Î ate sharing is not assured for the MPLS Tunnel OAM/Data in the presence of

CMP.
Î The current MPLS Transport Profile ensures OAM/Data fate sharing for the
MPLS tunnel by ecluding the use of MPLS
CMP paths (for eample by only
using RSVP or GMPLS signaled MPLS tunnels
Î There is a requirement to improve 
T MPLS OAM. This will require the
problem of fate sharing in the presence of
CMP to be addressed.
Î f the OAM/DATA fate sharing problem is solved for MPLS
CMP, then the
Transport Profile may be etended to take advantage MPLS paths that employ

CMP.


 '$=> ) 

Y
   !#$"
&

!  


+, -
& 

Y
   !#$" !#$%
 " Y*'


 

Î Static Control Plane
Under the control of an eternal MS 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
CMP routes
Traffic
ngineering can as well (auto-route
Î Recognized in 
T
RC Ë 4 Avoiding
qual Cost Multipath Treatment in MPLS etworks :  or 1 in the first nibble of the payload
RC Ë: * PW: Control Word for Use over an MPLS PS : Defines ³Generic PW
-: control word´ and ³PW
Associated Channel´ formats
Î A consistent approach required for MPLS with a transport profile
RC Ë 4 implemented through use of control word and PW
-: AC
RC Ë: * for Control Word and PW associated Channel formats
OT
: joint proposals to be made on ³Load Balance´ label technology in PW
: WG 1
 &
+&*
 
LB:CD-D

D
LB:AB-BC
D
, PW-L
B
Segment Primary Path
PW-L, AB
LB:BC-CD


A LB:Y-YZ
YZ, PW-L

PW-L, AW

Segment Backup Path LB:W-Y

LB:AW-W
Primary Path

LSP OAM

Î Path diversity is not part of the OAM process. t is the responsibility of the Control or
Management Plane
Î OAM function uses LU with Generic Channel Association
Î Pre-provisioned segment primary and backup paths
Î LSP OAM running on segment primary and back-up paths (using a nested LSP
Î OAM failure on backup path Alert MS
Î OAM failure on primary path results in B and D updating LB to send traffic labelled for BD via
segment backup path
Î
nd to
nd traffic labelled for BD now pushed onto segment backup path
4
  
 +&*
 

LB:CD-D

LB:AB-BC LSP OAM
D
, PW-L

PW-L, AB
Primary Path LB:BC-CD


A LB:Y-YZ
YZ, PW-L

PW-L, AW

LB:W-Y
LB:AW-W Backup Path

LSP OAM
Î Path diversity is not part of the OAM process. t is the responsibility of the Control
Plane
Î OAM function uses LU 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 MS
Î OAM failure on primary path A and
updating LB to send and receive PW-L
traffic over backup path
:
*±*

Î t is believed that PP may be able to be used in the

transport profile.
Î The issue is how do we maintain the packet contet for
both the data and OAM
described on the following : slides

Î One scenario follows:

SS-PW, LSP and TCM-LSP

Ë
* 
$
3

Î OAM operations require packet contet.

Î Work to date has proposed that this is supplied by the
label value and hence precludes the use of PP.
Î Using the label as the identifier is a simple mechanism
that can be applied to both OAM and data packets, but
has a number of issues:
±Precludes PP which has cost and applicability implications
for the OAM
±Label errors may produce comple network issues
Î Other contet indicators may be available that allow the
lifting of the PP constraint (at least as an option.

*

 
$
3
O 


Î n the case of P the P address provides contet

Î n the case of PW, the PW label provides contet
Î n the case of an OAM pkt, an identifier can provide
contet
Î The issue are:
± OAM and data must fate share;
± eed to provide contet identification for performance
monitoring of data packets, or the need to provide an alternative
mechanism that provides satisfactory performance information.

†

#
 

3
) 
Î The MPLS architecture supports label retention and hence we
can proceed on the basis that this approach is available to the
design team.
Î There are costs to the prohibition of PP that needs to be fully
understood and accepted.
Î During the design phase we need to:
± Understand the costs, limitations, vulnerabilities and advantages of the PP
and non-PP approaches
±
ither
1. Confirm label as contet identifier and hence confirm PP restriction
4. Propose an alternative mechanism that satisfies all needs and which
permits PP
:. Propose the specification of a PP and non-PP method with appropriate
applicability statements.


&&*+&*  $+&*' ?

?      2

   

 
*±*

  ë

V
  %     ë & 3

   

 V  
?
 ?

 



 
ë
 ë  ë 
V ?
 ?
 ?
 ?

   



 
ë
 ë  ë 
 ë ë ë ë ë ë ë ë
   

     ?

ë
 ë  ë  ëë ?
ë ë ë ë ë ë ë ë 
   

Control Plane


 $ % 5' 
 

Î Control plane sub-team sees  
 

isting 
T protocols can be used to provide required function
Transport network operation
DC/SC operation

T GMPLS protocols already applied to ASO architecture
Any protocol etensions needed will be easy to make
2 
      
V

  
— 
 
   

 
 
V 

 




 %
Î Transport profile should meet the requirements of the ASO architecture
Use 
T protocol suite given it is used for ASO
GMPLS RSVP-T
for LSP signaling
GMPLS OSP-T
and SS-T
for LSP T
information distribution
LDP will be used for PW setup (as part of client set up process
Î DC/SC
P-based DC/SC
AC defines
CC
Can have as many channels and protocols as necessary and therefore could
support the SC
Must have policing for DC/SC
S-S or OSP running in DC to provide DC topology information
Î Connectivity discovery and verification
Could use LMP if native mechanisms not adequate

1
 
"  

$
* ?.# .
 %+ %+ . *
..
.  .
ë.
ë   .
O
&* 
## ""  %+
4 4 %&
?
#   ?

SC
SC-A GW
SC-B

$   $ 

AC CP - CP - CP
- CP - CP - CP AC

ë ë ë ë

 
  ë 

LSP-Tunnel A LSP- LSP-Tunnel B

PW-Seg.
PW-Segment A PW-Segment B
AB
Tunnel

T-LDP T-LDP T-LDP T-LDP

RSVP-T
RSVP-T
RSVP-T
'&?*  RSVP-T
RSVP-T
RSVP-T

  
     ë  ?  

     
    

4
&'$5$ 
 
    

 %+   
 
   

.

  %+. *
.
 %+ %+ . *
..
.  .
ë.
ë   .

SC
SC-A GW
SC-

$   $ 

U CP - CP - CP
- CP - CP - CP U

ë ë ë ë

 

5

Call Call Segment A Call Call Segment Call

Con. Con.-Seg. Con.
Connection Segment A Connection Segment
Segmt. A Segmt.
Segmt. Segmt. Segmt.

CCCC1 CCA CCC CC
CC
CCCC4

CCC1 CCA CC
CCC CCD CC
CC CCC4

Call Connection
Signaling Signaling

:
Survivability

Ë
 

Î Survivability sub team has not found any issues that

prevent the creation of an MPLS transport profile
 
  

Î Therefore option 1 can be selected

Î Summary of discussion
± Three potential solutions have been identified
±
ach solutions has different attributes and advantages
± urther work in the design phase should eliminate one or more
of these options and/or provide an applicability statement

*
 %

Î ested LSPs (potentially PW
s provide levels of

hierarchy to support per segment and path recovery


!
"




Î Most of the time intermediate nodes to not process the

entire stack
Î
ach segment can act independently
Multiple potential solutions including
ative 
T mechanisms
Carry G. 1:1/G. 1:4 PDUs in an AC

†
 % 
Î ative MPLS protection schemes, such as facility bypass and detours, can be
used to provide ring protection in most, but not optimal in some scenarios
A single facility bypass LSP protects all LSPs over a specific link by wrapping
traffic
A detour LSP can be used for optimal traffic delivery to the egress point (without
wrapping
A detour LSP is needed for every LSP to be protected.
Also can provide optimized eit preventing the 4 bandwidth in other wrapping
repair technologies
Must add notion of DOW and ADMDOW (e.g. standby bit
Î TU-T G. 1:4 TM-SPRing defines a ring protection that includes additional
capabilities to the MPLS protection schemes, by supporting coordinated
protection in case of multiple failures (using single protection mechanism for
all cases
Î !" 

  
 
 
  
 4


 3

 
&5467 
  

   

  


   
 

 '0%
%, ' 
Î MPLS-TP ring protection shall satisfy the following:
± Less than * ms switching time
± Protect p-t-p and p-t-mp connections
± Support normal traffic and non-preemptable unprotected traffic
± Provide hold-off timer and wait to-restore timer
± Protect all traffic possible in case of single and multiple failures
iber, nodes or both
ailures that segment the ring
± Support operator
s commands
± Support a priority scheme to arbitrate between switch requests from multiple faults and/or operator
commands
Provide ability to coordinate multiple requests in the ring
± Bi directional switching

Î TU-T References:

TS TS 11  , Section †.4.4
TU-T G. Ë1, Section .4.4
Telcordia GR-14:, Section *
TU-T Draft G. 1:4, Section 

 '0%
%, + 
Î MPLS-TP linear protection shall satisfy the following:
± Less than * ms switching time
± Protect p-t-p and p-t-mp connections
v !*7* !"!

   
 859:3  
 

± Support normal traffic and non-preemptable unprotected traffic
± Provide hold-off timer and wait to-restore timer
± Support operator
s commands
± Support a priority scheme to arbitrate between switch requests from multiple faults
and/or operator commands
± Bi directional switching
± Revertive and non revertive operation
Î TU-T References:
± G.  .1 ± Generic linear protection
± G. 1:1 T-MPLS linear protection
Î ot addressed
'


#$

 

' 
 %

 3&  
)#. 

Î Basic restoration in a ring

Î MPLS protection scenarios

± acility Bypass
± Restoration using detours
Sub-optimal
Optimized

Î TU-T G. 1:4 TM-SPRing protection overview

± Label Allocation
± OAM and APS messaging
± P4P
± P4MP
± Multiple failures


 *+&
,,3

B B
C C
A A

D D
 

3/
Î Assume ingress to ring is at A and egress is at

Î acility bypass (B-A--
-D-C is established to protect link B-C
Î Link B-C in the ring goes down
Î acility bypass protects failure of link B-C with the red path to the merge point (C
Î
mulates conventional optical ring failure recovery
Î Requires two-label stack to redirect the LSP around the failure
Î Scale issue:
One facility bypass provides protection for all LSPs over link B-C
One facility bypass for each link in the ring (shared by all LSPs on that link 1
 
' . +% #

*+&
,,+"&
  
' & * 

O 
&

% 
 +&* V



 



V  


ë 
&
   = bypass label
ë
 B & = LSP payload
&

C
 
  ë 
A &


 
PP may or may
 not be used:
  TBD
D

 
 
  ë ë ë
&

4
 
' . +% #
*+&
,,+"&
  
' & * 

%



 +&* V



 



V  



ë

& B   = bypass label
CB bypass
label pushed by C


C
 
ë 
AC A & 
 ë 
(P
   &
ë 
&

  PP may or may
ë  not be used:
& TBD
 D
 
ë 
&

  
 ë ë ë
ë  &
&


(P


AC
:
 
' . +% #
*+&
,,+"&

 ' . +% #

' & * 

%


 +&*
 ' & *

V



 



V  

 
ë
  
& & B   = bypass label
CB bypass
label pushed by C

 
C
 


ë  

AC A & &  
  ë   
(P
  
 & &
ë  

& &
 
 
 PP may or may
ë  
 not be used:
& & TBD
  D
 
ë
ë  

& &

    
 ë
 ë ë  
ë  
 & &
& &


(P


AC
Ë
 *+&/
%
 '
('

 

ntry Point to repair path

B Primary-detour B
C merge point C
A A
Repair Path
D D
 

3
Î Assume ingress to ring is at A and egress is at

Î Detour established to protect link B-C merges with primary path at
, resulting in protection through B-A--

Î Link B-C in the ring goes down
Î Detour carries traffic to

Î Optimizes on conventional optical ring and facility bypass failure recovery
Î Requires one-label stack to redirect the LSP around the failure
Î Scale issue:
One detour per LSP is required for each working LSP
The detour LSP can be used to protect the failure of any link on the ring
*
 
' . +% #

 ' . +% #
*+&/
% +"&
  
'   * 

O 




 +&*
 ' & *

V



 



V  

ë 
&
   = detour label
ë

&
B

C

ë 
ë  &
A ë


ë 

ë  D
ë ë

ë ë
 &

Primary-detour merge point

†
 
' +% #
*+&/
% +"&
   
' & * 

%



 +&* V



 



V  


  = detour label


ë
 B
&

C

AC
A ë 
&

& 
ë 
&
D



ë ë
&

AC

  ' +% #

' +% #
*+&/
% +"&
   ' +% #

 ' +% #
 ' +%  

 ' & * 

%


 +&*  ' +%  

' & *

V



 




 



V  

V  


  = detour label

 
ë
   B
& &

C
 
AC
A ë 
&



&

 
ë 

& &
D

  
ë ë

& &

Open issue for discussion: ow to force both ends

pick same merge point for each direction?

AC

' 0%
  *+&
,",5
%

Î  
  but, to be solved in the design phase

± 

± 

 &
   
± 

 
  

"


± 

   

'
   
  
± (
  
  

 
± 




' 


± ) V
 './ &*' "


 


 
„

  


 

a
?
   

   

p ode 1 k
 +" *+"
ode 4 ode †
 ï 
b o l
" ï "
 ï 
ode : ode *

 ï 
n ode Ë m
ï 
c d
ï 
 
  


   


1
'./ &*' ' 
  *&

Î Monitoring:
„
 
„  ±
ach section (span in the ring is monitored
by sending CV OAM with periodicity of
:.:ms
± Span failures are detected as absence of :
consecutive CV frames
ode 1
ode 4 ode †
Î APS:
O 


 
±
ach node has an APS controller that
sends and receives APS PDUs using an
ode : ode * AC
± n normal state APS controller generates
ode Ë
R (no request PDUs to its neighbours in
both directions
± When there is no failure each node in the




ring is in the dle state i.e. frames are not
forwarded on the protection LSP

When there is no failure in the ring:

All nodes are in the idle state
All nodes generate and terminate
APS R PDUs to their neighbours

11
 &*' 


3

      

„ „

 
 
 : 

 
 

      


   

ode 1 ode 1
ode 4 ode † ode 4 ode †
: 

 :
  
   


 :

 

ode : ode *
 ode : ode *


ode Ë ode Ë
  :
  


 : 
 : 

 :
 

When failure occurs:

The nodes adjacent to the failure enter the switching state and sends APS S
PDUs to neighbors
When the other nodes in the ring receive the S PDU they enter pass-through
state (i.e. allow forwarding on the protection LSP and forward the APS PDUs
without modification
14
 &*' 

%

3

      

„ „

 
 

 
 



    

 

   
   

ode 1 ode 1
: 

ode 4 ode † ode 4 ode †
 

: 

 :
  
   


 :

 

ode : ode *
 ode : ode *


ode Ë ode Ë
  :
  


 : 
 : 

 :
 






   

—


 
'&& && 
 
'
 



' 






1:
 &*' %
#%3
       
: 
 : 

 
„  
„

 
 
 
 
  

     

  

 

ode 1 ode 1
ode 4 ode † ode 4 ode †

  
   


 

 

ode : ode *
 ode : ode *


ode Ë ode Ë
   

 

: 
 : 

 


  

 

The same mechanism with a single protection connection restores all traffic possible:
or p-t-p and p-t-mp connections
or fiber or node failure
or single or multiple failures

1Ë
etwork Management

1*


Î etwork Management sub team has not found any

issues that prevent the creation of an MPLS transport
profile
Î Therefore option 1 can be selected
 
  

1†
 $ %  O

Î eed to be able to provision and manage a LSP or PW across a network where some
segments are managed by 
T (e.g. netconf and other segments that are managed
by TU/TM (ML/CORBA interfaces.
± LSP establishment
MPLS management in the 
T already supports the ability to independently
setup LSP segments (using different tools to create a concatenated (end to
end LSP
± LSP maintenance
t is possible to run maintenance on an LSP independent of the mechanism
used to establish the LSP
± The TU/TM interface supports the management of multiple technologies
Management of MPLS-TP needs to be added to these multi technology
interfaces

Î o need to eplicitly support the case of a single 
that offers both the 
T and
TU/TM interface
± This is a 
implementation issue
1
 $ % 
Î etwork Management (M requirements
± Configuration
o issues
± ault, PM
f the OAM can provide the measurement primitives then no reason that M
cannot report them
eed to allow each operator to determine the performance of the segment (plus
end to end.
± Accounting
Limited functionality ± e.g. reporting of unavailable time, providing PM data
± Security (of the management interface
ot specific to MPLS-TP networks
Dependent on:
± Management protocol
± Management application
± Bearer for the management traffic
Security implementation is per network segment

1
  
9  % O 

Î 
T architecture is layered and the functionality is allocated in separate

processes, e.g.:
± Performance management
etflow/Pfi
± Sample packets with a defined label ± allows inspection of contents
SMP MBs (e.g. packet counts on LSPs, Octets on an LSP, Queue
drops, CRC errors from lower layers ± LSP not identified
± ault management
SMP traps,informs, BD and syslog
± Configuration management
etconf, SMP
± Security
Psec, tls, eap, Radius etc
± Accounting
TACACS, netflow, ippm, ppml

Î 
T doesn
t use TM style CORBA/ML interfaces

1
  
9  % O

Î TM/TU approach
± Provides both a 
and etwork level interface to the OSS
± Protocol neutral model (in UML, requirements and use cases
± Protocol specific interface definitions

11
O
 *"1

Î PM Requirements for a MPLS-TP LSP/PW
Î Same measurements and processing as
thernet
± Connectivity defects present in a 1-second period
± number of lost (circuit/packet frames in a 1-second period
± near-end and far-end (severely errored second
± 1 seconds being severely errored/not severely errored to enter/eit
unavailable time (UAT
± 1*min and 4Ëhr PM parameter reporting
Î To define how LM (loss measurement and DM (delay
measurement information, as defined in Y.1:1 & draft G. 11Ë, is
registered in 1*min/4Ëhr bins (G.1

Dependent on OAM providing the primitives to

make these measurements
111
Summary

114
&%,
To date we have found no showstoppers and everyone is in agreement
that we have a viable solution
'  

t is technically feasible that the eisting MPLS architecture can be

etended to meet the requirements of a Transport profile
The architecture allows for a single OAM technology for LSPs, PW

and a deeply nested network

rom probing various SGs, WGs it appears that label 1Ë has had wide
enough implementation and deployment that the solution may have to use
a different reserved label (e.g. Label 1:

tensions to Label 1Ë should cease
This architecture also appears to subsume Y.111 since the
requirements can be met by the mechanism proposed here

11:
 & % 


1. One way delay measurement techniques need to be defined

although not required for initial design
Decision: architecture can not preclude a solution for one-way delay
measurement
o issues w/ 4-way delay

4. Measurement of packet loss to support PMs and detection of

degraded performance need to be defined
One approach is to encapsulate the appropriate Y.1:1 pdus in an AC

11Ë
) 

11*