Upload
dangthuy
View
228
Download
3
Embed Size (px)
Citation preview
Enabling Efficient Packet Transport with MPLS-TP
Matthew Bocci Alcatel-Lucent [email protected]
Luyuan Fang Cisco Systems [email protected]
Ben Niven-Jenkins (BT), Nabil Bitar (Verizon), Andrew G. Malis (Verizon), Nurit Sprecher (NSN)
2
Agenda Evolving Transport Towards Packet What is MPLS-TP? MPLS-TP Architecture OAM in MPLS-TP Management, configuration and control plane Protection and Resiliency Relationship between IP/MPLS and MPLS-TP Use Cases Standardization Update Summary
3
Agenda Evolving Transport Towards Packet What is MPLS-TP? MPLS-TP Architecture OAM in MPLS-TP Management, configuration and control plane Protection and Resiliency Relationship between IP/MPLS and MPLS-TP Use Cases Standardization Update Summary
4
Wireline and Wireless
Access
IP and Ethernet Services Drive Network Transformation
Multiple Legacy Networks
Fewer layers, converged multi-function network
“Horizontalized”, more homogenized infrastructure
Enables service and network transformation
Multi-service, application aware
Converged packet-enabled transport
IP
ATM
SONET/SDH
WDM
TDM FR/ATM PSTN
Data Mobile Voice
SONET/SDH
Converged Infrastructure
IP/MPLS
Carrier Ethernet
WDM/OTN
Multiple layers, separate single function networks
“Verticalized”, stovepiped infrastructure
Complicates service and network transformation
Multiple single services
Circuit-based transport
Flexible Services
Aggregation and Core
Efficient Transport
POS
5
Simplifying Data Services and Packet Transport
Efficient Transport
Flexible IP/MPLS/ETH
Based Services
Layer 3: IP
Layer 2: Ethernet, ATM
Layer 1: SONET/SDH
Layer 0: DWDM
Layer 1/2
Layer 0/1
Layer 2/3
Profile of MPLS optimized for transport enables packet
transport
MPLS (Transport)
Already widely deployed for IP-VPN’s, multi-point services and
service aggregation
Deployed for service aggregation, may be optimized
for transport
MPLS Pseudowires
IP/MPLS
Transport
Service
Underlying layer provides framing, PHY convergence
functions, etc e.g. OTN IP-MPLS-Ethernet services over converged transport
6
Packet Transport Evolution
Explosion of packet traffic due to packet services drives demand for carrier-grade packet transport While embracing SONET/SDH features offering high-benchmark for
reliability and operational simplicity
New big "frontier" for MPLS MPLS well positioned to become the foundation for the next generation packet transport
Ethernet Ethernet +
Enhancements MPLS-TP
Connection-oriented packet transport
7
The case for MPLS in Packet Transport
MPLS-TP bridges the gap between the transport and service routing world
allowing true convergence
Is Multiservice
Is carrier-grade
Offers connection-oriented operation with TE capability
Is widely deployed in service routing and core
Will allow true convergence between packet transport and service routing
Capex and Opex savings Can be easily profiled for packet transport
SONET/SDH
Routing
Transport MPLS-TP
OTN
IP/MPLS
40G/100G/WDM expansion
8
Agenda Evolving Transport Towards Packet What is MPLS-TP? MPLS-TP Architecture OAM in MPLS-TP Management, configuration and control plane Protection and Resiliency Relationship between IP/MPLS and MPLS-TP Use Cases Standardization Update Summary
9
Operator A
Operator C
Operator D Operator B
Transport Network Environment
Client
Wholesale transport of various services at various bit rates at lowest cost per bit
High availability for each SLA: resilience (short term), maintainability (mid term) , measurability
Resilience at transport service level (sub-50ms) for each SLA, and at section level for physical breaks (sub-50ms)
Measurability by monitoring signal (connectivity, integrity and quality)
Alarms in order to assist with network operation
SLA
10
Packet Transport: Requirements on MPLS
Transport-Centric Operational Model NMS Configuration without CP, or fully Dynamic Control Plane
Transport-Optimized OAM Functions such as CC, CV, Performance Monitoring, Alarm Suppression
Not dependent on IP forwarding
Protection Switching Triggered by OAM (i.e. not dependent on dynamic signaling or CP liveliness)
Efficient operation for both dense mesh and ring topologies
Connection-Oriented Bidirectional LSPs are co-routed
No LSP merging; no ECMP
Standard MPLS Data-Path
Must operate using standard labels, standard push/pop/swap operations
(ParaphrasedfromRFC5654)
NMS Configuration without CP
Data plane capabilities independent of Control plane
11
MPLS-TP Objectives (from draft-ietf-mpls-tp-framework-07.txt)
To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies.
Enable MPLS to support packet transport services with a similar degree of predictability, reliability and OAM to that found in existing transport networks
Enablesconnec+on‐orientedop+calpackettransportbasedonwidelydeployedMPLSprotocols,withtransport‐gradeperformance&opera+onsimilartoexis+ngtransportnetworks;ensurescompa+bilitywithIP/MPLS
12
Characterising Packet Transport Services Independence between MPLS-TP network operation and
client networks supported by the service Service guaranteed not to fall below agreed level regardless
of the behaviour of other MPLS-TP clients Control/management plane isolation between networks
using service and MPLS-TP network Little or no coordination required between client using
service and MPLS-TP network All packets of a client MPLS network transparently
transported MPLS-TP server addressing and topology info hidden from
client of packet transport service
(Paraphrasedfromdraft-ietf-mpls-tp-framework-07.txt)
13
What is MPLS-TP?
Existing MPLS RFCs prior to RFC5654
• ECMP • MP2P LDP • IP forwarding
Subset to meet transport network operational requirements • MPLS/PWE3 architecture • MPLS forwarding • GMPLS/PWE3 control
MPLS
Additional functionality based on Transport Requirements
MPLS Transport Profile
14
Additional Functionality based on Transport Requirements
• Operation through NMS • Static provisioning • TE rules
Transport-like Operation
• Sub-50ms protection switching • Linear protection • Ring protection
Transport-like Resilience
• In-band OAM channels • Performance monitoring for SLA verification • Tandem connections and multi-level operation • Wire-speed operation • Alarms and AIS
Transport-like OAM
Addi+onalfeaturesforstandardIP/MPLSrouters&Op+calPacketTransportequipment;enhancedinteroperabilitybetweenservicerou+ngandop+caltransport
Addi$onalfunc$onality
15
MPLS-TP Operation
Working LSP
PE PE
Protect LSP
NMS for Network Management Control
Client node Client node
Section MPLS-TP LSP (static or dynamic)
Pseudowire (static or dynamic)
Client Signal
Connection Oriented, pre-configured working path and protect path Transport Tunnel 1:1 or 1+1 protection, switching triggered by in-band OAM Initially, NMS used with static provisioning
Section
E2e and segment OAM
16
Agenda Evolving Transport Towards Packet What is MPLS-TP? MPLS-TP Architecture OAM in MPLS-TP Management, configuration and control plane Protection and Resiliency Relationship between IP/MPLS and MPLS-TP Use Cases Standardization Update Summary
Thefollowingslidescontaintechnicaldetailsthatares+llworkinprogressatIETFincoordina+onwithITU‐TSG15
17
Architecture of MPLS-TP: P2P Service using a PW
Ethernet ATM TDM etc.
Point to Point Packet transport service
IP or MPLS LSPs Pseudowires adapt L2 services to MPLS-TP LSP Static or T-LDP signaled
PW PW
LSPs take strict path in both directions “bidirectional and co-routed” Static or RSVP-TE
Section between adjacencies at LSP layer
PE PE LSR/P
MPLS-TP
ReuseofMPLSarchitecturetomeettransportrequirements
Bidirectional MPSL-TP LSPs paring relationship
MPLS-TP LSP Section PW
18
Architecture of MPLS-TP: P2P Service using a MS-PW
Ethernet ATM TDM etc.
Point to Point Packet transport service
PW1
PW1
PWs & LSPs take strict path in both directions “bidirectional and co-routed” Static or dynamic
T-PE T-PE
S-PE
MPLS-TP
MS‐PWsenhancescalingbyreducingTELSPmeshEnableinter‐providerPW‐basedservicesEnableinteropofsta+canddynamicMPLS(‐TP)networks
Section
T-PE
PW2
PW2
PW1
PW2
19
Architecture of MPLS-TP: P2P Service for a Network Layer Client
IP, MPLS LSP
etc.
Point to Point Packet transport service
IP or MPLS LSPs Service LSP provides encap/service multiplexer Static or RSVP-TE signaled
Service LSP (optional)
LSPs take strict path in both directions “bidirectional and co-routed” Static or RSVP-TE Section between adjacencies at LSP layer
PE PE LSR/P
MPLS-TP
Service LSP (optional)
ReuseofMPLSarchitecturetomeettransportrequirements
20
Architecture of MPLS-TP: Services using P2MP LSPs
IP MPLS
Ethernet etc.
PE
Leaf PEs
LSR/P
P2MP LSP
Section between adjacencies at LSP layer
Unidirectional P2MP LSP Static or RSVP-TE
Point to multipoint packet transport service
MPLS-TP
IP, MPLS, or P2MP PW
ReuseofMPLSarchitecturetomeettransportrequirements
21
Domain of MPLS-TP Where does MPLS-TP end, and client layers begin?
LSP label S=1
IP PW label S=1
LSP label S=0
PW Payload
LSP label* S=0
LSP label S=0
PW Label
MPLS-TP layer
Client layer
Labelled services
e.g. backhaul of MPLS traffic
PW-based service
e.g. L2 private line
- S-bit follows current MPLS practice i.e. indicates non-MPLS follows - Label stacks shown are the smallest no. labels possible. These could include more labels. *Could be PHP’d
IP service e.g. router interconnect
LSP label S=1
LSP label S=0
IP S=1
22
Enabling Enhanced OAM Capabilities
LSP
PW
Three possibilities for OAM supported by MPLS 1. Hop-by-hop (e.g. control plane based) 2. Out-of-band OAM (e.g. UDP return path) 3. In-band OAM similar to transport model e.g PW Associated Channel
Section
MPLS-TP generalises PW ACH to also enable transport style OAM on MPLS LSPs & Sections
• In-band forward and return path • Increases range of OAM tools • Common tools at
PW, LSP and Section level • RFC5586 – Generic ACh
ReuseofMPLSPWOAMarchitecturetomeettransportrequirements
23
G-ACh Label Stack
LSP Label
OAM Packet Label Stack
GAL
Generic Alert Label (GAL) Identifies G-ACh packet on LSP New reserved label (Value = 13) Not needed for PWs — use control word
ACH Associated Channel Header (ACH) Reuse PW ACH on LSPs Channel Type indicates protocol
Payload
G-ACh Packet Payload E.g. OAM, Data Communication (DCC),
protection protocols, etc.
ACH TLV
ACH TLVs (optional — depends on ACH protocol) Intended for src/dst addressing, authentication, etc.
MPLS‐TPusesanewalertlabeltoiden+fypacketsontheGenericAssociatedChannel(G‐Ach)–GenericAlertLabel(GAL)
24
Associated Channel Header Indicates G-ACh packet, per RFC4385
0 0 0 1 Version Reserved Channel Type
0 4 8 16 31
Version 0000 today!
Set to zero
Indicates protocol carried in G-ACh
Highly extensible range
Common to PWs, LSPs and Sections
Uses PW associated channel type registry
• 8 experimental values
• All others Standards allocation
25
Associated Channel TLVs
ACh TLVs can be used to carry additional context information about the messages carried in the G-ACh
Some example uses include: Source Address Destination Address LSP ID Pseudowire Identifier
26
Maintenance Domains for MPLS-TP OAM
MPLS-TP uses concept of Maintenance Domains being managed/monitored
Maintenance End Points (MEPs) are edges of a maintenance domain OAM of a maintenance level must not leak beyond corresponding MEP
Maintenance Intermediate Points (MIPS) define intermediate nodes that can be monitored
Maintenance Entity Groups (MEGs) comprise all the MEPs and MIPs on an LSP
MIP/MEP can be any points along the LSP path where the LSP label is processed
LSR A LSR B LER LER
MEP MEP MIP MIP
LSP
MEG
MPLS‐TPintroducestransportmanagementconceptstoMPLSSimplifiesmanagementofpacketandcircuitbasedtransport
Maintenance Domains
MIP
27
Targeting OAM to a MEP or MIP For a MEP, GAL exposed when label popped
Ensures OAM does not leak beyond MEP
For a MIP, TTL expires, force OAM packet to be processed
Verification that OAM message received at targeted MIP/MEP for further processing
GAL <swap>
TTL=2 TTL=1
LSP Label ACH
LSP label TTL expires
GAL processed
ACH processed
<push>
LSP label popped
GAL exposed
ACH processed
LSP Label ACH
GAL <swap> <swap>
TTL=255 TTL=254 TTL=253
<push> <pop>
MPLS‐TPusescommonMPLSmechanismstoachievetransport‐orientedfunc+ons
28
Identifying MPLS-TP Entities
Need to uniquely identify the following entities: MPLS Network Elements: LSRs, PEs, etc Paths: LSPs, PWs Maintenance Entities: MEGs, MEPs, MIPs
MPLS-TP can use either: IP-based:
Compatible with existing GMPLS and PW identifiers
ITU-T based: International Carrier Code (ICC)
29
Agenda Evolving Transport Towards Packet What is MPLS-TP? MPLS-TP Architecture OAM in MPLS-TP Management, configuration and control plane Protection and Resiliency Relationship between IP/MPLS and MPLS-TP Use Cases Standardization Update Summary
30
MPLS-TP OAM Requirements
Comprehensive set of “pro-active” & “on-demand” tools, applicable to both layer (PW/tunnel/section) and domain (tandem and e2e)
Checking signal integrity, connectivity, quality Allowing for fault localization, performance monitoring Supporting remote indications and alarm suppression (server client)
Fast, data plane operation and without need for IP forwarding
31
OAM Operational Principles MPLS-TP defines a comprehensive set of
OAM tools OAM tools must be available for both
proactive and on demand operation Must not need IP forwarding in data path Operationally independent at all layers Monitoring at different nested levels
End to end monitoring Per-Domain
“Path segment monitoring”
32
OAM Function Outline Functions Description
Continuity Check Rapid, proactive detection of faults causing SLA violation
Connectivity Verification ..and Path Trace
Reactive fault localisation
Alarm Suppression / Fault Notification
Rapid indication of remote faults Prevention of alarm storms
Performance Monitoring Delay and loss measurements
Proactive non-intrusive detection of degradations causing SLA violation
Terms: LM: Loss Measurement DM: Delay Measurement FM: Fault Management
33
OAM Functions and tools
OAM functions MPLS-TP OAM ongoing work
Continuous (proactive) On demand (reactive)
Continuity Extended BFD (*) Extended LSP Ping (**)
Connectivity (path verification)
Extended BFD Extended LSP Ping
Quality New LM and DM tools New LM and DM tools
Fault Localization Not applicable Extended LSP Ping
Remote integrity Extended BFD Extended LSP Ping
Silencing (alarm suppression)
New FM tool Not applicable
* BFD to be extended for pro-active CC- CV and RDI
** LSP Ping to be extended for on-demand CV and TraceRoute
Design guidelines: Reuse/extend MPLS tools as much as possible, ensure interoperability
34
Example OAM functionality: Proactive Continuity Check w/o IP
LSR A LSR B LER A LER B
LSP1
BFD running on G-ACh Optimized for transport network operation - No UDP headers – similar to VCCV - Static configuration of parameters
• Initiated by a source MEP, and processed by the sink MEP • Configurable interval for fast failure detection* • If no CC received in 3.5 times interval, Loss of Continuity defect
*Between 3.3ms to 10min
MEP MIP MIP MEP
35
Example OAM functionality: Proactive Connectivity Verification
LSR A LSR B LER A LER B
LSP1
LSR B LER C
LSP2
BFD packet injected into LSP 2 - ACH TLV: ME ID (x)
BFD packet received on LSP 1 - ACH TLV: ME ID (x)
Mis-connection (mis-swap)
• Detects miss-merge or miss-connection through wrong ME identifier • Detects MEP miss-configuration through wrong peer MEP identifier • Detects period miss-configuration (different from its own)
MEP MIP MIP MEP
MIP MEP
36
Example OAM functionality: Path Segment Monitoring
Path segment monitoring enables a subset of the segments of an LSP to be monitored independently of any end-to-end OAM Tandem monitoring in terms of connectivity, fault and
quality, as well as alarms Achieved via standard MPLS label stacking
LSR A LSR B LER LER
MEP MEP MIP MIP
LSP
MEP MEP
Pathsegmentmonitoring
End‐to‐endmonitoring
37
Example: Alarm Reporting using AIS
Domain B Domain A
Client Client Sec. LSP
MS-PW
Fiber cut generates alarms in physical layer, section, LSP, PW (TCM) and MS-PW
Only fiber cut alarm needs to be reported to NMS Alarms on LSPs / PWs running CC need to be
suppressed using AIS packets
NMS
AIS AIS
38
Example: Performance Monitoring Loss, Delay and Delay Variation measurements Delay and Loss measurements can be proactive
or on-demand and rely on sending LM/DM packets from MEP to MEP for exchanging counters/timestamps
Delay Measurements can be one way and two way One way contains all the information in the packet send
from source MEP to sink MEP Two way requires sink MEP to reply back with the
relevant information
39
Example: Performance Monitoring (draft-frost-mpls-tp-loss-delay-00)
At T1: A sends Loss Measurement (LM) query messages to B contains the count of packets transmitted prior to time T1 over the connection to B (A_TxP).
At T2: B appends two values and reflects the message back to A the count of packets received prior to time T2 over the connection from A (B_RxP)
At T3: B sends response back to A the count of packets transmitted prior to time T3 over the connection to A (B_TxP).
At T4: When the response reaches A, it appends a fourth value the count of packets received prior to time T4 over the connection from B (A_RxP).
These four counter values enable A to compute the desired loss statistics.
LSR A LSR B
T1 T2
T3 T4
QUERY
RESPONSE
40
Agenda Evolving Transport Towards Packet What is MPLS-TP? MPLS-TP Architecture OAM in MPLS-TP Management, configuration and control plane Protection and Resiliency Relationship between IP/MPLS and MPLS-TP Use Cases Standardization Update Summary
41
Management and Control for MPLS-TP MPLS-TP control plane based on existing MPLS-based
control plane protocols GMPLS for LSPs
ISIS-TE, OSPF-TE for topology distribution RSVP-TE for signalling
T-LDP for PWs Both of these already support bidirectional connections Pug-and-play SCC over LSPs or sections for signaling in
absence of native IP support in server layer MPLS-TP can be operated in absence of control plane
NMS configuration Static assignment of labels Plug-and-play MCC over G-ACh carries NMS traffic
Operation of MPLS-TP data plane is independent of configuration mechanism
SCC: Signaling Communication Channel MCC: Management Communication Channel
42
Data Communication Network using G-Ach: Carries MCC or SCC
LSPSec$on
NMS NMS
LSRA LSRB
GALACH
ACHTLV
DCNMessage
SCCorMCC
ProtocolID
DCNonSec+on
GALACH
ACHTLV
DCNMessage
SCCorMCC
ProtocolID
DCNonLSP
LSP
43
MPLS-TP LSP Control Plane (GMPLS) GMPLS is a unified, generalized distributed control plane used for multiple networking technologies, including packets, TDM and WDM I(nternal)-NNI concept (the only one supported in MPLS CP)
E(xternal)-NNI concept (thus allowing for interworking among different vendors/operators)
Bidirectional paths
GMPLS allows for separation of data plane and control plane Only control interfaces are used to flood control information
GMPLS allows for “horizontal” scalability in routing domains (thanks to separation of data plane and control plane and recursive topology)
GMPLS allows for “vertical” scalability (same control plane across different layers)
44
MPLS-TP PW Control Pane (Targeted LDP) T-LDP universally deployed today for PW
Lightweight protocol allows for service scalability Signals binding of PW label to FEC Will use FEC 129 with MPLS-TP
Global-ID + Node Prefix + AC-ID Allows routing scalability with aggregation and domain
partitioning Establishes and maintains each direction of a SS-
PW or MS-PW Enables encapsulation to be negotiated, as well as
PW status to be signaled When used with a MS-PW, supports bidirectional,
co-routed PWs
45
Creation of: UNI and NNI Tunnel, LSP PW service at the Ethernet UNI:
E-Line, E-LAN, E-Tree Association of the service to PWs:
service mapped to FEC by classification at UNI Classification parameters
are Port, VID, P-bits, IP DSCP, Client Ethertype…
Service Set-up
MPLS-TP
physical link
UNI / NNI Interfaces
MPLS-TP
physical link Tunnel
Termination (LER) Tunnel Swap
(LSR)
MPLS-TP
physical link PW
Termination PW Termination
PW Swapping
46
Agenda Evolving Transport Towards Packet What is MPLS-TP? MPLS-TP Architecture OAM in MPLS-TP Management, configuration and control plane Protection and Resiliency Relationship between IP/MPLS and MPLS-TP Use Cases Standardization Update Summary
47
MPLS-TP Resilience MPLS-TP
Multiservice Access Ring
Prot.
LSP Protection
Section Protection IP/MPLS
Ethernet, TDM, ATM,
NMS or ASON/GMPLS
Wire-speed OAM
PW protection
< 50ms with PSC protocol trigged by data-plane OAM
1+1, 1:1, 1:N, without extra traffic
Unidir, Bidir Section, LSP, PW Subnetwork Connection (SNCP) Mesh and Ring
Protection (data plane) GMPLS based restoration for LSP in
synergy with other transport network technologies (SONET, OTN, WDM)
PW redundancy LSP fast reroute GMPLS segment end-to-end
protection Pre-planned LSP rerouting
restoration Any topology
Restoration (ctrl. and mgmt. plane)
PSC: Protection State Coordination
48
Data plane: Linear 1+1 protection
Recovery path
Working path
Transport path: PW, PST, LSP, TC
PB SB
Permanent Bridge Selector Bridge
LSR LSR Permanent Bridge sends traffic on both working and recovery
paths Selector bridge selects path Applicable to p2p and p2mp, uni and bi-directional PSC protocol for bi-directional, to synchronize both ends
PST: Path Segment Tunnel TC: Tandem Connection
Permanent Bridge Selector bridge
49
Data Plane: Linear 1:1 protection
Recovery path
Working path
Transport path: PW, PST, LSP, TC
SB SB
Selector Bridge Selector Bridge
LSR LSR
PSC protocol for synchronization between selector bridges Always sent over the recovery path over the GACH Upon failure, three PSC packets sent at 3.3 ms intervals to
trigger switchover in sub-50ms Supports revertive and non-revertive, uni and bi-directional
operation
PSC
50
Data Plane: Ring Protection
Ring operation of importance in transport scenarios due to existing fiber layout Optimizations possible in rings
Many ring-specific protection scheme developed (RPR, ERP, UPSR, BLSR…) in existing technologies
FRR can be fully applied to rings FRR does not provide bi-directional protection
switching. Linear protection does.
Several schemes discussed in MPLS-TP (work in progress) Based on Optimizing FRR (FRR-Transport Profile and
Ring Optimized FRR) Multipoint protection switching Based on G.8132-like mechanism
Protec+onop+mizedwithknowledgeofringtopology
51
Control Plane Based Protection
MPLS-TP uses existing GMPLS and PW control planes
Inherits existing control plane based protection/restoration mechanisms applicable to uni/bi-directional paths
LSPs: GMPLS protection mechanisms PWs: PW Redundancy
Correct forwarding if dual-homed AC fails-over Protection if S-PE fails on MS-PW
52
GMPLS Protection GMPLS defines recovery signaling for
P2P LSPs in [RFC4872], RSVP-TE extensions in support for end-to-end GMPLS recovery
and [RFC4873] for GMPLS segment recovery. GMPLS segment recovery provides a superset of
the function in end-to-end recovery1. All five of the protection types defined for recovery are
supported in MPLS-TP. 1+1 bidirectional protection for P2P LSPs 1+1 unidirectional protection for P2MP LSPs 1:n (including 1:1) protection with or without extra traffic Rerouting without extra traffic (sometimes known as soft
rerouting), including shared mesh restoration Full LSP rerouting
1Use of Notify messages to trigger protection switching and recovery is not required in MPLS-TP as this is expected to be supported via OAM. However, it's use is not precluded. The restoration priority and The preemption priority are supported
53
PW Redundancy
MPLS-TP component of end-to-end protection against PE/AC failures PE configured with multiple pseudowires per service with multiple end-points Local precedence indicates primary PW for forwarding if multiple PWs are
operationally UP PW status exchanged end-to-end to notify PEs of operational state of both PWs
& ports/attachment circuits (PW Status Notification).
(For more details, please attend the BBF “MPLS in the RAN” tutorial at 4PM today)
• RNC
MPLS-TP network
AC redundancy: MC – APS MC - LAG
ATM (IMA)
Ethernet Node B
3G active
standby
AC redundancy protocol drives forwarding state of PWs/PEs
Forwarding direction determined by PW state
PW status
Active/standby state of LAG/APS sub-groups reflected in PW status
54
Protection for static PWs
Static PWs are common in MPLS-TP PW status messaging can be extended to
static PWs when T-LDP control plane absent
Carry PW status TLV in PW associated channel, instead of over T-LDP
draft-martini-pwe3-static-pw-status-02.txt
55
Static PW Status Messaging
Ethernet ATM TDM etc.
PW PW
MPLS-TP LSP
T-PE T-PE
MPLS-TP
S-PE
T-LDP static
PW status
Carried in T-LDP signaling across dynamic segment
Carried in ACH across static segment PW label TTL=1 ensures single hop (S-PE-T-PE) propagation
PW status TLV:
56
LSP and PW working/protect Relationships
Working PW configured over LSP Green with working and protect paths. When LSP Green working path fails, switches to LSP Green Protect. No PW
failover is needed. PW redundancy takes place when both LSP Green Working and Protect
paths fail, in that case, PW will switch to the protect PW which is configured on the LSP Red tunnel interface with working and protect path.
LSP Red Working
LSP Red Protect
Working PW over LSP Green
LSP Green Protect
LSP Red Working
Protect PW over LSP Red
57
Agenda Evolving Transport Towards Packet What is MPLS-TP? MPLS-TP Architecture OAM in MPLS-TP Management, configuration and control plane Protection and Resiliency Relationship between IP/MPLS and MPLS-TP Use Cases Standardization Update Summary
58
MPLS-TP and IP/MPLS are one technology set For both IP edge routing and transport
Brings benefits to the IP edge routing toolset Transport-oriented OAM features for more predictable services
Peer interworking with a hybrid optical transport network to reduce OPEX
Seamless delivery of packet transport services from IP edge routing and transport networks
MPLS-TP: Relationship to IP/MPLS
Commonsetofnewfunc+onsapplicabletobothMPLSnetworksingeneral,andtothoseofMPLS‐TPprofile
IP
MPLS‐TP
Convergedservicerou$ngMPLSNetwork
59
Example: Access/Aggregation using MPLS-TP
PWE3 e2e MPLS-TP OAM
LSP [Static/GMPLS-RSVP-TE]
LSP MPLS-TP OAM
LSP [RSVP-TE/LDP]
LSP MPLS-TP OAM /BFD/RSVP/IGP
LSP [Static]
Section OAM
IP/MPLS w/MPLS-TP
IP/MPLS w/MPLS-TP
MPLS-TP
Hybrid optical aggregation
Full feature IP aggregation
MS-PW (static/T-LDP)
MS-PW (static/T-LDP)
MS-PW (T-LDP)
PW hand-off between networks Optical and IP platforms act as S-PEs Common, end-to-end TP functions
IP network cherry-picks TP functions
60
Agenda Evolving Transport Towards Packet What is MPLS-TP? MPLS-TP Architecture OAM in MPLS-TP Management, configuration and control plane Protection and Resiliency Relationship between IP/MPLS and MPLS-TP Use Cases Standardization Update Summary
61
Business VPN Services
MPLS-TP/Optical Metro Network
IP/MPLS-TP Metro Core
IP/MPLS-TP
Core
Enterprise
Enterprise
Internet
IMS, Video Servers
Enterprise
IP/MPLS-TP Metro
Consistent PW Forwarding, OAM, & Resiliency Options End-End Across Domains
PW
MPLS-TP extensions can be used selectively (e.g. per-domain, per-service) in
IP/MPLS networks
VPNs across geographically distributed networks
Several transport and IP/MPLS metro and core segments
Interop between transport and routing (OAM, bandwidth provisioning, QoS, resilience)
Enterprise bandwidth services Enterprise access to
voice, video, & VPN services
VPN
62
Carrier’s Carrier Service Provider
Service Provider (or Large
Enterprise)
Service Provider (or Large
Enterprise)
Service Provider (or Large
Enterprise)
Service Provider (or Large
Enterprise)
MPLS-TP/Optical Transport Network
Highly Scalable, Packet-Optimized Transport
MPLS-TP End-End & Per-Domain Connection Monitoring
Highly segmented topologies with several nested service providers/enterprises
OAM with e2e as well as per domain capabilities to isolate problems MPLS-TP OAM supporting path segment monitoring
Multiplexed, flexible- bandwidth LSP UNIs
SP Trunks & Enterprise WAN Connections
63
Mobile Backhaul
Multiservice transport for Ethernet, TDM, ATM, IP using PW Performance monitoring for new services (delay for VoIP) Fast protection Interoperability with IP/MPLS ePC and in RAN Support for E-LAN and E-Line for S1 and X2 interfaces Support for L2VPNs
BSC / RNC
BTS
Node B
Node B eNB
Evolved packet Core (IP/MPLS)
Circuit core
Backhaul transport (MPLS-TP with or w/o IP)
IP
ATM
TDM
P- GW
MME S- GW
64
Agenda Evolving Transport Towards Packet What is MPLS-TP? MPLS-TP Architecture OAM in MPLS-TP Management, configuration and control plane Protection and Resiliency Relationship between IP/MPLS and MPLS-TP Use Cases Standardization Update Summary
65
IETF/ITU-T Joint Working Team Consensus on MPLS in Transport
IETF and ITU-T formed Joint Working Team Achieved consensus: agree to work together and bring transport requirements into the IETF
and extend IETF MPLS forwarding, OAM, survivability, network management, and control plane protocols to meet those requirements through the IETF Standards Process.[RFC5317]1
1: [RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile, Feb. 2009.
Definition of MPLS “Transport Profile” (MPLS-TP) protocols, based on ITU-T requirements
Derivation of packet transport requirements
Integration of IETF MPLS-TP definition into transport network recommendations
Providing MPLS-TP Recommendations per IETF definitions
66
IETF MPLS-TP Development
Requirements (MPLS WG)
Transport Profile Architectural Framework (MPLS WG)
G-Ach Definition (MPLS WG)
OAM (MPLS WG)
Survivability (MPLS WG)
Control Plane (CCAMP WG)
Network Management (MPLS WG)
IETF developing a set of MPLS-TP specs under umbrella of ‘MEAD team’ First set already approved during 2009
draft-ietf-mpls-tp-framework draft-ietf-mpls-tp-oam-framework
JWT report: RFC5317 Requirements: RFC5654 GACH: RFC5568 DCN: RFC5718 draft-ietf-mpls-tp-nm-req (WG last call) draft-sprecher-mpls-tp-oam-analysis draft-ietf-mpls-tp-oam-requirements
RFC5586 draft-ietf-mpls-tp-survive-frmwk
Many additional individual drafts proposing MPLS-TP functions
RFC5718
See http://tools.ietf.org/id/mpls-tp http://wiki.tools.ietf.org/misc/mpls-tp/
Several I-Ds on mechanisms
67
IETF Work on MPLS-TP
The IETF MPLS-TP design team has successfully achieved its objectives.
The main requirements work has been published, and two subsidiary requirements documents (NM and OAM) are close to publication.
The core work on the frameworks and solutions has started and are progressing.
Further work on MPLS-TP continues using the IETF normal process to allow
Open participation by everyone in the industry, New items to be introduced more quickly. Streamlining the process
68
MPLS-TP Elements – Standardization Status
69
MPLS-TP Specific Documents
Four RFCs
Informational RFC 5317: “JWT Report on MPLS Architectural Considerations for a Transport Profile“
Standard RFC 5586: “MPLS Generic Associated Channel” The basic architectural elements of MPLS-TP are fully defined!
Standard RFC 5654: “Requirements of an MPLS Transport Profile “
Standard RFC 5718 on An In-Band Data Communication Network For the MPLS Transport Profile
More than ten IETF WG drafts (in MPLS, PWE3 and Opsawg WGs). One of them is in the RFC editor queue and another is under the IESG processing.
More than thirty individual documents on OAM tools and entitles, linear and ring protection, control plane, management plane, interworking with IP/MPLS and security.
70
MPLS-TP Documents’ Structure
RFC
IETF Document under IESG Review
IETF Document
Individual documents
71
IETF and ITU-T Collaboration
ITU-T G.81xx
IETF RFCs
ITU-T G.81xx
ITU-T
IETF
Joint Working Team (JWT)
Alignment Converged
MPLS Transport
Specs Transport
requirements
MPLS-TP
MPLS-TP MPLS
IETF RFCs
IETF Drafts
Draft Recs
Review
72
Agenda Evolving Transport Towards Packet What is MPLS-TP? MPLS-TP Architecture OAM in MPLS-TP Management, configuration and control plane Protection and Resiliency Relationship between IP/MPLS and MPLS-TP Standardization Update Summary
73
The goal: MPLS-transport profile For next-generation converged
packet network supported in service routing and transport platforms for convergence
Consistent operations and OAM between both routing and transport domains to enable seamless interconnection
Standards definition focused on five topics: OAM, protection, forwarding, control plane and management
Significant advantage over Ethernet-centric alternatives due to commonality with MPLS
74
IETF RFC and WG Draft Reference
IETF RFCs published RFC 5317: JWT Report on MPLS Architectural Considerations for a
Transport Profile RFC 5586: MPLS Generic Associated Channel RFC 5654: MPLS-TP Requirements RFC 5704: Uncoordinated Protocol Development Considered Harmful RFC 5718: An In-Band Data Communication Network For the MPLS
Transport Profile IETF WG drafts
draft-ietf-mpls-tp-framework-07.txt draft-ietf-mpls-tp-nm-req-06.txt draft-ietf-mpls-tp-oam-framework-04.txt draft-ietf-mpls-tp-survive-fwk-03.txt draft-ietf-mpls-tp-nm-framework-04.txt draft-ietf-mpls-tp-rosetta-stone-01 draft-ietf-mpls-tp-process-04.txt draft-ietf-mpls-tp-oam-analysis-00.txt draft-ietf-mpls-tp-identifiers-00.txt
75
www.alcatel-lucent.com Thank You! Please come and see further MPLS-TP
presentations on Wednesday 10th February