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 • Cisco • Stewart Bryant, Luca Martini, George Swallow, Ali Sajassi, Simon Spraggs, Mark Townsley, Joe Wojtal, Dave Ward • Ericsson • Dave Sinicrope • Juniper • Ross Callon, Kireeti Kompella, Rahul Aggarwal, Thomas Walsh • Nortel • Malcolm Betts, Stephen Shew

4. How is the effort organized? • In ITU-T • TMPLS ad hoc group • In IETF • MPLS interoperability design team • DMZ between the SDOs: Joint Working Team • Segmented into groups looking at • Forwarding • OAM • Protection • Control Plane • 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/PWE • Initiates 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 • 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 • 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 MPLS-TP solution must exist over this spectrum Connection Orientated Multi-service (Connectionless and Connection Orientated) Connectionless 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 L3 only L1, L2, L3 Services Pt-Pt, Pt-MPt, MPt-MPt L1, L2 Services Pt-Pt and Pt-MPt 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 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. Static provisioning and dynamic control plane Anticipated 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 MPLS+TP Static Provisioning Network Management System Control Plane for PT2PT services OAM OAM OAM Forwarding Tables Edge Forwarding Tables Forwarding Tables Edge

12. MPLS Transport Profile - Terminology Emulated Service Pseudo-wire Multi-node PSN cloud • Definition of an MPLS Transport Profile within IETF MPLS standards • Based 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? Attachment Circuit Attachment Circuit CE1 CE2 PE1 PE2 PW1

13. MEP MEP MEP MEP MEP MEP MEP MEP Multi segment Transport LSP example Service Provider Carrier 1 Carrier 2 PE PE CE or PE? P PE P PE CE or PE? UNI or NNI? NNI UNI or NNI? end to end OAM MEP MIP MIP MIP MIP MEP per carrier OAM MEP MEP MIP MIP <<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.>> • 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 MEP: Maintenance End Point MIP: Maintenance Intermediate Point Note: A policing function (traffic management/shaping) is normally co located with a MEP at a business boundary (UNI/NNI)

14. MEP MEP MEP MEP MEP/MIP architecture updated Nested segment example Carrier 1 Region 1 Region 2 PE2 PE3 PE1 P PE4 P PE5 PE6 NNI INNI NNI end to end OAM MIP MIP MIP MIP per carrier OAM MEP MIP MIP MEP per region OAM MEP MIP MIP MEP • 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

15. Bi directional Paths • External Static Provisioning • NMS responsible for configuration and ensuring bi-directional congruency • If Dynamic Control Plane • GMPLS bidir RSVP for LSP path establishment

16. 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? 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 • 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 detectionand 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>> A B C D E F Segment Protection

20. OAM mechanisms

21. A B C D E F 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 Channel • Includes End to End and segment LSPs • Used to carry a variety of OAM, Mgmt, signalling protocols. • Pseudo-wires : PWE-3 Associated Channel L1/L2 L1/L2 L1/L2 L1/L2 L1/L2 Segment LSP Midpoint End to End LSP Pseudo-wire

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, or • Label 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 LFU • In 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-wire • 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 • Generalised Associated Channel defines what packet function using “channel type” field • Examples : What OAM function is carried, DCC, etc LFU/BoS L2 MAC Header L1 Generic ACH Channel payload 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) PWL/BOS L2 MAC Header L1 Control Word Payload 0000 | Specified by encapsulation PWL/BOS L2 MAC Header L1 PWE-3 ACH Channel payload 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 information • Maybe even signalling information in non IP environments • 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 (MCC and SCC) • Via routed IP or Associated channel 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) • 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 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 • MCC • Management communication • SCC • Control plane communications • APS • Protection 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 monitoring • Detailed 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 set • MEP 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. LFU – Label For You (label 13|14) ACh – Associated Channel CW – Control Word SS-PW, LSP and TCM-LSP OAM A B C D E Section OAM LFU LFU LFU LFU ACh ACh ACh ACh TCM-LSP OAM BC CD LFU LFU ACh ACh E2E (A to E) LSP OAM BC CD AB BD BD DE LFU LFU LFU LFU ACh ACh ACh ACh E2E (A to E) PW OAM BC CD AB BD BD DE AE AE AE AE ACh ACh ACh ACh Non OAM Data Frames TCM-LSPs BC CD E2E LSP AB BD BD DE SS-PW AE AE AE AE CW CW CW CW

30. LFU – Label For You (label 13|14) ACh – Associated Channel CW – Control Word SS-PW over inter-domain LSP Domain A Domain B A B C D E F Section OAM LFU LFU LFU LFU LFU ACh ACh ACh ACh ACh One hop TCM-LSP OAM and Section OAM would traditionally not run concurrently TCM-LSP OAM AB BC DE EF LFU LFU LFU LFU ACh ACh ACh ACh Manual stiching in C and D E2E LSP OAM AB BC DE EF AC AC CD DF DF LFU LFU LFU LFU LFU ACh ACh ACh ACh ACh E2E PW OAM AB BC DE EF AC AC CD DF DF AF AF AF AF AF ACh ACh ACh ACh ACh Non OAM Data Frames TCM-LSPs AB BC DE EF E2E LSP AC AC CD DF DF SS-PW AF AF AF AF AF CW CW CW CW CW

31. OAM operations

32. Pseudo-wire OAM processing A B C D E F • 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 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

33. LSP End Point processing A B C D E F • 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 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

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 LFIB:CD-DE LSP OAM LFIB:AB-BC DE, PW-L E Primary Path LFIB:BC-CD PW-L, AB A YZ, PW-L LFIB:XY-YZ PW-L, AW LFIB:WX-XY LFIB:AW-WX Backup Path LSP OAM

35. LFIB:CD-DE D LFIB:AB-BC B DE, PW-L E Segment Primary Path LFIB:BC-CD PW-L, AB A YZ, PW-L LFIB:XY-YZ PW-L, AW Segment Backup Path LFIB:WX-XY LFIB:AW-WX LSP OAM 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

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 MCC • Can 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 independently • Multiple 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 architecture • IETF 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 • 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 • 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 • 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 PWE-L/BOS L2 MAC Header L1 Control Word Payload • 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) • 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 Label • RFC 4928 implemented through use of control word and PWE-3 ACH • RFC 4385 for Control Word and PW associated Channel formats 0000 | Specified by encapsulation PWE-L/BOS L2 MAC Header L1 PWE-3 ACH OAM message 0001 | Ver | resv | Channel Type This is a start of ECMP considerations and a place to discuss load-balance labels

47. LSPs / OAM and Label Stacks Alternate approach using stacked PWsNot 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. LFU – Label For You (label 13|14) ACh – Associated Channel CW – Control Word TCM-MS-PW OAM B and D are S-PEs A B C D E Section OAM LFU LFU LFU LFU LFU a priori not needed because BD2 is bottom of stack and Ach has been negotiated ACh ACh ACh ACh LSP OAM not shown here TCM-PWE (B to D)OAM BC CD Use of pseudo-wide Label stacking* to be further specified. * : not pseudo-wire nesting BD2 BD2 ACh ACh E2E (A to E) PW OAM BC CD AB BD2 BD2 DE AB BD BD DE ACh ACh ACh ACh AB-BD pw label swap BD2 pw label push BC lsp label push Non OAM Data Frames LSPs AB BC CD DE TCM-PWE BD2 BD2 MS-PW AB BD BD DE CW CW CW CW

49. Combined LSP OAM and TCM-MS-PW LFU – Label For You (label 1314) ACh – Associated Channel CW – Control Word B and D are S-PEs A B C D E Section OAM LFU LFU LFU LFU ACh ACh ACh ACh One hop LSP OAM and Section OAM would traditionally not run concurrently LSP OAM AB BC CD DE LFU LFU LFU LFU ACh ACh ACh ACh TCM-PWE (B to D)OAM Use of pseudo-wide Label stacking* to be further specified. * : not pseudo-wire nesting BC CD BD2 BD2 ACh ACh E2E (A to E) PW OAM BC CD AB BD2 BD2 DE AB BD BD DE LFU a priori not needed because BD2 bottom of stack and negotiated Ach ACh ACh ACh ACh Non OAM Data Frames LSPs AB BC CD DE TCM-PWE BD2 BD2 MS-PW AB BD BD DE CW CW CW CW