MPLS-TP Y(J)S Slide 1 MPLS-TP Yaakov (J) Stein September 2011

MPLS-TP Y(J)S Slide 1

MPLS-TP

Yaakov (J) SteinSeptember 2011


Outline

MPLS-TP historyFundamentalsThe GAChOAMAPSControl plane


MPLS-TP History


Background

IP is the most popular packet-switched protocol

MPLS and Ethernet are the most popular server layers under IPbut neither is a transport network

At least some Service Providers want a• packet-based transport network • similar to present transport networks • optimized for carrying IP


Background

Characteristics of transport networks 1. High availability

1. Fault Management OAM2. Automatic Protection Switching

2. Efficient utilization, SLA support, and QoS mechanisms1. high determinism2. Connection Oriented behavior3. Performance Management OAM

3. Management plane (optionally control plane)1. configuration management similar to traditional2. efficient provisioning of p2p, p2m and m2m services

4. Scalability - must scale well with increase in 1. end-points2. services3. bandwidth


Possible solutions

There are two popular server network protocols for carrying IP• Ethernet• MPLS(in the past there were ATM, frame relay, IP over SDH, etc.)

Extensions to both were proposed :• Provider Backbone Transport (which became PBB-TE)• Transport-MPLS (which became MPLS-TP)

PBT advanced in IEEE standardization (802.1ah + 802.1Qay)but is now dead in the market

Today we are going to talk about MPLS-TP


PBT

PBT was invented by engineers at BT and Nortel• standardization attempted at the IETF• standardization attempted at the ITU• standardization succeeded at the IEEE

PBT uses the regular Ethernet encapsulation, but • turns off Ethernet learning, aging, flooding, STP• requires use of Y.1731 Ethernet OAM, APS, etc.• uses management plain to set up CO connections (SDH-like)• supports client/server layering through use of MAC-in-MAC


T-MPLS

T-MPLS was invented by Alcatel• standardization performed at the ITU (SG13/SG15)• standardization attempted at the IETF

T-MPLS is a derivative of MPLS, but• does not require IP• does not require a control plane• has ITU style OAM and APS• uses management plain to set up CO connections (SDH-like)


Behind the scenes at the ITU

SG13 worked on MPLS PW Recommendations Y.1411-Y.1418in parallel with the PWE3 WG in the IETF

SG13 started developing practical recommendations relating to MPLSsuch as Y.1710/Y.1711 for OAM and Y.1720 for linear APS

In RFC 3429 the IETF gave the ITU reserved label 14 for use in Y.1711 Later SG15 defined GFP (G.7041) UPIs for transport of MPLS

Then SG15 started work to describe MPLS as a transport layer networksuch as G.mta on architecture and G.mplseq on equipment functional blocks

SG15 decided that standard MPLS was not ideal for transport networksand started defining a “transport variant” of MPLS – T-MPLS(for example, disallowing PHP, ECMP, and VC-merge) in G.motnni (T-MPLS NNI) and G.8110.1 (T-MPLS layer network architecture)

At this point the IETF realized that the ITU was redefining MPLS

MPLS was developed in the IETF, and the IETF “holds the pen” on it

Furthermore, there were concerns that the new T-MPLSwould connect to MPLS but not be interoperable with regular “IP/MPLS”


ITU-T MPLS Recommendations

Recommendation Title Status

Y.1710 Requirements for Operation & Maintenance functionality in MPLS networks

approved Feb 2002

Y.1711 Operation & Maintenance mechanism for MPLS networks

approved Feb 2004

Y.1712 Y.17iw OAM functionality for ATM-MPLS interworking

approved Jan 2004

Y.1713 Y.fec-cv Misbranching detection for MPLS networks

approved Mar 2004

Y.1714 Y.17fw MPLS management and OAM framework approved Jan 2009

Y.1720 Protection switching for MPLS networks approved Dec 2006


ITU-T T-MPLS RecommendationsRecommendation Title Status

G.8101 /Y.1355 Terms and definitions for transport MPLS approved Dec 2006

G.8110/Y.1370 (G.mta) MPLS layer network architecture approved Jan 2005

G.8110.1 /Y.1370.1 Architecture of T-MPLS layer network approved Nov 2006

G.8112 (G.motnni) Interfaces for the T-MPLS hierarchy approved Oct 2006

G.8121/Y.1381 (G.mplseq)

Characteristics of T-MPLS equipment functional blocks

approved Mar 2006

G.8131 /Y.1382 Linear protection switching for T-MPLS approved Feb 2007

G.8132 T-MPLS Shared Protection Ring

G.8151/Y.1374 Management aspects of the T-MPLS network element

approved Oct 2007

G.8113/Y.1372 T-MPLS OAM requirements became Y.Sup4

G.8114 /Y.1373 T-MPLS OAM methodologies


History – IETF/ITU JWT

IETF participants and later the IETF management objected toredefining MPLS functionality without IETF control

Direct contact between the highest echelons of the two bodiesand a series of liaisons led to two options :

OPTION 1 T-MPLS would be co-developed with all standardization activity according to the IETF process

OPTION 2 T-MPLS would become a completely separate protocols(with a different EtherType to ensure no interconnection)

At a meeting of Q12/SG15 at Stuttgart the ITU picked OPTION 1 and a Joint IETF/ITU-T Working Team (JWT) was formed

The JWT produced a report (summarized in RFC 5317) proposing :• the ITU-T would cease work on T-MPLS and work with the IETF• the IETF would define an MPLS Transport Profile (MPLS-TP)


Early IETF documents

Process documents :RFC 4929 Change process for MPLS and GMPLS protocols and procedures

RFC 5704 Uncoordinated Protocol Development Considered Harmful

RFC 5317 JWT report

the beginning of a solution …RFC 5994 Application of Ethernet Pseudowires to MPLS Transport Networks

RFC 5586 MPLS Generic Associated Channel (G-ACh and GAL)

RFC 5718 An In-Band Data Communication Network for MPLS-TP


IETF Requirements documents

RFC 5654 Requirements of an MPLS Transport Profile• General requirements • Layering • Data plane• Control plane (optional)• Recovery (protection switching)• QoS

RFC 5860 Requirements for OAM in MPLS Transport Networks • OAM • Performance Monitoring

RFCs 5951 Network Management Requirements for MPLS-TP• Network management


Framework and architecture

RFC 5921 A Framework for MPLS in Transport Networks

RFC 5950 Network Management Framework for MPLS-TP

RFC 5960 MPLS-TP Data Plane Architecture

RFC 6215 MPLS-TP UNI and NNI

draft-ietf-mpls-tp-oam-framework OAM Framework for MPLS-TP

draft-ietf-ccamp-oam-configuration-fwk OAM Configuration Framework and Requirements for GMPLS RSVP-TE

draft-ietf-mpls-tp-survive-fwk - MPLS-TP Survivability Framework

draft-ietf-ccamp-mpls-tp-cp-framework MPLS-TP Control Plane Framework

draft-ietf-mpls-tp-mib-management-overviewMPLS-TP MIB-based Management Overview

draft-ietf-mpls-tp-security-framework MPLS-TP Security Framework


CampsOAMdraft-ietf-mpls-tp-cc-cv-rdi (was bfd-cc-cv)RFC 6374 (draft-ietf-mpls-tp-loss-delay) RFC 6375 (draft-ietf-mpls-tp-loss-delay-profile)draft-ietf-mpls-tp-on-demand-cvdraft-ietf-mpls-tp-li-lb draft-ietf-mpls-tp-faultdraft-ietf-mpls-tp-csfvsdraft-bhh-mpls-tp-oam-y1731Linear protectiondraft-ietf-mpls-tp-linear-protectionvsdraft-zulr-mpls-tp-linear-protection-switchingRing protectiondraft-weingarten-mpls-tp-ring-protectionvsdraft-helvoort-mpls-tp-ring-protection-switching

new numbers ! note that 6371/2/3 are being held !

but draft-sprecher-mpls-tp-oam-considerations insists that there be only one OAM


Control and management planes

draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lspRSVP-TE Extensions to Establish Associated Bidirectional LSP

draft-ietf-ccamp-rsvp-te-mpls-tp-oam-extConfiguration of Pro-Active OAM for MPLS-TP using RSVP-TE

draft-ietf-mpls-tp-fault fault (AIS, link-down, lock) reporting

RFC 6360 (draft-ietf-mpls-tp-identifiers) MPLS-TP Identifiersdraft-ietf-mpls-tp-itu-t-identifiers

MPLS-TP Identifiers Following ITU-T Conventions

draft-ietf-mpls-tp-te-mib MPLS-TP TE MIB


ITU-T MPLS-TP documents

G.8101/Y.1355 Terms and definitions for MPLS transport profileG.8151/Y.1374 Management aspects of the MPLS-TP network element

Work in progressG.8113.x/Y.1373.x Operation & maintenance mechanism …G.8121.1/Y.1382.1 Characteristics of MPLS-TP equipment functional blocks

supporting G.8113.1/Y.1373.1 G.8121.2/Y.1382.2 Characteristics of MPLS-TP equipment functional blocks

supporting G.8113.2/Y.1373.2 draft-tsb-mpls-tp-ach-ptn Assignment of an Associated Channel Type for Packet

Transport Network Applications


MPLS-TP Fundamentals(requirements …)


General

MPLS-TP is a profile of MPLS, that is• it reuses existing MPLS standards• its data plane is a (minimal) subset of the full MPLS data plane• it interoperates with existing MPLS (and PWE) protocols

without gateways

TP is similar to other transport networks (including look and feel)

TP is multi-vendor (in a single domain and between domains)

TP supports static provisioning via management planea control plane is defined but not mandatory to use

TP networks can be configured and operate w/o IP forwarding

TP’s data plane is physically/logically separated from management/control planes


Planes

TP supports static provisioning via management planea control plane (CP) is defined but not mandatory to use

TP networks can be configured and operate w/o IP forwarding

TP’s data plane is physically/logically separated from management/control planes

Data plane continues to operate normally (forwarding, OAM, APS) even if the management/control plane that configured it fails

TP can always distinguish user packets from control/management


Data plane

TP is a CO PS network TP defines PWs, LSPs, and segments (single links of LSP or PW path)

TP clients: IP, Ethernet, MPLS, MPLS-TP and can be extended to others

TP servers: Ethernet, MPLS-TP, SDH, OTNTP supports• traffic-engineered p2p and p2mp transport paths• unidirectional/co-routed bidirectional/associated bidirectional flows• mesh, ring, interconnected ring topologies

TP paths must be identifiable by a single label

The path’s source must be identifiable at destination

TP P2MP can exploit P2MP capabilities of a server layer

TP mechanisms can detect sub-SLA performance


QoS

The main aim of TP is to enable SPs to guarantee SLAs Thus QoS mechanisms are an essential part of TPThese mechanisms include:• DiffServ traffic types and traffic class separation• provisioning end-to-end bandwidth• flexible BW allocation• support for delay- and jitter- sensitive services • guarantee of fair access to shared resources• guaranteed resources for control/management-plane

traffic, regardless of the amount of data-plane traffic


OAMTP OAM applies to PWs, LSPs, and to segments, and may cross domainsTP OAM works independently and distinguishably at any label-stack depthTP OAM fate-shares with user traffic, but is distinguishable from user trafficTP OAM functionality can be configured by management or control planeIt should be possible to change configuration without impacting user trafficSupported functionality:• proactive CC• proactive CV• on-demand route tracing• on-demand diagnostics (e.g., intrusive loopback)• on-demand lock (administratively configured test state)• proactive defect reporting (FDI and RDI)• proactive client failure indication (CSF)• proactive or on-demand packet loss measurement• on-demand (and proactive) 1-way and 2-way delay measurementTP OAM must not cause network congestionMEPs and MIPs are defined


APSTP APS is similar to APS in other transport networksAPS may be triggered by lower-layer/OAM/mngt/control planeAPS mechanism should be the same for p2p and p2mp link, segment, and end-end protection are possibleRequirements:• standard 50 ms switching time for 1200 km • 100% protection must be supported• priority logic is required but extra traffic is not required• it must be possible to preconfigure protection paths• it must be possible to test/validate protection mechanisms• race conditions with other layers must be avoided

Protection types• revertive/nonrevertive• uni and bidi 1+1 for p2p• uni 1+1 for p2mp • bidi 1:n (including 1:1) for p2p • uni 1:n for p2mp


Management plane

Every MPLS-TP network element must connect (directly or indirectly) to an Operations System

When the connection is indirect, there must be aManagement Communication Channel

When there is a control plane, there is also aSignaling Communication Channel

TP management plane functionality includes:• configuration management (of system, CP, paths, OAM, APS)• fault management (supervision, validation, alarm handling)• performance management (characterization, measurement)• security management

We won’t go further into management functionality


Control plane

A control plane is defined (but not mandatory to use)The defined control plane for LSPs is based on GMPLS

and meets ASON requirements G.8080 (RFC 4139/4258)

For PWs – RFC 4447 (PWE3 control protocol)

An integrated control plane (TP, clients, servers) is possible

The control plane can configure• all the flow types • configuration/activation/deactivation of OAM functions

Automatic CP restart/relearning after failure

Management and control planes may co-exist in same domain


Topologies and connection types

TP paths are strictly Connection Oriented and may be Traffic Engineered

TP supports :• unidirectional p2p and p2mp connections• co-routed bidirectional p2p paths• associated bidirectional point-to-point transport p2p pathsTP should safeguard against forwarding loopsTP paths can span multiple (non-homogenous) domains TP supports rings (with at least 16 nodes)

TP supports arbitrarily interconnected rings (1 or 2 interconnections)


Identifiers

In order to configure, manage, and monitor network elements they require unique identifiers

In IP networks, IP addresses serve as a unique identifiersbut MPLS-TP must function without IP

PWs set up by PWE3 control protocol have unique identifiersRFC 4447 defines Attachment Individual Identifiers

In carrier networks network elements can be uniquely identified by Country_Code:ICC:Node_IDCountry_Code is two upper case letters defined in ISO 3166-1 ICC is a string of one to six alphabetic/numeric characters Node_ID is a unique 32-bit unsigned integer

For MPLS-TP any of these can be used


The GACh


Generic Associated Channel

MPLS-TP must be able to forward management and control plane messages without an IP forwarding plane

MPLS-TP must be able to inject OAM messagesthat fate-share with the user traffic

MPLS-TP needs to send status indications

MPLS-TP must support APS protocol messages

How are all these messages sent ?


Associated channels

PWs have an Associated Channel (ACh) in which one can place OAM (VCCV)that will fate-share with user traffic

The ACh is defined in RFC 4385 and is based on use of the PWE3 Control Word

MPLS-TP also needs an ACh for its OAMbut MPLS LSPs do not have a CW!

Y.1711 defined a mechanism for MPLS (pre-TP) OAMbased on use of reserved label 14 and an OAM type code

The ITU wanted to use this mechanism for T-MPLS as wellbut the IETF did something a little bit different

0 0 0 1 VER RES=0 Channel Type


GACh

RFC 5586 defines the Generic Associated Channel (GACh)based on the Generic Associated channel Label (GAL)

For the simplest case :

GAL label = 13 TC S TTL

MPLS label TC S TTL

0001 0000 RESERVED Channel Type

GAL

MPLS label stack

ACH header

Zero or more ACh TLVs

GACh message


What can be carried in the GACh ?

Defined Channel Types (IANA registry) :

The GACh can thus be used for:1. OAM (FM/PM) – using BFD, Y.1731, … (see next chapter)2. status signaling for static (non-LDP) PWs3. management traffic (e.g., when no IP forwarding plane)4. control traffic (e.g., when no IP forwarding plane)5. other uses ?

Value Description TLVs Reference

0x0000 Reserved

0x0001 MCC No RFC5718

0x0002 SCC No RFC5718

0x0007 BFD w/o IP header No RFC5885

0x0021 IPv4 packet No RFC4385

0x0057 IPv6 packet No RFC4385

0x0058 Fault OAM (temporary) No draft-ietf-mpls-tp-fault

0x7FF8-0x7FFF Experimental Use RFC5586


MPLS-TP OAM


The OAM issue

Since it strives to be a carrier-grade transport networkTP has strong OAM requirements

OAM has been the most contentious issue in standardization

Two documents are agreed upon• RFC 5860 Requirements for OAM in MPLS-TP • draft-ietf-mpls-tp-oam-framework OAM Framework for MPLS-TP

It is agreed that OAM will be generally in the GACh

But two OAM protocols have been proposedand the IETF and ITU-T have still not agreed on how to proceed

The OAM controversy may break MPLS-TP into two flavors


Which OAM ?

So what OAM do we put into the GACh ?There are two possibilities:

1. Bidirectional Forwarding DetectionBFD is a “hello” protocol originally between routersbefore TP IETF standardized it for IP, MPLS, and PWs (in VCCV)

• RFC 5880 (draft-ietf-bfd-base)• RFC 5881 (draft-ietf-bfd-v4v6-1hop) • RFC 5882 (draft-ietf-bfd-generic) • RFC 5883 (draft-ietf-bfd-multihop) • RFC 5884 (draft-ietf-bfd-mpls)

2. Y.1731 (802.1ag)Y.1731 is an ITU/IEEE OAM protocol for Ethernet OAMend-end OAM with FM and PM (ITU-only) capabilitiesproposed as an alternative to LSP-ping and BFD in VCCV


BFD - review

Originally developed by Juniper and Ciscoto detect failures in the bidirectional path between routersfaster than via routing protocol hellos thus reducing routing processing load as hello rates can be reduced

Light-weight liveliness protocol control packets sent in both directions at negotiated raterate specified in msec optional echo mode for two-way failure detectionruns in data plane like OAM, but unlike router hellos,simple fixed-field encoding to facilitate HW implementationno neighbor discovery (sessions triggered by routing protocol)

Since BFD can be the payload of any encapsulating protocolso easily extended to new cases: physical links, tunnels, LSPs, multihop routed paths, …


BFD details

ModesAsync mode – each side periodically sends control packetsDemand mode – side does not send control packet unless polledEcho mode – echo packet returned to sender

StatesDown – just created or no connectivityInit – during 3-way handshake (set-up or tear-down)Up – connectivity AdminDown – administratively down for indefinite period

does not imply lack of connectivity!


BFD format

format of echo packet need not be defined

BFD control packet (without optional Authentication) :

Vers Diag Sta|P|F|C|A|D|M Detect Mult Length

My Discriminator

Your Discriminator

Desired Min TX Interval

Required Min RX Interval

Required Min Echo RX Interval


BFD control packet – explanations

Vers : version = 1Diag : diagnostic code specifying the reason for the last state change 0 -- No Diagnostic 1 -- Control Detection Time Expired 2 -- Echo Function Failed 3 -- Neighbor Signaled Session Down 4 -- Forwarding Plane Reset 5 -- Path Down 6 -- Concatenated Path Down 7 -- Administratively Down 8 -- Reverse Concatenated Path Down 9-31 -- Reserved Sta: current BFD session state as seen by the transmitting system 0 – AdminDown 1 -- Down 2 -- Init 3 -- Up P: Poll. Sender requests verification of connectivity or of parameter change, expects an “F” packet in replyF: Final Sender is responding to a received poll.C: Control plane independent - sender BFD in data plane, continues to function even if control plane failsA: Authentication presentD: Demand – sender wishes to operate in Demand mode, asks remote not to send control packetsM: Multipoint - for p2mp applications Detect Mult : Detection time multiplier (e.g., 3). Number of Tx intervals for detection in async modeLength : length of packet in bytesMy Discriminator : unique nonzero value used to demux BFD sessions between the same endpointsYour Discriminator : discriminator received from the remote or zero if unknownDesired Min TX Interval : minimum interval (msec) that can sendRequired Min RX Interval : minimal interval (msec) that can receive

0 means do not send periodic control packets.Required Min Echo RX Interval : minimum supported interval (msec) between received echo packets

if zero, echo mode is not supported.


Encapsulations

single hop IP UDP dest port = 3784 for control packets, 3785 for echo packetsUDP source port from dynamic range TTL=255 (for security)

multihop IPUDP dest port = 4784 for control packets, echo mode forbiddenUDP source port from dynamic range TTL does not provide security

PWPW label + any of the 3 VCCV CC types but always with the CW4 CV types – (fault only or fault+status) * (with/without UDP/IP headers) – indicated in CWonly async mode, discriminator=0, capabilities signaled in PWE control protocol

MPLSlabel stack of FEC being monitoredMPLS TTL set to expireBFD triggered by LSP pingUDP/IP BFD control packet inside MPLSasync mode onlybootstrapped with LSP ping echo request/reply messages

containing discriminators in TLV type 15


Y.1731 – brief review

Developed by the ITU and IEEE as 802.1ag (CFM)and supported by the MEF

Designed as a full multi-level carrier-grade OAM solutionIntroduced new concepts, such as MEPs, MIPS, …Supports CC, CV, AIS, LB, LT, placket loss, delay, PDV, …

Unfortunately, Y.1731 is tightly coupled with Ethernet• EtherType identifies Y.1731 packet• DAs identifies entities such as MEPs and MIPS• MEL identifies level

not easy to drop Y.1731 PDUs into other protocols


Y.1731 format

after DA, SA, optionally VLANs, comes Ethertype (8902)and the following PDU

if there are sequence numbers/timestamp(s), they are nextthen come TLVs (after offset), the “end TLV”, followed by the FCS TLVs have 1B type and 2B length fieldsthere may or not be a value fieldthe “end-TLV” has type = 0 and no length or value fields

MEL(3b)

OPCODE(1B)

VER(5b)

FLAGS(1B)

TLV-OFF(1B)


Y.1731 PDU typesopcode OAM Type DA

1 CCM M1 or U

3 LBM M1 or U

2 LBR U

5 LTM M2

4 LTR U

6-31 RES IEEE

32-63 unused RES ITU-T

33 AIS M1 or U

35 LCK M1or U

37 TST M1 or U

39 Linear APS M1or U

40 Ring APS M1or U

41 MCC M1 or U

43 LMM M1 or U

42 LMR U DA

45 1DM M1 or U

47 DMM M1 or U

46 DMR UA

49 EXM

48 EXR

51 VSM

50 VSR

52 CSF M1 or U

55 SLM U

54 SLR U

64-255 RES IEEE


and the winner is …

So, for MPLS-TP there are two options1. BFD + The IETF chose this route

extensible to new encapsulationsnot a full OAM protocolalready runs on LSRs

and deployed in MPLS core networksextend BFD (and LSP-ping) to become a full FM OAM protocol

and invent new protocols as needed

2. Y.1731 The ITU-T chose this routefull OAM protocolnot easily extensible to MPLSalready runs on switches

and deployed in carrier Ethernet networkscreate a new encapsulation and reuse all functionality


The IETF OAM - overview

All functionality runs over the GAL/GACh

draft-ietf-mpls-tp-• cc-cv-rdi leverages BFD for CC, CV and RDI• on-demand-cv leverages LSP-ping for on demand CV• li-lb new lock instruct and loopback protocol• fault new fault (AIS, link-down) reporting protocol• csf new client signal fail protocol• loss-delay (RFC 6374) new PM protocol• loss-delay-profile (RFC 6375) simplified subset of loss-delay

Let’s see a few of these …


The IETF CC and RDI message

from draft-ietf-mpls-tp-cc-cv-rdi

CC packet

RDI indicated in BFD control packet by Diag=8 -- Reverse Concatenated Path Down

0001 VER 00000000 CC channel type

BFD control packet

GAL Label (13) TC S=1 TTL GAL

GACh

BFD


The IETF CV message

from draft-ietf-mpls-tp-cc-cv-rdi

CV packet

0001 VER 00000000 CV channel type

BFD control packet


GACh

BFD

MEP Source ID

TLV

Type= 1)segment 2)LSP 3) PW Length

node identifier


The IETF on-demand CV message

from draft-ietf-mpls-tp-on-demand-cv

on-demand CV packet (several encaps possible)

return path is in MPLS (no IP forwarding …)three encapsulations

– LSP-ping UDP/IP packet in MPLS (RFC 4379 )– LSP-ping packet in UDP/IP in GACh (channel type 0x21 or 0x57) – “raw” LSP-ping packet in GACh (new channel type)

new TLVs are defined

0001 VER 00000000 channel type

RFC 4379 packet


GACh

LSP-ping


The IETF fault message

from draft-ietf-mpls-tp-fault

fault management packet

L flag used for AIS R flag removes previous fault conditionTLVs indicate the nodes/interfaces and conditions

0001 VER 00000000 FM channel type

Vers RES Msg Type Flags Refresh Timer


GACh

FMmessage

TLV Length TLVs

L R


The IETF loss and delay PM

RFC 6374 defines 4 new GACh types

• the same packet format is used for query and responsea flag bit distinguishes between the two

• direct mode = use of counters for accurate loss measurement• inferred mode = use of synthetic packets• for loss measurement counters are carried in the OAM packets• delay measurement timestamps may be

1588 format (default) or NTP format

These messages are for MPLS in generalProfile for TP (where no ECMP, PHP, etc) is available

Value Description TLVs Reference

0x000A Direct Loss Measurement (DLM) No RFC6374

0x000B Inferred Loss Measurement (ILM) No RFC6374

0x000C Delay Measurement (DM) No RFC6374

0x000D Inferred Loss and Delay Measurement (ILM+DM) No RFC6374


The ITU-T Y.1731-based OAM

Defined in draft-bhh-mpls-tp-oamY.1731 PDUs are placed after GALACh channel type (not allocated by IANA) identifies PDUs

MEL OPCODEVER FLAGS TLV-OFF

0001 VER 00000000 allocated channel type

Y.1731 PDU with (ICC-based or IP-based) MEG ID


GACh

Y.1731


MPLS-TP APS


MPLS-TP resilience

Since it strives to be a carrier-grade transport networkTP has strong protection switching requirements

APS has been almost as contentious issue as OAMand indeed the arguments are inter-related

draft-ietf-mpls-tp-survive-fwk gives a general frameworkand differentiates between – linear– shared-mesh and– ring

protection


Linear protection – IETF style

from draft-ietf-mpls-tp-linear-protection• 1+1, 1:1, 1:n and uni/bidi are supported• APS signaling protocol (for all modes except 1+1 uni)

is single-phase and called the Protection State Coordination protocol• PSC messages are sent over the protection channel• APS messages are sent over the GACh with a single channel type message functions identified by a request field • 6 states: normal, protecting due to failure, admin protecting, WTR, protection path unavailable, DNR• when revertive, a WTR timer is used


PSC message format

Request : NR, SF, SD, manual switch, forced switch, lockout, WTR, DNRPT = Protection Type : uni 1+1, bidi 1+1, bidi 1:1/1:nR = RevertiveFPath = which path has fault Path = which data path is on protection channel

0001 VER 00000000 PSC channel type

Ver Request PT R Res FPath Path


GACh

PSC TLV Length Res

Optional TLVs


Linear protection – ITU style

from draft-zulr-mpls-tp-linear-protection-switching

Similar to previous, but uses Y.1731/G.8031 format

0001 VER 00000000 allocated channel type


GACh

G.8031

MEL VER OPCODE=39 FLAGS=0 OFFSET=4

reqstate

prot type

requestedsig

bridged sig reserved

END=0


Ring protection

once again there are two drafts, both support p2p and p2mp, wrapping and steering, link/node failures

draft-weingarten-mpls-tp-ring-protectionBetween any 2 LSRs can define a Sub-Path Maintenance EntitySo between 2 LSRs on a ring there are 2 SPMEs – we define 1 as the working channel and 1 as the protection channelNow we re-use the linear protection mechanisms, including the PSC protocol

draft-helvoort-mpls-tp-ring-protection-switchingBoth counter-rotating rings carry working and protection trafficThe bandwidth on each ring is divided X BW is dedicated to working traffic and Y dedicated to protection trafficThe protection bandwidth of one ring is used to protect the other ringEach node should have information about the sequence of ring nodes MPLS-TP Ring Protection Switching is G.8032-like, but forwards non-NR msgs


MPLS-TP Control Plane


When a control protocol is used

from draft-ietf-ccamp-mpls-tp-cp-framework

for setting up PWs, MPLS-TP uses :PWE3 control protocol RFC4447for MS-PWs:

OSPF-TE (RFC 3630) or ISIS-TE (RFC 5305) or MP-BGP

for setting up LSPs, MPLS-TP uses :GMPLS RFC3945

which is built on RSVP-TE RFC 3209 and extensions OSPF-TE (RFC 4203 and 5392) or ISIS-TE (RFC 5307 and 5316) fulfilling ASON signaling requirements of RFC 4139 and 4258

Documents

MPLS-TP Y(J)S Slide 1 MPLS-TP Yaakov (J) Stein September 2011