mpls architectural considerations for a transport profile
DESCRIPTION
MPLS Architectural Considerations for a Transport Profile. ITU-T - IETF Joint Working Team Dave Ward, Malcolm Betts, ed. March 25, 2008. What am I reading?. - PowerPoint PPT PresentationTRANSCRIPT
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
Penultimate Hop Popping
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
Penultimate Hop Popping
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
LFU – Label For You (label 13|14)ACh – Associated ChannelCW – Control Word
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
0001 | Ver | resv | Channel Type
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
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 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
0001 | Ver | resv | Channel Type
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
LFU – Label For You (label 13|14)ACh – Associated ChannelCW – Control Word
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