mpls architectural considerations for a transport profile

1

MPLS Architectural Considerations for aTransport Profile

ITU-T - IETF Joint Working Team

Dave Ward, Malcolm Betts, ed.

March 25, 2008

2

What am I reading?

This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the month of March, 2008

This represents the agreed upon starting point for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture

The output of the technical analysis will be the recommendation given to SG 15 on how to reply to the IETF’s liaison of July 2007

– IETF requested decision on whether the SDOs work together and extend MPLS aka “option 1: or

– ITU-T choose another ethertype and rename T-MPLS to not include the MPLS moniker aka “option 2”

The starting point of the analysis is to attempt to satisfy option 1 by showing the high level architecture, any showstoppers and the design points that would need to be addressed after the decision has been made to work together.

3

Some Initial Participants and contributors of this set BT

Ben Niven-Jenkins, Tom Nadeau Verizon

Andy Malis ATT

Deborah Brungard NTT

Shin Miyakawa Comcast

John Leddy Consultants

Loa Anderson, Adrian Farrel Alcatel-Lucent

Vach Kompella, Marc Lasserre, Matthew Bocci, Italo Busi, Kevin Sparks, Sunil Khandekar, Bruce Nelson, Martin Vigoureux, Vincenzo Sestito, Lieven Levrau

CiscoStewart Bryant, Luca Martini, George Swallow, Ali Sajassi, Simon Spraggs, Mark Townsley, Joe Wojtal, Dave Ward

EricssonDave Sinicrope

JuniperRoss Callon, Kireeti Kompella, Rahul Aggarwal, Thomas Walsh

NortelMalcolm Betts, Stephen Shew

4

How is the effort organized?

1. In ITU-T

TMPLS ad hoc group

2. In IETF

MPLS interoperability design team

3. DMZ between the SDOs: Joint Working Team

Segmented into groups looking at

1. Forwarding

2. OAM

3. Protection

4. Control Plane

5. Network Management

Goal: Produce technical analysis that MPLS architecture can perform functionality required by a transport profile.

Compare w/ ITU-T requirements and identify showstoppers

Find any obvious design points in MPLS architecture that may need extensions

5

MPLS + Transport Profile: What are the problems? 1

Ability to statically configure LSPs and PWEs via the management plane i.e. not a control (routing/signaling) plane

If a control plane is used for configuration of LSPs/PWEs failure and recovery of the control plane must not impact forwarding plane (a la NSR/NSF)

Transport OAM capabilities for LSP and PWE independent of configuration mechanism (management plane or GMPLS or PWE control plane)

Full transport FCAPS - AIS, RDI, Connection verification (aka connectivity supervision in G.806), loss of connectivity (aka continuity supervision in G.806), support of MCC and SCC etc

Recent drafts to IETF demonstrate some issues

Service Providers are requesting consistent OAM capabilities for multi-layered network and interworking of the different layers/technologies (L2, PWE, LSP)

Include functionality of Y.1711 and Y.1731 into one architecture

6

MPLS + Transport Profile: What are the problems? 2

Service Providers want to be able to offer MPLS LSPs and PWEs as a part of their transport offerings and not just associated with higher level services (e.g. VPNs)

Service Providers want LSPs/PWEs tandem connections to be able to be managed at the different nested levels seamlessly (path, segment, multiple segments)

e.g. where a LSP/PWE crosses multiple administrations

Service Providers want additional protection mechanisms or clear statements on how typical “transport” protection switching designs can be met by the MPLS architecture

Service Providers are requesting that OAM and traffic are congruent when traversing LAG or ECMP

Or create LSP/PWEs that don’t traverse links with LAG/ECMP

7

MPLS - Transport Profile (TP) Requirements Overview

Meet functional requirements stated earlier by service providers

No modification to MPLS forwarding architecture

Solution Based on existing Pseudo-wire and LSP constructs

Bi-directional congruent p2p LSPs

No LSP path merge

Multicast is point to multipoint NOT MP2MP

OAM function responsible for monitoring the LSP/PWEInitiates path recovery actions

No requirement on IP for forwarding of OAM and data traffic

OOB management and signalling network running IP is outside scope

Can be used with static provisioning systems or with control plane

With static provisioning, no dependency on routing or signaling (e.g. GMPLS or, IGP, RSVP, BGP, LDP)

Mechanisms and capabilities must be able to interoperate with existing MPLS control plane and forwarding planes

8

MPLS-TP Major Solution Constructs

1. Definition of Label For yoU (LFU) and generic Associated Channel (PWE ACH)

Allows OAM packets to be directed to an intermediated node on a LSP/PWE

Via label stacking for TCM MEP addressing

Via proper TTL setting for MIP addressing

Reuse Label 14 or define a new reserved label:

It is believed that Label 14 can be reused since the functionality defined at that codepoint is supported in this architecture and it has not been deployed

2. Generic Channel Association function supports the FCAPS functions by carrying OAM, APS, SCC/MCC etc. packets across the network

Use of PWE-3 Associated Channel to carry OAM packets

Generic Channel Association are codepoints from PWE ACH space but, not necessarily for PWE purposes

ACH now present for OAM of all LSPs

9

High Level Architecture

10

MPLS-TP service spectrum

Connectionless Multi-service(Connectionless and Connection Orientated)

ConnectionOrientated

Node /Link addressing

IP

Control plane

IP based / LDP or TE

External NMS

LSP creation

Dynamic and static coexistence

Label Space

Split label space (static / dynamic)

Load Balancing

ECMP and Non ECMP support

Penultimate Hop Popping

PHP or non PHP

L2 Signalling

Static or Targeted LDP

L3 only L1, L2, L3 ServicesPt-Pt, Pt-MPt, MPt-MPt

L1, L2 ServicesPt-Pt and Pt-MPt

Node/Link addressing

IP

Integrated control Plane

IP based / LDP or TE

LSP creation

Dynamic only

Label space

Dynamic label space

Load Balancing

ECMP only


PHP or non PHP

L2 signalling

Not required

MPLS-TP solution must exist over this spectrum

Node /Link addressing

Multiple

Control plane

External NMS or GMPLS

LSP creation

Static and dynamic coexistence

Label Space

Static/dynamic label space

Load Balancing

Non ECMP support


non PHP

L2 Signalling

Static or Targeted LDP

11

MPLS+TP Static Provisioning

Forwarding Tables

Forwarding Tables

Forwarding Tables

Edge Edge

Network Management SystemControl Plane for PT2PT services

Static provisioning and dynamic control planeAnticipated that initial solutions will be based on static provisioning

Dynamic Control plane will be based on IETF solutions (G-MPLS, IP/MPLS)

Control Plane responsible for:End to End, Segment LSPs and PWE-3 application labels (programming the LFIB)

Determining and defining primary and backup paths

Configuring the OAM function along the path

Others : Defining the UNI etc

OAM responsible for monitoring end to end and tandem paths and driving switches between primary and backup paths

OAM OAM OAM

12

MPLS Transport Profile - Terminology

Definition of an MPLS Transport Profile within IETF MPLS standardsBased on PWE-3 and LSP forwarding architecture IETF MPLS architecture concepts

Questions <<NEED to clarify the questions>>How do we signal end to end : PWE-3 uses T-LDP to signal, exchange capabilities etc. Is this done entirely statically in MPLS-TP and use internal OAM mechanisms to drive emulated service status. Need to define the connection pieces - TBD by NMS/OAM subgroups

How are the devices identified and how does the NMS communicate with them outside DCC?

Multi-node PSN cloud

Pseudo-wire

PW1

Emulated Service

AttachmentCircuit

PE1 PE2CE1 CE2

AttachmentCircuit

13

Multi segment Transport LSP example

CE or PE?

CE or PE?

PE P P

MEP MIPMIP MIP MEP

MEP MEPMEP MEP

MIP

MEP MEP MEP MEP MEP MEP

PE PE PE

MIPMIP

• A segment is between MEPs• OAM is end to end or per segment• The OAM in each segment is independent of any other segment• Recovery actions (Protection or restoration) are always between MEPs i.e. per segment or end to end

Carrier 1 Carrier 2

UNIor

NNI?

NNI

MEP: Maintenance End PointMIP: Maintenance Intermediate Point

end to end OAM

per carrier OAM

UNIor

NNI?

Note: A policing function (traffic management/shaping) is normally co located with a MEP at a business boundary (UNI/NNI)

Service Provider

<<We need to discuss/review the differences between segment and tandem connection.It seems that they are used as synonymous in this slide.

The reference network scenario is not very clear.>>

14

Nested segment example

PE1 PE6 PE5 P P

MEP

MEP MEP

MEP

PE4 PE3 PE2

Region 1 Region 2

NNINNI INNI

Carrier 1

MEP MEP MEP MEP MIPMIP

MIP MIP

MIP MIP MIPMIP

end to end OAM

per carrier OAM

per region OAM

3 OAM levels• end to end + 2 nested segment levels• Nested segments are supported by Tandem Connection Monitoring (TCM) in SDH/OTN and Y.1731

MEP/MIP architecture updated

15

Bi directional Paths

External Static ProvisioningNMS responsible for configuration and ensuring bi-directional congruency

If Dynamic Control PlaneGMPLS bidir RSVP for LSP path establishment

16

Node identification

Will need to work through identification requirementsWhat about algorithmically derived label from the IP identifierWhat IP identifier if we do not need IP to support forwarding or OAM?Need to be able to rearrange the DCC without disturbing the forwarding/OAM?

NMS/OAM subteam to clarify that we have a Node Identification scheme

A node has multiple identifiers including the following: Management identifier – normally user friendly, based on the location MEP/MIP identifier DCC address - how do management messages reach this node Control plane identifiers - how are the various control components identified Forwarding plane identifier - end points and intermediate points - e.g. NNIs

These are design issues, not “show stoppers”.

17

OAM requirements

18

OAM Requirements

Must be able to monitor Section, LSP, PWE-3– Inter layer fault correlation– failure indication propagation across multiple segments

Packet loss rather than bit error based measurements/metrics for L2, LSP, PWE-3

Per segment <<(tandem connection?)>> and end-to-end– Fault detection/isolation – Recovery - protection switch

A security architecture

19

What is segment recovery?

End to End protection :

Fault detection and protection of the end to end pseudo-wire

Fault detection and protection of the end to end LSP

Segment protection : Fault detection and protection of a segment (arbitrary portion of an LSP, aka sub-network connection in G.805, or a segment of an MS-PW, aka link connection in G.805) <<NOT CLEAR>>

Segment could be provided by a hierarchical nested LSP, pseudo-wire stitching function <<NOT CLEAR>> or a nested pseudo-wire function

No concept of nested pseudo-wires in IETF: Future if necessary

Already clear concept of nested LSPs

Initial solution will be based nested LSPs or pseudo-wire stitching <<NOT CLEAR>>

BA DC FE

End to End Protection

Segment Protection

20

OAM mechanisms

21

OAM hierarchy and mechanisms

L0/L1 : Loss of Light; G.709, SONET/SDH LoS, LoF, ES, SES (NOT DISCUSSED)

L2 connectivity : Native L2 solution 802.1ag, Section OAM (e.g. non IP BFD) <<Do we mean interworking between L2 service OAM and PW OAM or do we mean failure propagation across layers?>> OAM of L2 and L2 interworking can be met by this architecture

General LSPs : Generic Exception Label and Generic Associated ChannelIncludes End to End and segment LSPs Used to carry a variety of OAM, Mgmt, signalling protocols.

Pseudo-wires : PWE-3 Associated Channel

BA DC FE

L1/L2 L1/L2 L1/L2 L1/L2L1/L2

Segment LSP

End to End LSP

Pseudo-wire

Midpoint

22

LSP monitoring and alarming Generic Exception Label and Generic Associated Channel Proposal

Assign a new label as a Label For youU (LFU)From reserved label space:Label 13 has been proposed, orLabel 14 because this has been allocated to Y.1711

Huub checking if it is deployed and can be reclaimed as Y.1711 arch fits into new construct

Bottom of Stack is always set on LFUIn transport case this is always true

Define a Generic Associated Channel function Similar to the PWE-3 Associated Channel but doesn’t have to be associated with a pseudo-wireImportant the first nibble tells system not to load balance (so not 06 or 04)

Generic Associated Channel is always under a Generic Exception Label if endpoint

Generalised Associated Channel defines what packet function using “channel type” fieldExamples : What OAM function is carried, DCC, etc

MAC Header Channel payloadL1 L2 LFU/BoS Generic ACH

000x | Ver | resv | Channel Type

Should this be the same as PWE-3 format?

23

Pseudo-wire monitoring and alarmingPWE-3 Control Word and PW-Associated Channel : (RFC4385)

MAC Header Channel payloadL1 L2 PWL/BOS PWE-3 ACH

MAC Header PayloadL1 L2 PWL/BOS Control Word

0000 | Specified by encapsulation

0001 | Ver | resv | Channel Type

To be completed

24

Associated Channel Level (ACH)

25

Associated Channel Level ACH: Overview

Generalised mechanism for carrying management / OAM information OAM capabilities :- Connectivity Checks (CC) and “Connectivity Verification” (CV)Management information:- Management Communication Channel (MCC) and Signalling Communication Channel (SCC)APS informationMaybe even signalling information in non IP environments

Associated Channel CapabilitiesMultiple channels can exist between end pointsChannel Type Indicates what protocol that is carriedTo service an MPLS-TP network new channel types will need to be defined

Management and Control Plane Information (MCC and SCC)Via routed IP or Associated channel where IP is not configured

Generic ACH contains a “channel Type” fieldNeed for a registry of protocolsThis needs to be blocked for different functions(IP-Free BFD is currently 7)

Do we define a vendor specific range?

26

Protocols within Associated Channel CV : Connectivity Verification (misconfiguration detection) PM: Performance of the path AIS: Alarm suppression CC : Continuity Check :- Is the path present (reuse vanilla BFD here)

Light weightRole is as a CC protocol, it is not a CV protocol Not a connectivity verification protocolVCCV-BFD provides capabilities over pseudo-wire

MCCManagement communication

SCCControl plane communications

APSProtection switching coordination

Accounting/Billing information Security exchange Define new or use existing protocols for other functions

27

LSPs / OAM and Label Stacks

28

Scope of next (label stack example) slides

Slides focus on MEP to MEP monitoringDetailed OAM packet walkthrough not yet covered in this slide-set

Examples of potential PWE stacking at end of slideset

MEP to MIP is not covered in this slide setMEP sets the TTL of the MEP to MEP tunnel label so that it will expire when the target MIP is reached

Detail packet walkthrough to be added

29

LFUACh

LFUACh

LFUACh

LFUACh

Section OAM

TCM-LSP OAM BC CDLFUACh

LFUACh

E2E (A to E)LSP OAM

BCAB BD DE

LFUACh

LFUACh

LFUACh

BDLFUACh

E2E (A to E)PW OAM AE

AChAE

AChAE

AChAE

ACh

Non OAM Data Frames

CW CW CWCW

LFU – Label For You (label 13|14)ACh – Associated ChannelCW – Control Word

TCM-LSPs

E2E LSPSS-PW

A B C D E

CD

BCAB BD DEBD

CD

AE AE AEAE

BCAB BD DEBD

CD

SS-PW, LSP and TCM-LSP OAM

30

Domain BDomain A

LFUACh

LFUACh

LFUACh

LFUACh

LFUACh

Section OAM

TCM-LSP OAM AB BC DE EFLFUACh

LFUACh

LFUACh

LFUACh

E2E LSP OAM AB BC DE EFAC AC DF DF

LFUACh

LFUACh

LFUACh

LFUACh

CDLFUACh

E2E PW OAM AB BC DE EFAC AC DF DFAF

AChAF

AChAF

AChAF

ACh

CDAF

ACh

Non OAM Data Frames AB BC DE EFAC AC DF DFAFCW

AFCW

AFCW

AFCW

CDAFCW


TCM-LSPs

E2E LSPSS-PW

A B C D E F

Manual stiching in C and D

One hop TCM-LSP OAM and Section OAM would traditionally not run concurrently

SS-PW over inter-domain LSP

31

OAM operations

32

Pseudo-wire OAM processing

BA DC FE

Pseudo-wire

Pseudo-wire Label

Pseudo-wire Associated Channel

Pseudo-wire Channel Type

OAM function

MAC Header OAM messagePWE-3 L PWE-3 ACH


Processed by the pseudo-wire function on the end-pointsEnd point or Pseudo-wire stitch point

Verifies the operational status of the pseudo-wire

Working with the native attachment circuit technologyAn inter-working function with the native attachment circuit OAM.

Transport and act upon native attachment circuit OAM technology

33

LSP End Point processing

BA DC FE

Pseudo-wire

Label For yoU

Generic Associated Channel

Generic Channel Type

OAM function

MAC Header OAM messageLFU GE-ACH


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 LSPMany options including Non IP BFD is an option encapsulation of Y.1731 pdu

Generates OAM packet

34

End to End LSP operations

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

LSP OAM

LSP OAM

LFIB:AB-BC

LFIB:BC-CD

LFIB:CD-DE

PW-L, AB

DE, PW-L

LFIB:AW-WXLFIB:WX-XY

LFIB:XY-YZAEPrimary Path

Backup Path

PW-L, AW

YZ, PW-L

35

Segment LSP operations

Path diversity is not part of the OAM process. It is the responsibility of the Control or Management Plane

OAM function uses LFU with Generic Channel Association Pre-provisioned segment primary and backup paths LSP OAM running on segment primary and back-up paths via LSP nesting OAM failure on backup path Alert NMS OAM failure on primary path results in B and D updating LFIB to send traffic labelled for BD via

segment backup path End to End traffic labelled for BD now pushed onto segment backup path

Primary Path

LSP OAM

LFIB:AB-BC

LFIB:BC-CD

LFIB:CD-DE

PW-L, AB

DE, PW-L

LFIB:AW-WXLFIB:WX-XY

LFIB:XY-YZAE

Segment Backup Path

PW-L, AW

YZ, PW-L

Segment Primary PathB

D

36

Control Plane

37

Discussion/Decisions

Transport profile should meet the requirements of the ASON architecture

Decision: Use IETF - GMPLS protocol suite given it is used for ASON

In none GMPLS cases need DCC for control

ACH defines MCCCan have as many channels and protocols as necessary and therefore could support the ASON SCN

Must have policing for DCC/SCC

ISIS running in DCC for topology information

38

Protection and Switchover

39

Discussion/Decision

Nested LSPs (potentially PWEs) provide levels of hierarchy to support per segment and path recovery

Must draw up PWE requirements

Most of the time intermediate nodes to not process the entire stack

This follows the model of GMPLS nesting and hierarchy exactly

Thus, if MPLS label stack not useful in this scenarios demonstrates critical flaw in GMPLS architecture.

Each segment can act independentlyMultiple potential solutions including

Native IETF mechanisms

Carry G.8131/G.8132 pdus in an ACH

40

Discussion/Decisions.2

We found that MPLS local repair, wrap and 1:1 detour mechanisms met required functionality

Also provided optimized exit to prevent use of 2x bandwidth in transport wrapping repair technologies

No need for Q9 mechanism as described there

Must add notion of DOWN and ADMINDOWN (e.g. standby bit)

Must add use case diagramming

41

Network Management

42

Discussion/Decisions

We had discussion of network management requirements

We must map ITU-T requirements into IETF architectureIETF architecture is a layered one that has functionality in many different processes, e.g.

Netflow/Ipfix = performance management

SNMP traps,informs, BFD and syslog = fault management

Netconf, SNMP = configuration management

IPsec, tls, eap, etc = security

Radius, TACACS, netflow, ippm, ppml = accounting

IETF doesn’t have TMF or Corba definitions Need to be able to “stitch” a service where some segments use IETF/netconf and

others use ITU/TMF management interfaces

Need to draw IETF arch and map

43

Summary

To date we have found no showstoppers and everyone is in agreement that we have a viable solution

It appears that the existing MPLS architecture can be extended to meet the requirements of a Transport profile

The architecture allows for a single OAM technology for LSPs, PWE and a deeply nested network

This architecture also appears to consume Y.1711 and those requirements can be met

44

Some open discussion points

1. One way delay measurement techniques are just emerging and very hard to solve. Decision: architecture can not preclude it

No issues w/ 2-way delay

2. Appears we can’t use PHP in transport profile as you need context of the “previous nexthop” to perform all OAM

Think if this is always the rule

3. Measurement of packet loss to support PMs and detection of degraded performance is difficult

One approach is to encapsulate the appropriate Y.1731 pdus in an ACH

45

The End

46

ECMP considerations

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 environmentRouting protocols and LDP may set-up ECMP routes

Traffic Engineering can as well (auto-route)

Recognised in IETF RFC 4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks : 0 or 1 in the first nibble of the payload

RFC 4385 PW3 Control Word for Use over an MPLS PSN : Defines “Generic PWE-3 control word” and “PW Associated Channel” formats

A consistent approach required for MPLS with a transport profile - Vach/Stewart to define LB LabelRFC 4928 implemented through use of control word and PWE-3 ACH

RFC 4385 for Control Word and PW associated Channel formats

MAC Header OAM messageL1 L2 PWE-L/BOS PWE-3 ACH

MAC Header PayloadL1 L2 PWE-L/BOS Control Word

0000 | Specified by encapsulation


This is a start of ECMPconsiderations and a placeto discuss load-balance labels

47

LSPs / OAM and Label StacksAlternate approach using stacked PWs

Not currently supported

These are sketches of what the label stack would look like if we went forward with a stacked PWE approach in the IETF

Just for reference

This work is NOT a requirement of MPLS-TP option 1|2 decision making

48

LFUACh

LFUACh

LFUACh

LFUACh

Section OAM

TCM-PWE (B to D)OAM

E2E (A to E)PW OAM AB

AChBDACh

DEACh

BDACh

Non OAM Data Frames

CW CW CWCW


LSPs

TCM-PWEMS-PW

A B C D E

ABBC

DECD

BD2ACh

BD2ACh

BC CD

BD2 BD2

LFU a priori not needed because BD2 is bottom of stack and Ach has been negotiated

AB BD DEBD

AB BC DECDBD2 BD2

Use of pseudo-wide Label stacking* to be further specified.* : not pseudo-wire nesting

LSP OAM not shown here

AB-BD pw label swapBD2 pw label pushBC lsp label push

TCM-MS-PW OAMB and D are S-PEs

49

LFUACh

LFUACh

LFUACh

LFUACh

Section OAM

TCM-PWE (B to D)OAM

E2E (A to E)PW OAM AB

AChBD

AChDE

AChBD

ACh

Non OAM Data Frames

CW CW CWCW

LFU – Label For You (label 1314)ACh – Associated ChannelCW – Control Word

LSPs

TCM-PWEMS-PW

A B C D E

ABBC

DECD

B and D are S-PEs

BD2ACh

BD2ACh

BC CD

BD2 BD2

LFU a priori not needed because BD2 bottom of stack and negotiated AchAB BD DEBD

AB BC DECDBD2 BD2

Use of pseudo-wide Label stacking* to be further specified.* : not pseudo-wire nesting

LSP OAM BC CDLFUACh

LFUACh

ABLFUACh

DELFUACh

One hop LSP OAM and Section OAM would traditionally not run concurrently

Combined LSP OAM and TCM-MS-PW

mpls architectural considerations for a transport profile

Documents