MPLS Architectural Considerations

for a Transport Profile

ITU-T - IETF Joint Working Team

Dave Ward, Malcolm Betts, ed.

April 18, 2008

1
Table of Contents
• Executive Overview
– Recommendation
• Introduction and Background Material
• High Level Architecture
• OAM Requirements
• OAM Mechanisms and Baseline Use Cases
• Associated Channel Level (ACH)
• Forwarding and OAM
– LSP/PW OAM
– Use Case Scenario and Label Stack Diagrams
– Use of TTL for MIP OAM alert
– Packet Context
• Control Plane
• Survivability
• Network Management
• Summary
2
Executive Summary

3
 Recommendation
 Consensus on recommendation of Option 1
– Jointly agree to work together and bring transport requirements into the IETF and extend
IETF MPLS forwarding, OAM, survivability, network management and control plane
protocols to meet those requirements through the IETF 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:
• In the IETF: Definition of the MPLS “Transport Profile” (MPLS-TP)
• In the ITU-T:
– Integration 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 IETF MPLS
and Pseudowire architecture could be extended to support transport
functional requirements
– Therefore the team believed that there was no need for the analysis of any other option
4
 Future inter-SDO organizational structure
 It is proposed that the MPLS interop design team, JWT and ad hoc T-
MPLS groups continue as described in SG15 TD515/PLEN with the
following roles:
– Facilitate the rapid exchange of information between the IETF and ITU-T
– Ensure that the work is progressing with a consistent set of priorities
– Identify 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
 None of these groups has the authority to create or modify IETF RFCs or
ITU-T Recommendations
– Any such work will be progressed via the normal process of the respective
standards body
– Direct participation in the work by experts from the IETF and ITU-T is
required

5
Role for the IETF MPLS Interoperability Design Team
 The IETF MPLS Interoperability Design Team should be chartered to produce an
MPLS-TP architectural documentation hierarchy
– All documents would progress in appropriate IETF WGs according to the normal process
– The list of specific documents to be written in the IETF 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 RFCs 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 example of such a tree (by functional area) is below:

Requirements
(MPLS WG)

Transport Profile Architectural Framework

(MPLS WG)

Alert Label Definition ACH Definition Survivability Control Plane Network Management
(MPLS WG) (PWE3 WG) (MPLS WG) (CCAMP WG) (MPLS WG)
6
 Development of RFCs on MPLS-TP
 Work areas will be assigned to the appropriate IETF Working Groups to
develop the RFCs
– Working group charters and milestones will be updated to reflect the new
work
• Expected to be completed before IETF 72 (July 2008)
• This will include the list of documents in the architectural hierarchy
– WGs will appoint authors and where appropriate form design teams to
develop the RFCs
• It is assumed that ITU-T participants will be active members of these
design teams
• The draft will be reviewed by the ITU-T prior to completion of WG last call
– ITU-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 ITU-T SG/experts meeting
» Early communication via liaisons and the JWT should allow us to
avoid major comments on the final documents
• Apply for early allocation of RFC numbers and IANA codepoints once a
document has completed IESG review

7
Development of ITU-T Recommendations on MPLS-TP
 The normative definition of the MPLS-TP that supports the ITU-T transport
network requirements will be captured in IETF RFCs
 The ITU-T will:
– Develop Recommendations to allow MPLS-TP to be integrated with current
transport equipment and networks
• Including in agreement with the IETF, the definition of any ITU-T specific
functionality within the MPLS-TP architecture
– Via the MPLS change process (RFC 4929)
• Revise existing Recommendations to align with MPLS-TP
– It 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.8110.1)
• Equipment (e.g. G.8121)
• Protection (e.g. G.8131, G.8132)
• OAM (e.g. G.8113, G.8114)
• Network management (e.g. G.7710, G.7712, G.8151, …)
• Control plane (e.g. G.7713, G.7715, …)
– ITU-T Recommendations will make normative references to the appropriate
8
RFCs
Development of ITU-T Recommendations on MPLS-TP - 2
 Work areas will be assigned to the Questions as defined in COM 15 - C1
(Questions allocated to SG15)
– Work will be progressed in each question
• Direct participation by interested parties from the IETF is strongly
encouraged
• Draft versions of Recommendations will be provided to the IETF for
review via a liaison to a WG and/or via the JWT
– It is anticipated that approval will be using AAP as defined in
Recommendation A.8
• Interim WP meetings may be required to allow timely consent of
Recommendations that rely on normative references to RFCs
• Final text for consent will be provided to the IETF for review
– Initiation of the AAP process should be timed such that members can
base AAP comments on an appropriate IETF WG consensus review
of the consented text
– Early 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
IETF for review prior to the SG meeting

9
 Documentation schedule
 First draft of the Transport Profile Architectural Framework
– IETF 72 (July 2008)
– WG last call completion Q2/2009

 Draft to request new reserved label for MPLS TP alert

– IETF 72 (July 2008)

 RFCs on Alert Label and ACH definition

– WG last call completion Q2/2009

 Updated ITU-T Recommendations

– Q2/2009 (may need to schedule experts meeting/WP plenary to
avoid delaying consent to the October 2009 meeting of SG 15)

A significant amount of work is required to achieve these milestones

• We need to start immediately (May 2008)
• Need a commitment from interested parties to edit and drive the drafts

10
Introduction and
Background Material

11
 What am I reading?
 This presentation is a collection of assumptions, discussion points and
decisions that the combined group has had during the months of March and
April, 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 to meet those
requirements

 The output of this technical analysis is 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.
Option 1 was stated as preferred by the IETF and if it can be met; Option 2 will not
be explored 12
Some contributors to this architecture

 BT
 Verizon
 ATT
 NTT
 Comcast
 Acreo AB
 Alcatel-Lucent
 Cisco
 Ericsson
 Huawei
 Juniper
 Nortel
 Old Dog Consulting

13
 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 a technical analysis showing 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 14
MPLS - Transport Profile: What are the problems?
 Desire to statically configure LSPs and PWEs via the management plane
– Not solely via 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 don’t exist 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

15
MPLS -TP: 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 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 example when 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
Including scenarios of LAG or ECMP
Or create LSP/PWEs that don’t traverse links with LAG/ECMP

16
MPLS - 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 merging (e.g. no use of LDP mp2p signaling in order to avoid losing
LSP head-end information)

 Multicast is point to multipoint not MP2MP

17
MPLS - TP Requirements Overview .2
 OAM function responsible for monitoring the LSP/PWE
Initiates path recovery actions

 IP forwarding is not required to support of OAM or data packets

OOB management network running IP 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, IGP, RSVP, BGP, LDP)
 Mechanisms and capabilities must be able to interoperate with existing MPLS
and PWE control and forwarding planes

18
MPLS-TP Major Solution Constructs
NOTE: These two constructs were used as the basis for the Technical Feasibility study performed
by the ad hoc team, JWT and IETF MPLS Interoperability Design Team

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

(GE ACH)
Allows OAM packets to be directed to an intermediated node on a LSP/PWE
Via label stacking or proper TTL setting
Define a new reserved label (13 is suggested):
It is believed that Label 14 cannot be reused at this point

2. Generic Associated Channel (GE ACH) functionality supports the FCAPS

functions by carrying OAM, APS, ECC etc. packets across the network
Use of PWE-3 Associated Channel to carry OAM packets
GE ACH are codepoints from PWE ACH space but, not necessarily, for PWE purposes
GE ACH would be present for OAM of all LSPs

19
MPLS-TP Major Solution Observations

1. Bringing ACH 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

2. The same OAM mechanism (e.g. ACH) can be unified for LSPs and PWE
Enabling the same functionality for both and ease of implementation
Avoid breaking anything (e.g. ECMP)
There may be specific differences that are discovered in design phase
ACH functionality for LSPs should be limited to only OAM, APS & ECC
management channel data

3. A great deal of IETF protocol, design and architectural reuse can be

employed to solve the requirements
No fundamental change to the IETF MPLS architecture was found to be necessary

20
 MPLS-TP Alert Label Observations - 1

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

 One possibility would be to use the OAM Alert Label (label 14) to establish
this channel but:

 IETF WGs and ITU-T SGs were polled to find out the state of
implementation and deployment of Y.1711 and RFC3429
– The conclusion was that there are enough implementations and deployments
so that it is not possible to immediately deprecate Y.1711 and RFC3429

21
 MPLS-TP Alert Label Observations - 2
 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 13 has been suggested.
 The suggested roadmap is to gradually move all OAM
functionality defined by label 14 over to the new reserved label
 The specification of the new OAM channel must be
accompanied with a decision to stop further extension of OAM
based on label 14
Only maintenance operations continue

22
High Level Architecture

23
MPLS-TP service spectrum MPLS-TP solution must exist
over this spectrum

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

L3 only L1, L2, L3 Services L1, L2 Services

Pt-Pt, Pt-MPt, MPt-MPt Pt-Pt and Pt-MPt
Node/Link addressing Node/Link addressing Node/Link addressing
IP IP Multiple
Tunnel provisioning mechanisms
Tunnel provisioning mechanisms Tunnel provisioning mechanisms
IP based
RSVP-TE (RFC 3209 or RFC 3473) RSVP-TE (RFC 3473)
LDP or RSVP-TE (RFC 3209)
LSP creation External NMS External NMS
Dynamic only LSP creation LSP creation
Label space Dynamic and static coexistence Static and dynamic coexistence
Dynamic label space Label Space Label Space
Load Balancing
Split label space (static / dynamic) Static/dynamic label space
ECMP only
Load Balancing Load Balancing
Penultimate Hop Popping
PHP or no PHP ECMP and Non ECMP support Non ECMP support
LSP creation Penultimate Hop Popping Penultimate Hop Popping
Static and dynamic coexistence PHP or no PHP No PHP
PW setup mechanisms PW setup mechanisms Determine if PHP can be used
Static
Static PW setup mechanisms
PW control protocol (RFC 4447)
PW control protocol (RFC 4447) Static
PW control protocol (RFC 4447)

• IMPERATIVE MPLS-TP MUST BE ABLE TO INTEROPERATE IN AN L3 NETWORK

24
• MPLS-TP MUST ALSO SUPPORT AND CO-EXIST WITH EXISTING PWE-3 SOLUTIONS
 MPLS+TP Static Provisioning
Network Management System
Control Plane for PT2PT services

OAM OAM OAM

Edge Forwarding Forwarding Forwarding Edge

Tables Tables Tables

 Static provisioning and dynamic control plane

Requirements state that the solution must include static only provisioning
Any dynamic Control plane will be based on IETF solutions (GMPLS, 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 and driving switches between primary and
backup paths for the end to end path and path segments 25
 MPLS Transport Profile - Terminology
Emulated Service
Pseudo-wire
Multi-node PSN cloud

Attachment Attachment
Circuit Circuit
CE1 CE2
PE1 PW1 PE2

 Definition of an MPLS Transport Profile (TP) within IETF MPLS standards

Based on PWE3 and LSP forwarding architecture
IETF MPLS architecture concepts
 The major construct of the transport profile for MPLS are LSPs
PW are a client layer

26
 LSP example
- end to end and per carrier monitoring

PE Carrier 1 PE
Carrier 2

NNI NNI NNI

PE P P PE PE P PE

end to end LSP OAM

MEP MIP MIP MIP MIP MEP

segment
segment LSP OAM LSP OAM segment LSP OAM
(carrier 1) (inter carrier) (carrier 2)
MEP MIP MIP MEP MEP MEP MEP MIP MEP

• A segment is between MEPs

• OAM is end to end or per segment
• In SDH/OTN and Ethernet 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 MEPs i.e. per segment or end to end

Note: A policing function (traffic management/shaping) is normally co MEP: Maintenance End Point
located with a MEP at a business boundary (UNI/NNI) MIP: Maintenance Intermediate Point 27
 Bidirectional Paths

 External Static Provisioning

NMS responsible for configuration and ensuring bi-direction congruency
 If Dynamic Control Plane
GMPLS bidirectional RSVP for LSP path establishment

28
OAM requirements

29
 OAM Requirements

 Must be able to monitor LSP, PWE3

– Inter layer fault correlation
– Failure indication propagation across multiple segments
– Monitoring of Physical layer, layer 1, layer 2 is out of scope

 Packet loss rather than bit error based measurements/metrics for L2, LSP,
PWE3

 Per segment (aka tandem connection) and end to end

– Fault detection/isolation
– Recovery - protection switch or restoration

 A security architecture

30
 What is segment recovery?
End to End Protection

A B C D E F

Segment Protection

 End to End recovery:

– Fault detection and recovery of the end to end pseudo-wire
– Fault detection and recovery of the end to end LSP Segment recovery:
 Fault detection and recovery of a segment
– The recovery mechanism used in a segment is independent of other segments
 Segment constructs
– Hierarchical nested LSP: Existing construct
– MS-PW segment: Currently defined construct in PWE3
– Stacked TCM label (mapped 1:1 with corresponding LSP/PW)

31
 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?

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, no “show stoppers” found

32
OAM mechanisms

33
Overview: OAM hierarchy and mechanisms

A B C D E F
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)

 Non MPLS L2 connectivity : Native L2 solution 802.1ag (Not Discussed) , Non IP BFD
Failure propagation across layers is supported 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 : PWE3 Associated Channel 34

LSP monitoring example
- monitoring within carrier 1

Carrier 1

Region 1 Region 2

NNI INNI NNI

PE PE P PE PE P PE PE

end to end LSP OAM

MEP MIP MIP MIP

segment LSP
OAM
Carrier 1 LSP OAM segment (inter carrier)
MEP MIP MIP MEP MEP MEP

carrier 1 region 1 carrier 1 region 2

LSP OAM segment LSP OAM segment
MEP MIP MEP MEP MIP MEP

3 LSP OAM levels + PW OAM

• end to end LSP + 2 nested segment LSP levels (Carrier 1 + regions 1/2)
• Nested segments are supported by Tandem Connection Monitoring (TCM) in SDH/OTN and Y.1731
35
 Carrier 1 example MEPs/MIPs relationships
MEL x: Carrier 1
Carrier 1 LSP segment OAM

So Sk
Pushing a new label at the MEP So starts a server layer trail
that is terminated when the label is removed at the MEP Sk

MIP[1] verifies MEPx_So connectivity to MEPy_Sk

MIP[2] verifies MEPx_So connectivity to MEPz_So

MIP [1] MIP [2]

MEL y: Carrier 1, Region 1 MEL z: Carrier 1,Region 2

region 1 OAM region 2 OAM

So So Sk
Sk

MEP A MIP must support monitoring on the ingress port (logically before the label swap)
An implementation may optionally support a second MIP to monitor the egress port
How will this MIP be addressed
MIP

Trail
36
PW over LSP monitoring example
Attachment circuit
CE Attachment circuit CE
Carrier 1 Carrier 2

UNI NNI UNI

PE P P PE PE P PE

PW OAM (end to end no switching)

MEP MEP

end to end LSP OAM

MEP MIP MIP MEP

segment
segment LSP OAM LSP OAM segment LSP OAM
(carrier 1) (inter carrier) (carrier 2)
MEP MIP MIP MEP MEP MEP MEP MIP MEP

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

Note: A policing function (traffic management/shaping) is normally co MEP: Maintenance End Point
located with a MEP at a business boundary (UNI/NNI) MIP: Maintenance Intermediate Point 37
PW over LSP example with PW switching
Attachment circuit
CE Attachment circuit CE
Carrier 1 Carrier 2

UNI NNI UNI

PE P P PE-S PE-S P PE

end to end PW OAM (with PW switching)

MEP MIP MIP MEP

segment
segment LSP OAM LSP OAM segment LSP OAM
(carrier 1) (inter carrier) (carrier 2)
MEP MIP MIP MEP MEP MEP MEP MIP MEP

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

Note: A policing function (traffic management/shaping) is normally co MEP: Maintenance End Point
located with a MEP at a business boundary (UNI/NNI) MIP: Maintenance Intermediate Point 38
Associated Channel
Level (ACH)

39
Associated Channel Level ACH: Overview
 Generalised mechanism for carrying management / OAM information
OAM capabilities : Connectivity Checks (CC) and “Connectivity Verification” (CV)
Management information: Embedded Control Channel (ECC)
To support the Data Communications Network (DCN) and the Signalling Communication
Network (SCN) – see G.7712
APS information
 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 (DCN and SCN connectivity)
Via ECC 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)
We may want to define a vendor specific and experimental range
No Showstoppers found
40
 LSP monitoring and alarming
Generic Exception Label and Generic Associated Channel Proposal

MAC Header L1 L2 LFU/BoS Generic ACH Channel payload

0001 | Ver | Resv | Channel Type

 Assign a Transport Alert Label as a Label For yoU (LFU) from reserved label space:
Label 13 has been proposed because,
Label 14 has been allocated to Y.1711
Y.1711 arch fits within “ACH” architecture
 Bottom of Stack is always set on LFU in the transport profile

 Define a Generic Associated Channel function

Similar to the PWE-3 Associated Channel but doesn’t have to be associated with a PW
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 (MEP)
 Generalised Associated Channel defines what packet function using “channel type” field
Examples : What OAM function is carried, DCC, etc

41
 Pseudo-wire monitoring and alarming
PWE-3 Control Word and PW-Associated Channel

MAC Header L1 L2 PWL/BOS Control Word Payload

0000 | Flags | FRG | Length | Seq #

MAC Header L1 L2 PWL/BOS PWE-3 ACH Channel payload

0001 | Ver | Resv | Channel Type

This is a representation of what is in RFC 4385

42
Required Functionality demarked by
Associated Channel
 CV : Connectivity Verification (detection of configuration errors)
 PM: Performance of the path
 AIS: Alarm suppression
 CC : Continuity Check : Is the path present (may 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
 ECC
OSS and control plane communication
 APS
Protection switching coordination
 Accounting/Billing information
 Security exchange
 Extra codepoint space to define new or use existing protocols for other
functions 43
Associated Channel Functionality
Observations
 Existing MPLS LSP OAM uses an IP based control channel and
could be used for some OAM functions in transport networks
– e.g. CC/CV
– The new Alert label based control channel should be able to co-exist
with the existing MPLS LSP OAM functions and protocols

 OAM message formats and protocol details carried in the OAM

channel will be discussed in the design phase
– We must figure out what the OAM messages/protocols should be used
for the new requirements
– Decide whether LSP-Ping or BFD can or should be tweaked or not

44
 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
45
 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
46
Forwarding and OAM:
LSPs / PW
OAM and Label Stacks

47
 Scope of next slides

 Slides cover on MEP to MEP and MEP to MIP monitoring

Detailed OAM packet walkthrough not yet covered in this slide-set
For MIP monitoring traceroute or loopback is executed and TTL set accordingly
 Introduce concept of LSP/PW TCM label:
This is a label to indicate a tandem monitoring session context
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 multiplexing
Need mechanism to bind TCM label to underlying LSP or PW being monitored
 MEP to MIP
MEP sets the TTL of the LSP, TCM or PW label so that it will expire when the target
MIP is reached
 PHP
No Showstoppers found

48
Notation and color conventions
• [Destination][(using label provided by)][optionalFEC]/[StackBit]
• Thus D(E)/0 means Destination is D, using label provided by (E) - i.e. c is
the tunnel next hop and the Sbit is 0 - i.e. not bottom of stack.
• Thus E(E)p/1 means Destination is E, using label provided by (E) the FEC
is a pseudowire and the Sbit is 1, i.e. bottom of stack
• Special Labels and terms
LFU = Label For yoU - OAM alert label
Ach = Associated Channel Header
CW = Control Word
P = PW FEC
Co lo r Co n ven tio n s
LSP ta n d em OA M la b el
LSP la b el
PW ta n d em OA M la b el
PW la b el
PW co n tro l w o rd
La b el Fo r yo U
A CH
49
Scenarios
 SS-PW over intra-domain LSP
– No TCM OAM
–TCM-LSP OAM
 SS-PW over inter-domain LSP
–LSP, TCM LSP & PW OAM
 Intra-domain MS-PW
–MS-PW TCM OAM
 Intra-domain MS-PW
–LSP OAM and TCM-MS-PW OAM
 Inter-provider MS-PW
–PW E2Eand PW TCM OAM
 SS-PW over Intra-domain LSP
–LSP MEP->MIP OAM using TTL
 Intra-domain MS-PW
–MS-PW OAM: PW MEP-MIP, No TCM
 Intra-domain MS-PW
–MS-PW OAM: TCM MEP->MIP, plus E2E PW

50
 Segment LSP setup

Starting Point
A B C D E
L1/L2 L1/L2 L1/L2 L1/L2

end-to-end LSP
Pseudo-wire

Final Point
A B C D E
L1/L2 L1/L2 L1/L2 L1/L2

Segment LSP

New end-to-end (tunnelled) LSP

Pseudo-wire

Objective:
Use bridge-and-roll with make-before-break mechanism
to ensure transition 51
Segment LSP setup – G.805 view
Starting Point
End to End LSP

A B C D E
LC LC LC LC

Final Point
New end-to-end (tunnelled) LSP

A B D E
LC LC LC
Segment LSP

C
LC – Link Connection
LC LC

52
 Procedural Ordering Overview

 Step 1 : establish the segment LSP

Question : can segment LSP and existing end-to-end LSP share bandwidth?
 Step 2 : establish a new end-to-end LSP and which must be tunnelled in the
segment LSP
Use MBB procedures (for sharing resources between existing and new end-to-end
LSP).
 Step 3 : Perform switchover after Resv is received in A
ITU-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 4 : Tear down the old end-to-end LSP

53
 LFU – Label For You (label 13)
ACh – Associated Channel
SS-PW, LSP OAM (no TCM) CW – Control Word

A B C D E

Section OAM LFU/1 LFU/1 LFU/1 LFU/1

ACh ACh ACh ACh

E2E (A to E)
E(B)/0 E(C)/0 E(D)/0 E(E)/0
LSP OAM LFU/1 LFU/1 LFU/1 LFU/1
ACh ACh ACh ACh

E2E (A to E)
E(B)/0 E(C)/0 E(D)/0 E(E)/0
PW OAM E(E)p/1 E(E)p/1 E(E)p/1 E(E)p/1
ACh ACh ACh ACh

Non OAM Data Frames

E(B)/0 E(D)/0 E(D)/0 E(E)/0 E2E LSP
E(E)p/1 E(E)p/1 E(E)p/1 E(E)p/1 SS-PW
CW CW CW CW
54
SS-PW over intra-domain LSP LFU – Label For You (label 13)
ACh – Associated Channel
CW – Control Word
LSP, TCM-LSP & PW OAM

A B C D E

PE P P P PE

TCM LSP label does not

Section OAM LFU/1 LFU/1 LFU/1 LFU/1 represent a true LSP
ACh ACh ACh ACh No LSP Mux (1:1
mapping)

TCM-LSP OAM D(C)/0 D(D)/0

LFU/1 LFU/1
ACh ACh

E2E (A to E) D(C)/0 D(D)/0

E(B)/0 E(D)/0 E(D)/0 E(E)/0
LSP OAM LFU/1 LFU/1 LFU/1 LFU/1
ACh ACh ACh ACh

E2E (A to E) D(C)/0 D(D)/0

E(B)/0 E(D)/0 E(D)/0 E(E)/0
PW OAM E(E)p/1 E(E)p/1 E(E)p/1 E(E)p/1
ACh ACh ACh ACh

Non OAM Data Frames D(C)/0 D(D)/0 TCM-LSPs

E(B)/0 E(D)/0 E(D)/0 E(E)/0 E2E LSP
E(E)p/1 E(E)p/1 E(E)p/1 E(E)p/1 SS-PW
CW CW CW CW
55
 LFU – Label For You (label 13)
SS-PW over inter-provider LSP ACh – Associated Channel
CW – Control Word
LSP, TCM-LSP & PW OAM PB = Provider Border LSR

Provider A Provider B
A B C D E F

PE P PB PB P PE

Section OAM LFU/1 LFU/1 LFU/1 LFU/1 LFU/1

ACh ACh ACh ACh ACh
One hop TCM-
LSP OAM and
Section OAM
TCM-LSP OAM C(B)0 C(C)/0 F(E)/0 F(F)/0 would not usually
LFU/1 LFU/1 LFU/1 LFU/1 run concurrently
ACh ACh ACh ACh

E2E LSP OAM C(B)0 C(C)/0 F(E)/0 F(F)/0 LSPs stitched

C(C)/0
LFU/1
C(C)/0
LFU/1
D(D)/0
LFU/1
F(F)/0
LFU/1
F(F)/0
LFU/1
in C and D
ACh ACh ACh ACh ACh
From DP
perspective, LSP
E2E PW OAM C(B)0 C(C)/0 F(E)/0 F(F)/0 stitching is a
C(C)/0 C(C)/0 D(D)/0 F(F)/0 F(F)/0 normal label
F(F)p/1 F(F)p/1 F(F)p/1 F(F)p/1 F(F)p/1 swap operation
ACh ACh ACh ACh ACh

Non OAM Data Frames C(B)0 C(C)/0 F(E)/0 F(F)/0 TCM-LSPs

C(C)/0 C(C)/0 D(D)/0 F(F)/0 F(F)/0 E2E LSP
F(F)p/1 F(F)p/1 F(F)p/1 F(F)p/1 F(F)p/1 SS-PW
CW CW CW CW CW
56
Intra-domain MS-PW
LFU – Label For You (label 13)
ACh – Associated Channel
CW – Control Word
MS-PW & TCM-MS-PW OAM

A B C D E
B and D are S-PEs
T-PE S-PE P S-PE T-PE

Section OAM LFU/1 LFU/1

LFU/1 LFU/1
ACh ACh ACh ACh LFU not needed
because D(D)p is
TCM PW label does not bottom of stack
LSP OAM not represent a true PW and Ach has been
No PW Mux (1:1 negotiated
shown here mapping)

PW TCM
TCM-PWE (B to D) D(C)/0 D(D)/0
OAM D(D)p/1 D(D)p/1 Use of pseudo-wire TCM
ACh ACh
labels to be further spec’d.

E2E (A to E) D(C)/0 D(D)/0

B(B)/0 D(D)p/0 D(D)p/0 E(E)(0)
PW OAM E(B)p/1 E(D)p/1 E(D)p/1 E(E)p/1
ACh ACh ACh ACh

E(B)p-E(D)p pw label
Non OAM Data Frames B(B)/0 D(C)/0 D(D)/0 E(E)(0) LSPs swap
D(D)p/0 D(D)p/0 TCM-PWE D(D)p pw label push
E(B)p/1 E(D)p/1 E(D)p/1 E(E)p/1 MS-PW D(C) lsp label push
CW CW CW CW
57
Intra-domain MS-PW
LFU – Label For You (label 13)
ACh – Associated Channel
CW – Control Word
LSP, MS-PW & TCM-MS-PW OAM

A B C D E
B and D are S-PEs
T-PE S-PE S-PE T-PE

Section OAM LFU/1 LFU/1 LFU/1 LFU/1

ACh ACh ACh ACh
One hop LSP OAM
and Section OAM
LSP OAM would traditionally
B(B)/0 D(C)/0 D(D)/0 E(E)/0
LFU/1 LFU/1 LFU/1 LFU/1 not run concurrently
ACh ACh ACh ACh

TCM-PWE (B to D) D(C)/0 D(D)/0 Use of pseudo-wire TCM

OAM D(D)p/1 D(D)p/1
ACh ACh
labels to be further spec’d

E2E (A to E) D(C)/0 D(D)/0

B(B)/0 D(D)p/0 D(D)p/0 E(E)/0
PW OAM E(B)p/1 E(D)p/1 E(D)p/1 E(E)p/1
ACh ACh ACh ACh
LFU not needed
because D(D)p/1
LSPs bottom of stack
Non OAM Data Frames B(B)/0 D(C)/0 D(D)/0 E(E)/0
and negotiated
D(D)p/0 D(D)p/0 TCM-PWE
E(B)p/1 E(D)p/1 E(D)p/1 E(E)p/1 MS-PW Ach
CW CW CW CW
58
Inter-provider MS-PW LFU – Label For You (label 13)
ACh – Associated Channel
CW – Control Word
LSP, MS-PW & TCM-MS-PW OAM
Provider A Provider B
A B C D E F

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

Section OAM LFU/1 LFU/1 LFU/1 LFU/1 LFU/1

ACh ACh ACh ACh ACh
One hop TCM-
LSP OAM and
Section OAM
LSP OAM C(B)0 C(C)/0 D(D)/0 F(E)/0 F(F)/0 would
LFU/1 LFU/1 LFU/1 LFU/1 LFU/1 traditionally not
ACh ACh ACh ACh ACh run concurrently

TCM MS-PW C(B)/0 C(C)/0 F(E)/0 F(F)/0

PW
OAM C(C)0
ACh
C(C)/0 F(F)/0 F(F)/0 switching in
ACh ACh ACh
C and D

E2E PW OAM C(B)/0 C(C)/0 F(E)/0 F(F)/0

C(C)0 C(C)/0 D(D)/0 F(E)/0 F(F)/0
F(C)p/1 F(C)p/1 F(D)p/1 F(E)p/1 F(F)p/1
ACh ACh ACh ACh ACh

Non OAM Data Frames C(B)/0 C(C)/0 F(E)/0 F(F)/0 LSP tunnel
C(C)0 C(C)/0 D(D)/0 F(F)/0 F(F)/0 TCM MS-PW
F(C)p/1 F(C)p/1 F(D)p/1 F(F)p/1 F(F)p/1 MS-PW
CW CW CW CW CW
59
SS-PW over Intra-domain LSP LFU – Label For You (label 13)
ACh – Associated Channel
CW – Control Word
LSP MEP->MIP OAM using TTL T = TTL

A B C D E
PE P PE
MEP MIP MEP

Section OAM LFU/1 LFU/1 LFU/1 LFU/1

ACh ACh ACh ACh

LSP label TTL

expires, OAM pkt
MEP-MIP (A to C) E(B)/0 T=2 E(C)/0 T=1
LFU/1 LFU/1 pops out at MIP
LSP OAM ACh
ACh

TTL > Max Hops OAM

pkt passes E2E
E2E (A to E) (standard TTL setting)
E(B)/0 T=255 E(C)/0 T=254 E(D)/0 T=253 E(E)/0 T=252
LSP OAM LFU/1 LFU/1 LFU/1 LFU/1
ACh ACh ACh ACh

E2E (A to E)
E(B)/0 E(D)/0 E(D)/0 E(E)/0
PW OAM E(E)p/1 E(E)p/1 E(E)p/1 E(E)p/1
ACh ACh ACh ACh

Non OAM Data Frames

E(B)/0 E(D)/0 E(D)/0 E(E)/0 E2E LSP
E(E)p/1 E(E)p/1 E(E)p/1 E(E)p/1 SS-PW
CW CW CW CW
60
Intra-domain MS-PW LFU – Label For You (label 13)
ACh – Associated Channel
MS-PW MEP->MIP OAM using TTL (No TCM) CW – Control Word
T = TTL
(See draft-ietf-pwe3-segmented-pw-)
B,C and D are S-PEs
A B C D E A, E are MEPs
T-PE S-PE S-PE S-PE T-PE
MEP MIP MIP MIP MEP

Section OAM LFU/1 LFU/1

LFU/1 LFU/1
ACh ACh ACh ACh

(LSP OAM not shown) PW label TTL expires at S-PE MIP.

PW pkt is not immediately discarded.
ACH examined and sent to ctrl plane
if identified as OAM, as per draft-ietf-
MEP-MIP (A to D) B(B)/0 C(C)/0 D(D)/0
pwe3-segmented-pw-05.txt & draft-
PW OAM E(B)p/1 T=3 E(C)p/1 T=3 E(D)p/1 T=1 hart-pwe3-segmented-pw-vccv-02.txt
ACh ACh ACh

E2E (A to E)
B(B)/0 C(C)/0 D(D)/0 E(E)(0)
PW OAM E(B)p/1 T=255 E(C)p/1 T=254 E(D)p/1 T=253 E(E)p/1 T=253
ACh ACh ACh ACh

Non OAM Data Frames B(B)/0 C(C)/0 D(D)/0 E(E)(0) LSPs

E(B)p/1 E(C)p/1 E(D)p/1 E(E)p/1 MS-PW
CW CW CW CW

61
 LFU – Label For You (label 13)
Intra-domain MS-PW ACh – Associated Channel
CW – Control Word
TCM-MS-PW MEP->MIP OAM using TTL T = TTL

A B C D E
B,C and D are S-PEs
T-PE S-PE S-PE S-PE
MEP T-PE
MIP MIP MEP

Section OAM LFU/1 LFU/1

LFU/1 LFU/1
ACh ACh
(LSP OAM not shown) ACh ACh

TCM PW label
expires, OAM pkt
TCM-PWE (A to C) B(B)/0 C(C)/0 pops out at MIP
OAM D(B)p/1 T=2 D(C)p/1 T=1
ACh ACh
TCM PW label
TCM-PWE (A to D) causes OAM to
B(B)/0 C(C)/0 D(D)/0 terminate at MEP
OAM D(B)p/1 T=255 D(C)p/1 T=254 D(D)p/1 T=253
ACh ACh ACh

E2E (A to E) B(B)/0 C(C)/0 D(D)/0

D(B)p/0 D(C)p/0 D(D)p/0 E(E)(0)
PW OAM E(B)p/1 E(C)p/1 E(D)p/1 E(E)p/1 TCM PW label
ACh ACh ACh ACh
swaps at each S-PE

Non OAM Data Frames B(B)/0 C(C)/0 D(D)/0 E(E)(0) LSPs

D(B)p/0 D(C)p/0 D(D)p/0 TCM-PWE
E(B)p/1 E(C)p/1 E(D)p/1 E(E)p/1 MS-PW
CW CW CW CW
62
MEP to MIP OAM:
TTL Processing for PWs and LSPs

 In 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

Scenarios to be added:
a) LSP on FRR path (both facility and detour)
b) b) PW with ACH processing (no need for LFU, so processing
steps are slightly different from LSP processing)
63
Short Pipe Model with Nested TTL and No PHP Processing

A B C D E F G H

From the TTL perspective, the

PW LSP
treatment for a Pipe Model LSP is
LSP LSP identical to the Short Pipe Model
TTL=n TTL=n-1 3 without PHP (RFC3443).
1 2

Stack going into pipe Stack received at H

TTL=m TTL=m-1 TTL=m-1 TTL=m-2

TTL=k TTL=k-1 TTL=k-2 TTL=k-2 TTL=k-2 TTL=k-2 TTL=k-3 TTL=k-3

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

Bottom of stack 64
 Nested LSP TTL Processing (1)

 The previous picture shows

PW: Pseudowire
LSP1: Level 1 LSP (PW is carried inside)
LSP2: Level 2 LSP (LSP1 is nested inside)
LSP3: Level 3 LSP (LSP2 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
LSP2 TTL is initialized to m at C
LSP3 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 H
LSP1 TTL is decremented at B, H
LSP2 TTL is decremented at G
LSP3 TTL is decremented at E, F

65
 Nested LSP TTL Processing (2) - pseudo code

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

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

66
 Nested LSP TTL Processing (3) continued pseudocode

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

67
 Multi-Segment PW TTL Processing

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- …
68
 Cascaded LSP TTL Processing

 The previous picture shows

PW1: Pseudowire
LSP1: Level 1 LSP (PW1 is carried inside)
PW2: Pseudowire (PW1 is stitched to PW2)
LSP2: Level 1 LSP (PW2 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
PW2 TTL is initialized to m at C
Is m = j-1?
LSP2 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
PW2 TTL is decremented at E
LSP2 TTL is decremented at D, E

69
 ECMP Considerations

 OAM and Data MUST share fate.

 PW OAM fate shares with PW through the first nibble mechanism (RFC4928)
and hence is fate shared over any MPLS PSN.
 Fate sharing is not assured for the MPLS Tunnel OAM/Data in the presence of
ECMP.
 The current MPLS Transport Profile ensures OAM/Data fate sharing for the
MPLS tunnel by excluding the use of MPLS ECMP paths (for example by only
using RSVP or GMPLS signaled MPLS tunnels)
 There is a requirement to improve IETF MPLS OAM. This will require the
problem of fate sharing in the presence of ECMP to be addressed.
 If the OAM/DATA fate sharing problem is solved for MPLS ECMP, then the
Transport Profile may be extended to take advantage MPLS paths that employ
ECMP.

70
 RFC4928 Mechanism

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)
 Recognized 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
RFC 4928 implemented through use of control word and PWE-3 ACH
RFC 4385 for Control Word and PW associated Channel formats
NOTE: joint proposals to be made on “Load Balance” label technology in PWE3 WG 71
 Segment LSP operations
LFIB:CD-DE

D
LFIB:AB-BC

B
DE, PW-L

PW-L, AB
Segment Primary Path LFIB:BC-CD
E
A LFIB:XY-YZ
YZ, PW-L

PW-L, AW

Segment Backup Path LFIB:WX-XY

LFIB:AW-WX
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 (using a nested LSP)
 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
72
 End to End LSP operations

LFIB:CD-DE
LFIB:AB-BC LSP OAM
DE, PW-L

PW-L, AB
Primary Path LFIB:BC-CD
E
A LFIB:XY-YZ
YZ, PW-L

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 73
PHP

 It is believed that PHP may be able to be used in the

transport profile.
 The issue is how do we maintain the packet context for
both the data and OAM
described on the following 3 slides

 One scenario follows:

SS-PW, LSP and TCM-LSP

74
Packet Context
 OAM operations require packet context.
 Work to date has proposed that this is supplied by the
label value and hence precludes the use of PHP.
 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 PHP which has cost and applicability implications
for the OAM
–Label errors may produce complex network issues
 Other context indicators may be available that allow the
lifting of the PHP constraint (at least as an option).

75
Alternative Context Indication

 In the case of IP the IP address provides context

 In the case of PW, the PW label provides context
 In the case of an OAM pkt, an identifier can provide
context
 The issue are:
– OAM and data must fate share;
– Need to provide context identification for performance
monitoring of data packets, or the need to provide an alternative
mechanism that provides satisfactory performance information.

76
 Use of alternate context mechanisms
 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 PHP that needs to be fully
understood and accepted.
 During the design phase we need to:
– Understand the costs, limitations, vulnerabilities and advantages of the PHP
and non-PHP approaches
– Either
1. Confirm label as context identifier and hence confirm PHP restriction
2. Propose an alternative mechanism that satisfies all needs and which
permits PHP
3. Propose the specification of a PHP and non-PHP method with appropriate
applicability statements.

77
SS-PW, LSP and TCM-LSP OAM - LFU – Label For You (label 13|14)
ACh – Associated Channel
CW – Control Word
PHP
A B C D E

Section OAM Do we need an ACh Ethertype?

ACh ACh ACh ACh

TCM-LSP OAM D(C)/0

LFU/1 LFU/1
ACh ACh

E2E (A to E) D(C)/0
E(B)/0 E(D)/0 E(D)/0
LSP OAM LFU/1 LFU/1 LFU/1 LFU/1
ACh ACh ACh ACh

E2E (A to E) D(C)/0
E(B)/0 E(D)/0 E(D)/0
PW OAM E(E)p/1 E(E)p/1 E(E)p/1 E(E)p/1
ACh ACh ACh ACh

Non OAM Data Frames D(C)/0 TCM-LSPs

E(B)/0 E(D)/0 E(D)/0 E2E LSP
E(E)p/1 E(E)p/1 E(E)p/1 E(E)p/1 SS-PW
CW CW CW CW
78
Control Plane

79
 Conclusions/Recommendations

 Control plane sub-team sees no show-stoppers

Existing IETF protocols can be used to provide required function
Transport network operation
DCN/SCN operation
IETF GMPLS protocols already applied to ASON architecture
Any protocol extensions needed will be easy to make
Configuration of MEPs/MIPs and activation of monitoring
Support of bridge and roll capability
Allows Tandem connection monitoring to be added to an existing
LSP without disruption to the service

80
 Discussion
 Transport profile should meet the requirements of the ASON architecture
Use IETF protocol suite given it is used for ASON
GMPLS RSVP-TE for LSP signaling
GMPLS OSPF-TE and ISIS-TE for LSP TE information distribution
LDP will be used for PW setup (as part of client set up process)
 DCN/SCN
IP-based DCN/SCN
ACH defines ECC
Can have as many channels and protocols as necessary and therefore could
support the SCN
Must have policing for DCN/SCN
IS-IS or OSPF running in DCN to provide DCN topology information
 Connectivity discovery and verification
Could use LMP if native mechanisms not adequate

81
 AC – Attachment Circuit

Control Plane View of NNI – Network-Network Interface

I-NNI – Internal NNI

Inter-provider MS-PW
E-NNI – External NNI
SCN – Signaling Communication Network
SCN-GW Gateway
T-LDP – Targeted LDP

SCN-A SCN
GW
SCN-B

Provider A Provider B
AC CP I-NNI CP I-NNI CP E-NNI CP I-NNI CP I-NNI CP AC

T-PE S-PE S-PE T-PE

C1 A B C D E F C2

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-TE RSVP-TE RSVP-TE RSVP-TE RSVP-TE RSVP-TE RSVP-TE

Data Frames C(B)/0 C(C)/0 D(D)/0 F(E)/0 F(F)/0 LSP tunnel

F(C)p/1 F(C)p/1 F(D)p/1 F(F)p/1 F(F)p/1 MS-PW
CW CW CW CW CW

82
ASON Call/Connection CCC – Client Call Controller
NCC – Network Call Controller
Model CC – Connection Controller
UNI – User-Network-Interface
NNI – Network-Network Interface
I-NNI – Internal NNI
E-NNI – External NNI

SCN-A SCN
GW
SCN-B

Provider A Provider B
UNI CP I-NNI CP I-NNI CP E-NNI CP I-NNI CP I-NNI CP UNI

T-PE S-PE S-PE T-PE

C1 A B C D E F C2

Call Call Segment A Call Call Segment B Call

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

CCCC1 NCCA NCCC NCCB NCCB CCCC2

CCC1 CCA CCB CCC CCD CCE CCF CCC2

Call Connection
Signaling Signaling

83
Survivability

84
 Advice

 Survivability sub team has not found any issues that

prevent the creation of an MPLS transport profile
No showstoppers found

 Therefore option 1 can be selected

 Summary of discussion
– Three potential solutions have been identified
– Each solutions has different attributes and advantages
– Further work in the design phase should eliminate one or more
of these options and/or provide an applicability statement

85
 Discussion

 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
 Each segment can act independently
Multiple potential solutions including
Native IETF mechanisms
Carry G.8131/G.8132 PDUs in an ACH

86
 Discussion - 2
 Native 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 exit preventing the 2x bandwidth in other wrapping
repair technologies
Must add notion of DOWN and ADMINDOWN (e.g. standby bit)
 ITU-T G.8132 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
 MPLS ring protection strategies provide necessary functionality and option 1
can be recommended but, there appears to be cases where G.8132 may
provide additional functionality that may be incorporated and specified
We have found no showstoppers
87
 Requirements summary - Rings
 MPLS-TP ring protection shall satisfy the following:
– Less than 50 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
• Fiber, nodes or both
• Failures 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

 ITU-T References:
ETSI TS 101 009, Section 6.2.2
ITU-T G.841, Section 7.2.2
Telcordia GR-1230, Section 5
ITU-T Draft G.8132, Section 7

88
 Requirements summary - Linear
 MPLS-TP linear protection shall satisfy the following:
– Less than 50 ms switching time
– Protect p-t-p and p-t-mp connections
• P-2-MP LSP protection based on detours is covered in RFC 4875, though an example is
not included here
– 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
 ITU-T References:
– G.808.1 – Generic linear protection
– G.8131 T-MPLS linear protection
 Not addressed
Reuse (or simplify) the mechanism used for Ring protection? 89
 Example Scenarios in the following slides

 Basic restoration in a ring

 MPLS protection scenarios

– Facility Bypass
– Restoration using detours
• Sub-optimal
• Optimized

 ITU-T G.8132 TM-SPRing protection overview

– Label Allocation
– OAM and APS messaging
– P2P
– P2MP
– Multiple failures

90
 MPLS Facility Bypass Example

B B
C C
A A

D D
F F
E E

Example:
 Assume ingress to ring is at A and egress is at E
 Facility bypass (B-A-F-E-D-C) is established to protect link B-C
 Link B-C in the ring goes down
 Facility bypass protects failure of link B-C with the red path to the merge point (C)
 Emulates 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) 91
 AE = Initial clockwise ring

MPLS Facility Bypass Label Stack .1 AE = bypass for AE

Initial State, unidirectional LSP Spin is relative to

initial LSP traffic flow
AE
E(C)/0
Payload
AE A(A)/0 = bypass label
E(B)/0 B
Payload = LSP payload
Payload

C
AE AE
E(D)/0
A C(A)/0
Payload

AE
C(C)/0
PHP may or may
AE not be used:
C(F)/0 TBD
D
AE
C(D)/0
AE AE
F C(E)/0 E(E)/0
Payload

92
MPLS Facility Bypass Label Stack .2 AE = Initial clockwise ring
AE = bypass for AE

Failure state, Unidirectional LSP Spin is relative to

initial LSP traffic flow

AE
E(B)/0
Payload B A(A)/0 = bypass label
CB bypass
label pushed by C

AE
C
C(A)/0
E(C)/0
AC A Payload AE
AE E(D)/0
(PE) C(C)/0 Payload
E(C)/0
Payload
AE
C(F)/0 PHP may or may
E(C)/0 not be used:
Payload TBD
AE D
C(D)/0
E(C)/0
Payload

F AE AE
C(E)/0 E(E)/0
E(C)/0 Payload
Payload
E
(PE)

AC
93
 AE = Initial clockwise ring
MPLS Facility Bypass Label Stack EA = Initial anticlockwise ring
AE = bypass for AE
Failure state, Bidirectional LSP EA = bypass for EA
Spin is relative to
initial LSP traffic flow
AE EA
E(B)/0 A(A)/0
Payload Payload B A(A)/0 = bypass label
CB bypass
label pushed by C

AE EA
C
C(A)/0 B(B)/0
E(C)/0 A(B)/0
AC A Payload Payload AE EA
AE EA E(D)/0 A(C)/0
(PE) C(C)/0 B(D)/0 Payload Payload
E(C)/0 A(B)/0
Payload Payload
AE EA
C(F)/0 B(A)/0 PHP may or may
E(C)/0 A(B)/0 not be used:
Payload Payload TBD
AE EA D
C(D)/0 B(E)/0
E(C)/0 A(B)/0
Payload Payload

F AE EA AE EA
C(E)/0 B(F)/0 E(E)/0 A(D)/0
E(C)/0 A(B)/0 Payload Payload
Payload Payload
E
(PE)

AC
94
 MPLS 1:1 Detours
- Optimized Restoration
Entry Point to repair path

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

Example
 Assume ingress to ring is at A and egress is at E
 Detour established to protect link B-C merges with primary path at E, resulting in protection through B-A-F-E
 Link B-C in the ring goes down
 Detour carries traffic to E
 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
95
 AE = Initial clockwise ring

MPLS 1:1 Detours - Label Stacks .1 EA = Initial anticlockwise ring

AE = detour for AE
Initial state, Unidirectional LSP EA = bypass for EA
Spin is relative to
AE initial LSP traffic flow
E(C)/0
Payload
AE A(A)/0 = detour label
E(B)/0
Payload
B

C
AE
E(D)/0
E(A)/0 Payload
A E(B)/0

E(F)/0

E(C)/0 D
E(E)/0
AE
E(E)/0
F Payload

Primary-detour merge point

96
 AE = Clockwise ring
MPLS 1:1 Detours - Label Stacks .2 AE = bypass for AE

Failure state, Unidirectional LSP Spin is relative to

initial LSP traffic flow

A(A)/0 = detour label

AE
E(B)/0 B
Payload

C
AE
AC A E(A)/0
Payload

Payload AE
E(F)/0
Payload
D

F
AE
E(E)/0
Payload
E

AC
97
 AE
C ==Clockwise
Clockwisering
ring
MPLS 1:1 Detours - Label Stacks EA
A ==Anticlockwise
Anticlockwisering
ring
EA
C ==Clockwise
bypass fordetour
AE
Failure state, Bidirectional LSP AE
A ==Anticlockwise
bypass for EAdetour
Spin
Direction
is relative
relative
to to
initial
LSP traffic
LSP traffic
flow flow

A(A)/0 = detour label

AE EA
E(B)/0 A(A)/0 B
Payload Payload

C
AE EA
AC A E(A)/0 B(B)/0
Payload Payload

AE EA
E(F)/0 B(A)/0
Payload Payload
D

F AE EA
E(E)/0 B(F)/0
Payload Payload

E Open issue for discussion: How to force both ends

pick same merge point for each direction?

AC
98
Open questions on MPLS Facility bypass/detours

 No showstoppers but, to be solved in the design phase

– Loop avoidance
– Implementation of bi-direction switching
– Implementation of manual switching/operator requests
– Implementation of switching priorities
• Faults conditions, operator commands
– Node configuration so that it is aware of the ring
– Multiple failures
• Ring segmentation
– p2mp LSPs

99
 Review: TM-SPRing labels allocation

Working connection Add

Protection connection
a
Labels allocation and association
p Node 1 k
Wk Labels Pr Labels
Node 2 Node 6
a p↔a
b o l o↔b
b
c n↔c
Node 3 Node 5 Drop
d m↔ d
n Node 4 m
l ↔ nil
c d
k ↔ nil
Working to protection
labels associations

100
Review: TM-SPRing OAM monitoring and APS
messages
 Monitoring:
APS controller
APS messages – Each section (span) in the ring is
monitored by sending CV OAM with
periodicity of 3.3ms
– Span failures are detected as absence of 3
consecutive CV frames
Node 1
Node 2 Node 6
 APS:
Idle state at all nodes – Each node has an APS controller that
sends and receives APS PDUs using an
Node 3 Node 5 ACH
– In normal state APS controller generates
Node 4
NR (no request) PDUs to its neighbours in
both directions
– When there is no failure each node in the
Monitoring point
ring is in the Idle 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 NR PDUs to their neighbours

101
 TM-SPRing point-to-point example
Fiber failure Node failure

Add Add
4 ‒ Pass-through state at 3 ‒ SF PDU by 4 ‒ Pass-through state
nodes 2-1-6-5 nodes 2-4 at nodes 1-6-5

Node 1 Node 1
Node 2 Node 6 Node 2 Node 6
3 ‒ SF PDU
by nodes 3-4 2 ‒ Switching state 2 ‒ Switching state at
at nodes 3-4 nodes 2-4

Node 3 Node 5 Drop Node 3 Node 5 Drop

Node 4 Node 4
1 ‒ Node 3
1 ‒ Fiber failure
failure 3 ‒ SF PDU by 3 ‒ SF PDU by
nodes 3-4 nodes 2-4

When failure occurs:

• The nodes adjacent to the failure enter the switching state and sends APS SF
PDUs to neighbors
• When the other nodes in the ring receive the SF PDU they enter pass-through
state (i.e. allow forwarding on the protection LSP) and forward the APS PDUs
without modification
102
 TM-SPRing point-to-multipoint example
Fiber failure Node failure

Add Add
4 ‒ Pass-through state at 4 ‒ Pass-through state
Drop and nodes 2-1-6-5 Drop and at nodes 1-6-5
continue continue

Node 1 Node 1
Node 2 Node 6 3 ‒ SF PDU by Node 2 Node 6
nodes 2-4
3 ‒ SF PDU by
nodes 3-4 2 ‒ Switching state 2 ‒ Switching state at
at nodes 3-4 nodes 2-4

Node 3 Node 5 Drop Node 3 Node 5 Drop

Node 4 Node 4
1 ‒ Node 3
1 ‒ Fiber failure
failure 3 ‒ SF PDU by 3 ‒ SF PDU by
nodes 3-4 nodes 2-4
Drop and Drop and
continue continue

The same mechanism:

• For p-t-p and p-t-mp connections
• For fiber or node failure
• For single or multiple failures

103
TM-SPRing multiple failures example
Multiple failures, p-t-p Multiple failures, p-t-mp
3 ‒ SF PDU 3 ‒ SF PDU by
by nodes 1-4 Add nodes 1-4 Add
4 ‒ Pass-through 4 ‒ Pass-through state
1 ‒ Fiber state at nodes 6-5 1 ‒ Fiber at nodes 6-5
failure failure
Node 1 Node 1
Node 2 Node 6 Node 2 Node 6

2 ‒ Switching state 2 ‒ Switching state at

at nodes 1-4 nodes 1-4

Node 3 Node 5 Drop Node 3 Node 5 Drop

Node 4 Node 4
1 ‒ Fiber 1 ‒ Fiber
failure failure
3 ‒ SF PDU by 3 ‒ SF PDU by
nodes 1-4 Drop and nodes 1-4
continue

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

104
Network Management

105
Advice

 Network Management sub team has not found any

issues that prevent the creation of an MPLS transport
profile
 Therefore option 1 can be selected
No Showstoppers found

106
 Conclusions - I

 Need to be able to provision and manage a LSP or PW across a network where some
segments are managed by IETF (e.g. netconf) and other segments that are managed
by ITU/TMF (XML/CORBA) interfaces.
– LSP establishment
• MPLS management in the IETF already supports the ability to independently
setup LSP segments (using different tools) to create a concatenated (end to
end) LSP
– LSP maintenance
• It is possible to run maintenance on an LSP independent of the mechanism
used to establish the LSP
– The ITU/TMF interface supports the management of multiple technologies
• Management of MPLS-TP needs to be added to these multi technology
interfaces

 No need to explicitly support the case of a single NE that offers both the IETF and
ITU/TMF interface
– This is a NE implementation issue
107
 Conclusions - 2
 Network Management (NM) requirements
– Configuration
• No issues
– Fault, PM
• If the OAM can provide the measurement primitives then no reason that NM
cannot report them
• Need 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)
• Not specific to MPLS-TP networks
• Dependent on:
– Management protocol
– Management application
– Bearer for the management traffic
• Security implementation is per network segment

108
 Management – Background IETF

 IETF architecture is layered and the functionality is allocated in separate

processes, e.g.:
– Performance management
• Netflow/IPfix
– Sample packets with a defined label – allows inspection of contents
• SNMP MIBs (e.g. packet counts on LSPs, Octets on an LSP, Queue
drops, CRC errors from lower layers – LSP not identified)
– Fault management
• SNMP traps,informs, BFD and syslog
– Configuration management
• Netconf, SNMP
– Security
• IPsec, tls, eap, Radius etc
– Accounting
• TACACS, netflow, ippm, ppml

 IETF doesn’t use TMF style CORBA/XML interfaces

109
 Management – Background ITU

 TMF/ITU approach
– Provides both a NE and Network level interface to the OSS
– Protocol neutral model (in UML), requirements and use cases
– Protocol specific interface definitions

110
ITU-T PM objectives
 PM Requirements for a MPLS-TP LSP/PW
 Same measurements and processing as Ethernet
– 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
– 10 seconds being severely errored/not severely errored to enter/exit
unavailable time (UAT)
– 15min and 24hr PM parameter reporting
 To define how LM (loss measurement) and DM (delay
measurement) information, as defined in Y.1731 & draft G.8114, is
registered in 15min/24hr bins (G.7710)

Dependent on OAM providing the primitives to

make these measurements
111
Summary

112
Summary
To date we have found no showstoppers and everyone is in agreement
that we have a viable solution
Recommend Option 1

It is technically feasible 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

From probing various SGs, WGs it appears that label 14 has had wide
enough implementation and deployment that the solution may have to use
a different reserved label (e.g. Label 13)
Extensions to Label 14 should cease
This architecture also appears to subsume Y.1711 since the
requirements can be met by the mechanism proposed here

113
 Some open discussion points

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
No issues w/ 2-way delay

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

degraded performance need to be defined
One approach is to encapsulate the appropriate Y.1731 pdus in an ACH

114
The End

115