* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download TDMoIP : IPR
Survey
Document related concepts
Network tap wikipedia , lookup
Point-to-Point Protocol over Ethernet wikipedia , lookup
Computer network wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Airborne Networking wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Internet protocol suite wikipedia , lookup
Deep packet inspection wikipedia , lookup
Wake-on-LAN wikipedia , lookup
IEEE 802.1aq wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Transcript
MPLS Yaakov (J) Stein February 2006 Chief Scientist RAD Data Communications Why study MPLS? it’s new it’s different and interesting along with IPv6 it will save the Internet it enables delivery of IP VPN services it facilitates pseudowire functionality all of the above Y(J)S MPLS Slide 2 Course Outline 1) Introduction 2) MPLS Forwarding Component 3) MPLS Control Component 4) MPLS Traffic Engineering 5) MPLS Applications Y(J)S MPLS Slide 3 1 2 3 4 5 1 2 3 4 5 Introduction 1.1 Review of forwarding and routing 1.2 Problems with IP routing 1.3 Label Switching Y(J)S MPLS Slide 4 Forwarding and Routing a router (switch) performs 2 distinct algorithms forwarding algorithm (forwarding component) routing algorithm (control component) may be manual configuration or signaling protocol from the forwarding point of view there are three different types of network: broadcast (e.g. Ethernet) connectionless (e.g. IP) connection oriented (e.g. ATM) 1.1 Y(J)S MPLS Slide 5 Broadcast (e.g. Ethernet) not for me for me!! not for me not for me not for me not for me not for me message is sent to all possible recipients all receivers check message destination address if message destination address does not match receiver’s address message ignored (except in promiscuous mode) if message destination address matches receiver’s address message processed 1.1 Y(J)S MPLS Slide 6 Connectionless Forwarding broadcast is only practical for small networks (e.g. LANs) large networks can be broken into subnetworks with routers performing the internetworking such a network is connectionless (CL) if no setup is required before sending data CL forwarder (router) each router makes independent forwarding decision packets are self-describing packet inserted anywhere will be properly forwarded Notes: – the address must have global significance – IP actually relies on a L2 protocol (Ethernet, PPP) for final stage 1.1 Y(J)S MPLS Slide 7 IP Routing Distance Vector (Bellman-Ford), e.g. RIP – send <addr,cost> to neighbors – routers maintain cost to all destinations – need to solve “count to problem“ Path Vector, e.g. BGP – – – – – send <addr,cost,path> to neighbors similar to distance vector, but w/o “count to problem“ like distance vector has slow convergence* doesn’t require consistent topology can support hierarchical topology => exterior protocol (EGP) Link State, e.g. OSPF, IS-IS – send <neighbor-addr,cost> to all routers – determine entire flat network topology (Dijkstra’s algorithm) – fast convergence*, guaranteed loopless => interior routing protocol (IGP) *convergence time is the time taken until all routers work consistently before convergence is complete packets may be misforwarded, and there may be loops 1.1 Y(J)S MPLS Slide 8 IP Forwarding what field is used for forwarding? field used depends on application regular: use longest destination prefix match ToS: use longest destination prefix match + exact match on ToS multicast: use longest/exact match on source/group address how is forwarding performed? forwarding algorithm depends on routing algorithm! for Distance Vector - forward by cost for Path Vector - forward by cost and path for Link State - Dijkstra’s algorithm 1.1 Y(J)S MPLS Slide 9 Connection Oriented Forwarding CO forwarder (switch) input ports 1 1 2 2 3 3 4 4 5 5 output ports each forwarder maintains forwarding table (or table per input port) control component: route must be set-up (table must be updated) before data sent set-up may be manual or signaled once route no longer needed it should be torn-down 1.1 Y(J)S MPLS Slide 10 CO Forwarding CO addresses need not have global significance by using locally defined addresses: addresses are smaller in size no need for global allocation mechanism no need to maintain global database L2 forwarding is based on address read and swap 12 17 23 Note: when addresses are purely local CO forwarding is called L2 (link layer) forwarding 1.1 Y(J)S MPLS Slide 11 CO Forwarding Table input port input address output port output address 1 21 2 21 1 37 1 21 2 12 5 12 3 5 5 12 4 15 3 37 Note: never really have an input port column either it is irrelevant (CO address is per switch not per input port), or if needed (e.g. ATM) we keep separate tables per input port (more efficient) 1.1 Y(J)S MPLS Slide 12 CO Routing for CO forwarding we need to find a route at setup – manual configuration (strict explicit route) – use routing protocols (e.g. P-NNI for ATM) CO routing protocols search for a global path – hence they can guarantee global characteristics (SLA) – pure CL routing can not guarantee path QoS information source usually knows desired characteristics so usually use source routing source routing – can force route to go through specific forwarders (loose explicit route) – can reject forwarders that can not guarantee needed characteristic – can request resource reservation in selected forwarders 1.1 Y(J)S MPLS Slide 13 Problems with IP routing scalability – router table overload – routing convergence slow-down – increase in queuing time and routing traffic – problems specific to underlying L2 technologies hard to implement load balancing QoS and Traffic Engineering problem of routing changes difficulties in routing protocol update lack of VPN services 1.2 Y(J)S MPLS Slide 14 Scalability when IP was first conceived scalability was not a problem as IP traffic increases, routing shows stress simplistic example – N hosts – each router serves M hosts – each router entry takes a bytes hence – router table size a N ~ N – N / M ~ N routers (more routers => slower convergence) – packet processing time* ~N (since have to examine entire table) – ~N routers send to ~N routers tables of size ~N so routing table update traffic increases ~N 3 (or ~N 4 ) * IP routing requires 1000s of clocks per decision 1.2 Y(J)S MPLS Slide 15 L2 Backbone Scalability instead of expensive and slow IP routers we can use faster and cheaper ATM switches in core ATM Classical IP over ATM but this doesn’t help! ATM switches are transparent to routers since ATM switches do not participate in IP routing protocols every IP router must be logically adjacent to every other and we need ~ N2 ATM VCs ! if only the ATM switches could understand IP routing protocols! 1.2 Y(J)S MPLS Slide 16 Load Balancing A “fish diagram” D 2 B C G 1 3 4 E F 2 3 using hop-count as path cost traffic destined for G from both A and B goes through D so links CD and DG become congested while links CE, EF, and FG are underutilized since IP forwarding uses only destination address this can’t be overcome in pure IP routing problem even exists in equal-cost multi-path (ECMP) case solution requires traffic engineering 1.2 Y(J)S MPLS Slide 17 QoS and TE pure IP, being CL, can not guarantee path QoS but other protocols in the IP suite can help TCP adds CO layer compensating for loss and misordering IntServ (RSVP) sets up path with reserved resources DiffServ (ToS) prioritizes packets (neither -Serv widely deployed) so IP network managers mostly use network engineering – i.e. throw BW at the problem rather than traffic engineering – i.e. optimally exploit the BW you have 1.2 Y(J)S MPLS Slide 18 Routing Changes IP routing is satisfactory in the steady state but what happens when something changes? change in routing information (new router, router failure, new inter-router connection, etc) necessitates updating of tables of all routers convergence will be slow change in routing protocol is even worse (e.g. Bellman-Ford to present, classes to classless, IPv4 to IPv6) necessitates upgrade of all router software upgrade may have to be simultaneous need more complete separation of forwarding from routing functionality 1.2 Y(J)S MPLS Slide 19 VPN Services 192.115.243.79 192.115.243.19 IP 192.115.243.19 IP was designed to interconnect LANs not to provide VPN services all routers logically interconnected, so security weak LANs may use non globally unique addresses (present solution - NAT) complex provider - customer relationship VC-merge problem (discussed later) 1.2 Y(J)S MPLS Slide 20 Solution - Label Switching CO forwarder (switch) CL forwarder (router) LSR label switching adds the strength of CO to CL forwarding label switching has three stages: – routing (topology determination) using L3 protocols – path setup (label binding and distribution) – data forwarding label switching the solution to all of the above problems – – – – speeds up forwarding decreases forwarding table size (by using local labels) load balance by explicitly setting up paths complete separation of routing and forwarding algorithms no new routing algorithm needed but new signaling algorithm may be needed 1.3 Y(J)S MPLS Slide 21 Where is it? unlike TCP, the CO layer lies under the CL layer if there is a broadcast L2 (e.g. Ethernet), the CO layer lies above it higher layers layer 3 (e.g. IP) label switching (layer 2.5) shim header layer 2 (e.g. ethernet) physical layer hence, label switching is sometime called layer 2.5 switching 1.3 Y(J)S MPLS Slide 22 Labels a label is a short, fixed length, structure-less address the following are not labels: telephone number (not fixed length, country-code+area-code+local-number) Ethernet address (too long, note vendor-code is not meaningful structure) IP address (too long, has fields) ATM address (has VP/VC) not explicit requirement, but normally only local in significance label(s) added to CL packet, in addition to L3 address layer 2.5 forwarding may find a different route than the L3 forwarding is faster than L3 forwarding requires a flow setup process and signaling protocol 1.3 Y(J)S MPLS Slide 23 Forwarding Equivalence Class equivalence class - set of entities sharing common characteristics that can be considered equivalent for some purpose Theorem (from set theory) - any equality relation (e.g. common features) divides all entities into non-overlapping equivalence classes any forwarding algorithm need only consider destination (and sometimes source) address service requirements (e.g. priority, BW, allowed delay, etc) we can group together all packets with the same destination and service requirements as a FEC by the theorem every packet belongs to one unique FEC packets in the same FEC should follow the same route so we should map them to the same label (bind them) 1.3 Y(J)S MPLS Slide 24 FECs what constitutes a FEC ? for IP routing (de facto) all packets w/ same destination IP prefix that prefix being the longest in the routing table for MPLS we can decide ! coarsest granularity all packets with a destination address served by a given router finest granularity all packets from given source socket to given destination socket with specified handling requirements 1.3 Y(J)S MPLS Slide 25 Label Switching Architecture downstream direction Label Switched Path L3 link ingress L3 router upstream direction L3 link egress Label Edge Router Label Edge Router Label Switched Routers L3 router label switching is needed in the core, access can be L3 forwarding* core interfaces the access at the edge (ingress, egress) LSR router that can* perform label switching LER LSR with non-MPLS neighbors (LSR at edge of core network) LSP unidirectional path used by label switched forwarding (ingress to egress) * not every packet needs label switching (e.g. only small number of packets, no QoS) 1.3 Y(J)S MPLS Slide 26 Label Switched Forwarding LSP needs to be setup before data is forwarded and torn down once no longer needed LSR performs – label switched forwarding* for labeled packets – label unique to LSR or unique to input interface (like ATM) – optionally L3 forwarding for unlabeled packets ingress LER – assigns packet* to FEC – labels packet – forwards it downstream using label switching egress LER – removes label – forwards packet using L3 forwarding – exception: PHP (discussed later) *once packet is assigned to a FEC and labeled, no LSR looks at the L3 headers/address 1.3 Y(J)S MPLS Slide 27 Hierarchical Forwarding many networks use hierarchical routing – decreases router table size – increases forwarding speed – decreases routing convergence time Country-Code Area-Code Exchange-Code Line-Number telephone numbers Internet DNS ATM 972 2 588 9159 host … SLD TLD myrad . rad . co . il VC VC VC Ethernet/802.3 address space is flat (even though written in byte fields) 1.3 Y(J)S MPLS Slide 28 IP Routing Hierarchy IPv4 – originally flat space (1st come - 1st) until router tables exploded – then 3 classes A 0 net7 B 10 net14 host24 host16 – now CIDR <RFC1519> net22 C 110 ASany host8 host AS=Autonomous System IP exploits hierarchy by employing interior/exterior routing protocols IP can even support arbitrary levels of hierarchy by advertising aggregated addresses AS12 AS13 AS13 AS14 but the exploitation is not optimal 1.3 Y(J)S MPLS Slide 29 IP Routing Hierarchy Bug Net 1 1 transit domain 2 Net 2 traffic from network 1 to network 2 must go through transit domain to get to any host in network 2, all transit domain routers forward to border router 2 transit domain routers shouldn’t need to know anything about network 2 but for IP protocols* change in network 2 forces rerouting in transit domain in worst case, transit domain routers need to know all routes in Internet avoiding maintenance of interdomain information • • • • conserves routing table memory ensures faster convergence transit domain routers restart faster provides better fault isolation * except at BGP-OSPF interface 1.3 Y(J)S MPLS Slide 30 Label Stacks since labels are structure-less, the label space is flat label switching can support arbitrary levels of hierarchy by using a label stack top label another label yet another label bottom label label forwarding based only on top label before forwarding, three possibilities (listed in NHLFE) : – read top label and pop – read top label and swap – read top label, swap, and push new label(s) 1.3 Y(J)S MPLS Slide 31 Example Uses of Label Stack Example applications that exploit the label stack – fast rerouting – VPNs – X over MPLS (PWE3) Note: three labels is usually more than enough 1.3 Y(J)S MPLS Slide 32 Fast Rerouting IP has no inherent recovery method (like SONET) in order to ensure resilience we provide bypass links to reroute quickly we pre-prepare labels for the bypass links when link down change fwd table swap swap 12 11 10 swap + push 13 swap swap 14 pop 11 11 protection LSP 11 from here on no difference! * * label space per LSR not per input port 1.3 Y(J)S MPLS Slide 33 Label Switched VPNs C C C C CE CE C C customer 1 network P P P C CE C customer 2 network customer 2 network PE PE C P P provider network Key C Customer router CE Customer Edge router P Provider router PE Provider Edge router C C CE C customer 1 network 1.3 Y(J)S MPLS Slide 34 Label Switched VPNs (cont.) customers 1 and 2 use overlapping IP addresses C-routers have inconsistent tables egress PE ingress PE-router inserts two labels egress CE IP headers payload P-routers don’t see IP addresses so no ambiguity P-routers see only the label of the egress PE-router – they don’t know about VPNs at all – no need to understand customer configuration – hence smaller tables & no rerouting if customer reconfigures ingress PE router only knows about CE routers – no need to understand customer configuration 1.3 Y(J)S MPLS Slide 35 X over MPLS P router P router native service PE router P router A tunnel may contain many PWs PE router native service P router tunnel label * PW label * PW control word payload * Dictionary: MPLS-f inner label outer label(s) ITU-T interworking label transport label(s) IETF PW label tunnel label(s) 1.3 Y(J)S MPLS Slide 36 Service Interworking Network interworking (PW): Native Service A Customer Edge (CE) Provider Provider provider Edge Edge network (PE) (PE) Customer Edge (CE) Native Service A Service interworking: Native Service A Customer Edge Provider Edge (CE) (PE) Provider provider Edge network (PE) Customer Edge (CE) Native Service B 1.3 Y(J)S MPLS Slide 37 Label (20b) Exp(3b) S(1b) TTL (8b) MPLS Forwarding Component 2.1 The essentials 2.2 The documents Y(J)S MPLS Slide 38 MPLS history many different label switching schemes were invented Cell Switching Router (Toshiba) <RFC 2098,2129> IP Switching (Ipsilon, bought by Nokia) <RFC 2297> Tag Switching (Cisco) <RFC 2105> Aggregate Route-based IP Switching (IBM) IP Navigator (Cascade bought by Ascend bought by Lucent) so the IETF decided to standardize a single method BOFs 1994-1995 WG chartered 1997 – co-chairs from Cisco and IBM (so similar to tag switching and ARIS) – Cisco, IBM, Ascend authored architecture document MPLS standards-track RFCs 20012.1 Y(J)S MPLS Slide 39 MPLS of all the label switching technologies - what is special about MPLS ? multiprotocol - from above and below label in L2 or shim header single forwarding algorithm, including for multicast and TE can run on IP router or ATM switch with only SW upgrade (although can benefit from special HW) label distribution piggybacked on existing routing protocols or via LDP control-driven downstream label binding support for constraint-based routing (for TE) 2.1 Y(J)S MPLS Slide 40 Multiprotocol Label Switching IPv4 IPv6 IPX etc. frame-relay etc. MPLS Ethernet ATM 2.1 Y(J)S MPLS Slide 41 MPLS Labels label may be an appropriate address in either L2 or L3 (even if we lose other features) Examples: – for ATM use VPI and VCI fields as two labels (only two labels, no TTL) – for frame-relay use DLCI (only one label, no CoS, no TTL) otherwise use shim header (described later) ATM header Ethernet header PPP header MPLS shim header MPLS shim header MPLS shim header IP headers IP headers IP headers payload fragment payload payload ATM header multi-access subnet point-to-point & POS payload fragment MPLS over ATM 2.1 Y(J)S MPLS Slide 42 ATM Label Switching GFC VPI/VCI => top label PTI/CLP/HEC GFC VPI/VCI => top label PTI/CLP/HEC MPLS shim payload fragment IP headers rest of cells payload fragment 1st cell AAL5 PDU shim ATM cell IP packet ATM cell AAL5 trailer … ATM cell MPLS WG in this mode the label is carried in the VPI/VCI devoted a lot of time this facilitates using ATM switches to this case however, we still need the shim header for S, and TTL the label field in shim header is a placeholder and set to zero 2.1 Y(J)S MPLS Slide 43 MPLS Shim Header Label (20b) Exp(3b) S(1b) TTL (8b) when a shim header is needed, its format should be: Label there are 220 different labels (+ 220 multicast labels) Special (reserved) labels 0 IPv4 explicit null 1 router alert 2 IPv6 explicit null 3 implicit null Exp (CoS) left undefined by IETF WG was CoS in Cisco Tag Switching could influence packet queuing S=0 Stack bit S=1 indicates bottom of label stack S=0 another label S=0 yet another label S=1 bottom label TTL decrementing hop count used to eliminate infinite routing loops generally copied from/to IP TTL field top label 2.1 Y(J)S MPLS Slide 44 Single Forwarding Algorithm IP uses different forwarding algorithms for unicast, unicast w/ ToS, multicast, etc. LSR uses one forwarding algorithm (LER is more complicated) – read top label L – consult Incoming Label Map (forwarding table) [Cisco terminology LFIB] – perform label stack operation (pop L, swap L - M, swap L - M and push N) – forward based on L’s Next Hop Label Forwarding Entry NHLFE contains: – next hop (output port, IP address of next LSR) if next hop is the LSR itself then operation must be pop for multicast there may be multiple next hops, and packet is replicated – label stack operation to be performed – any other info needed to forward (e.g. L2 format, how label is encoded) ILM contains: – a NHLFE for each incoming label – possibly multiple NHLFEs for a label, but only one used per packet 2.1 Y(J)S MPLS Slide 45 LER Forwarding Algorithm LER’s forwarding algorithm is more complex check if packet is labeled or not if labeled – then forward as LSR – else [Cisco terminology LIB] lookup destination IP address in FEC-To-NHLFE Map if in FTN – then prepend label and forward using LSR algorithm – else forward using IP forwarding IP router pure IP link LER MPLS link LSR 2.1 Y(J)S MPLS Slide 46 Penultimate Hop Popping PH I E IP link CE MPLS domain the egress LER E also may have to work overtime: – – – – – read top label lookup label in ILM find that in NHLFE that the label must be popped lookup IP address in IP routing forward to CE using IP forwarding we can save a lookup (and the first 3 steps) by performing PHP but pay in loss of OAM capabilities penultimate LSR PH performs the following: – – – – read top label lookup label in ILM pop label revealing IP address of CE router forward to CE using IP forwarding 2.1 Y(J)S MPLS Slide 47 Route Aggregation net 1 1 IP link 12 13 31 IP link net 2 2 22 32 E IP link 3 net 3 23 MPLS domain traffic from both network 1 and network 2 is destined for network 3 scalability advantages – fewer labels – conserve table memory disadvantages – IP forwarding may be required – OAM backwards trail is destroyed 2.1 Y(J)S MPLS Slide 48 IP Router / ATM Switch migration - important to be able to exploit existing forwarding hardware we can use IP routers as LSRs = + – already use the routing protocols for topology determination – need to add label distribution protocol (or extend routing protocol) – need to alter the forwarding algorithm – can manage with software upgrade but probably best to upgrade hardware too = + we can use ATM switches as LSRs – need to alter the routing protocols for topology determination – need to add label distribution protocol – already uses the forwarding algorithm – probably can just upgrade software 2.1 Y(J)S MPLS Slide 49 ATM Cell Interleave ATM switches – have separate label space per input port – segment traffic into ATM cells what if the forwarding tables for both port 1and port 2 have the entry incoming label 13 outgoing label 17 outgoing port 1 ? 13 data A1 13 data A2 A 17 data A1 2 13 data B2 B B 17 data B1 1 13 data B1 ATM LSR 1 2 17 data A2 ATM LSR 17 data B2 2.1 Y(J)S MPLS Slide 50 VC/VP Merge in order to properly reconstruct the packet we can use VC-merge buffer cells at the ATM LSR until end-of-packet detected cells belonging to different packets aren’t interleaved – introduces delay – requires large memory – requires ATM LSR to detect AAL5 end-of-packet VP merge use VPI as MPLS label use VCI as multiplexing index – limits number of available labels 2.1 Y(J)S MPLS Slide 51 Label Distribution Protocols when LSR creates/removes a FEC - label binding needs to inform other LSRs (“remote binding information”) MPLS allows piggybacking label distribution on routing protocols – – – – – – protocols already in use (don’t need to invent or deploy) eliminates race conditions (when route or binding, but not both, defined) ensures consistency between binding and routing information only for distance vector or path vector routing protocols (not OSPF, IS-IS) not all routing protocols are sufficiently extensible (RIP isn’t) has been implemented for BGP-4 MPLS WG invented a new protocol LDP for “plain” label distribution – messages sent reliably using TCP/IP – messages encoded in TLVs – discovery mechanism to find other LSRs … and extended RSVP to LSPs for QoS 2.1 Y(J)S MPLS Slide 52 Control Mechanisms pre-MPLS protocols used various control mechanisms Example: label distribution – Cisco and IBM - control driven – Toshiba and Ipsilon - data (traffic) driven MPLS is distinguished by its choice of control protocols – – – – control driven downstream binding unsolicited and on-demand allowed independent and ordered allowed we will discuss these in the section on the control plane 2.1 Y(J)S MPLS Slide 53 MPLS RFCs 2547 2702 2917 3031 3032 3035 3036 3037 3038 3063 3107 3209 3210 3212 3213 3214 3215 (page 1 of 2) BGP/MPLS VPNs Requirements for Traffic Engineering Over MPLS A Core MPLS IP VPN Architecture Multiprotocol Label Switching Architecture MPLS Label Stack Encoding MPLS Using LDP and ATM VC Switching LDP Specification LDP Applicability VCID Notification over ATM link for LDP MPLS Loop Prevention Mechanism Carrying Label Information in BGP-4 RSVP-TE: Extensions to RSVP for LSP Tunnels AS for Extensions to RSVP for LSP-Tunnels Constraint-Based LSP Setup using LDP Applicability Statement for CR-LDP LSP Modification Using CR-LDP LDP State Machine 2.2 Y(J)S MPLS Slide 54 More MPLS RFCs 3270 3346 3353 3429 3443 3468 3469 3477 3496 3564 3478 3479 3480 MPLS Support of Differentiated Services AS for Traffic Engineering with MPLS Overview of IP Multicast in MPLS Environment Assignment of the 'OAM Alert Label' for MPLS OAM functions TTL Processing in MPLS Networks The MPLS WG decision on MPLS signaling protocols Framework for MPLS-based Recovery Signalling Unnumbered Links in RSVP-TE Support of ATM Service Class-aware MPLS Traffic Engineering Support of DiffServ-aware MPLS Traffic Engineering Graceful Restart Mechanism for LDP Fault Tolerance for the LDP Signalling Unnumbered Links in CR-LDP 2.2 Y(J)S MPLS Slide 55 Yet More MPLS RFCs 3612 3630 3809 3811 3812 3813 3814 3815 3916 3988 3985 4023 4026 4031 Applicability Statement for Restart Mechanisms for LDP OSPF-TE Generic Requirements for PPVPNs Definitions of Textual Conventions for MPLS Management MPLS Traffic Engineering Management Information Base MPLS Label Switching Router (LSR) MIB MPLS FEC-To-NHLFE MIB Definitions of Managed Objects for LDP Requirements for Pseudo-Wire Emulation Edge-to-Edge Maximum Transmission Unit Signalling Extensions for LDP PWE3 Architecture Encapsulating MPLS in IP or GRE PPVPN Terminology Service requirements for Layer 3 PPVPNs 2.2 Y(J)S MPLS Slide 56 Even More MPLS RFCs 4023 4090 4105 4124 4125 4126 4127 4128 4182 4201 4206 4216 4220 4221 4247 4364 4368 4377 4378 4379 Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) Fast Reroute Extensions to RSVP-TE for LSP Tunnels Requirements for Inter-Area MPLS Traffic Engineering Protocol Extensions for Support of Diffserv-aware MPLS TE Maximum Allocation BW Constraints Model for Diffserv-aware MPLS TE Max Allocation w/ Reservation BW Constraints Model for Diffserv MPLS TE Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS TE Bandwidth Constraints Models for Diffserv-aware MPLS TE Removing a Restriction on the use of MPLS Explicit NULL Link Bundling in MPLS Traffic Engineering (TE) Label Switched Paths (LSP) Hierarchy with GMPLS Traffic Engineering MPLS Inter-AS TE Requirements Traffic Engineering Link Management Information Base Multiprotocol Label Switching (MPLS) Management Overview Requirements for Header Compression over MPLS BGP/MPLS IP VPNs (was 2547bis) MPLS Label-Controlled ATM and FR Management Interface Definition OAM Requirements for MPLS Networks A Framework for MPLS OAM 2.2 Detecting MPLS Data Plane Failures Y(J)S MPLS Slide 57 MFA forum IAs 1.0 Voice over MPLS IA 2.0 MPLS-PVC UNI IA 3.0 LDP Conformance IA 4.0 TDM Transport over MPLS using AAL1 IA 5.0 I.366.2 Voice Trunking over MPLS IA 6.0.0 MPLS Proxy Admission Control 7.0.0 MPLS UNI protocol 8.0.0 TDM over MPLS using Raw Encapsulation 2.2 Y(J)S MPLS Slide 58 ITU-T Recommendations Y.1411 ATM-MPLS network interworking - Cell mode user plane interworking Y.1412 ATM-MPLS network interworking - Frame mode user plane interworking Y.1413 TDM-MPLS network interworking – User plane interworking Y.1414 Voice services - MPLS network interworking Y.1415 Ethernet-MPLS network interworking – User plane interworking Y.1710 Requirements for OAM functionality for MPLS networks Y.1711 Operation & Maintenance mechanism for MPLS networks Y.1712 User-plane fault-management for ATM and MPLS OAM Y.1713 Misbranching detection for MPLS networks Y.1720 Protection switching for MPLS networks X.84 FR over MPLS core networks G.8110/Y.1370 MPLS Layer Network architecture 2.2 Y(J)S MPLS Slide 59 control plane user (data) plane MPLS Control Component 3.1 Procedures and scenarios 3.2 Label distribution protocols 3.3 LDP and BGP-4 details Y(J)S MPLS Slide 60 Control and User Planes topology determination use standard IP routing protocols BGP, OSPF, IS-IS, PIM label distribution control plane piggyback on routing protocol use LDP, RSVP-TE forwarding paradigm label-stack CO forwarding user (data) plane 3.1 Y(J)S MPLS Slide 61 What is Needed ? control plane all IP routing protocols (BGP,OSPF,PIM,etc) procedure to bind label to FEC (label assignment) protocol to distribute label binding information procedure to create forwarding table user (data) plane procedure to label incoming packet forwarding procedure – forwarding table lookup – label stack operations 3.1 Y(J)S MPLS Slide 62 All the Tables FEC table FEC protocol input port handling 192.115/16 IPv4 2 best-effort Free Labels 128-200 presently free FTN ILM NHLFE FEC port/label in port/label out 192.115/16 2/17 3/137 port/label in port/label out next hop operation 2/17 3/137 5.4.3.2 swap 3.1 Y(J)S MPLS Slide 63 LER Architecture control plane IP routing protocols IP routing table IP routers label binding and distribution protocols free label table LSRs user (data) plane FTN IP forwarding table labeling procedure egress LER MPLS forwarding table 3.1 Y(J)S MPLS Slide 64 Binding & Distribution Options label binding (assignment) – per port or per LSR label space – control driven vs. data driven (traffic driven) – liberal vs. conservative label retention label distribution (advertisement) – downstream vs. upstream – downstream on-demand (dod) vs. downstream unsolicited (du) – independent vs. ordered 3.1 Y(J)S MPLS Slide 65 Per Port Label Space LSR may have a separate label space for each input port (I/F) or a single common label space or any combination of the two separate labels spaces means separate forwarding tables per port ATM LSR have per port label spaces (leads to interleave problem) per port label spaces increases number of available labels common label space facilitates several MPLS mechanisms (e.g. reroute) 3.1 Y(J)S MPLS Slide 66 Control vs. Data Driven there are two philosophies as to when to create a binding data-driven (traffic-driven) binding (Toshiba CSR, Ipsilon IP-Switching) automatically create binding when data packets arrive (from first packet?, after enough packets? when tear LSP down?) control-driven binding (Cisco Tag Switching, IBM ARIS) create binding when routing updates arrive (only update when topology changes? update upon request?) although not specifically stated in the architecture document MPLS assumes control driven binding * * two implementations of control driven: – topology-driven (routing tables are consulted) – control-traffic driven (only routing update messages are used) 3.1 Y(J)S MPLS Slide 67 Liberal vs. Conservative Retention LSR receives “advertisements” (label distribution messages) from other LSRs conservative label retention: LSR retains only label-to-FEC bindings that are presently needed liberal label retention LSR stores all bindings received (more labels need to be maintained) using liberal retention can speed response to topology changes LSRs must agree upon mode to be used A advertises label B is previous hop LSR but C retains label anyway later routing change makes C the previous hop C immediately can start forwarding B A C 3.1 Y(J)S MPLS Slide 68 Downstream vs. Upstream downstream binding means to allocate a label to a FEC local binding - LSR allocates the label from “free label” pool remote binding - LSR that receives the label which LSR allocates ? MPLS uses downstream binding label allocated by LSR downstream from the LSR that prepends it label distribution information flows upstream reverse in direction from data packets to set up LSP through link from LSR A to LSR B LSR B binds label 13 to FEC B advertises label to LSR A LSR A sends packets with label 13 to B label 13 A 13 B 3.1 Y(J)S MPLS Slide 69 On-demand vs. Unsolicited downstream on-demand label distribution: LSRs may explicitly request a label from its downstream LSR unsolicited label distribution: LSR distributes binding to upstream LSR w/o a request (e.g. based on time interval, or upon receipt of topology change) LSR may support on-demand, unsolicited, or both adjacent LSRs must agree upon which mode to be used LSR A needs to send a packet to LSR B LSR A requests a label from LSR B B binds label 13 to the FEC B distributes the label A starts sending data with label 13 I need a label I allocated 13 A 13 data B 3.1 Y(J)S MPLS Slide 70 Independent vs. Ordered independent binding (Tag Switching) – each LSR makes independent decision to bind and distribute ordered binding (ARIS) egress LSR binds first and distributes binding to neighbors LSR that believes that it should be the penultimate LSR binds and distributes to its neighbors binding proceeds in orderly fashion until ingress LSR is reached LSRs must agree upon mode to be used B sees that it is egress LSR for 192.115.6 B allocates label 13 B distributes label to C and D C distributes label to E 13 D 192.115/16 B E C 13 A 3.1 Y(J)S MPLS Slide 71 LDP tasks a label distribution protocol is a signaling protocol that can perform the following tasks: discover LSR peers initiate and maintain LDP session signal label request advertise binding signal label withdrawal loop prevention explicit routing resource reservation 3.2 Y(J)S MPLS Slide 72 Label Distribution Protocols label distribution can be carried over various protocols There are presently four options: LDP – MPLS-enhanced IP networks BGP4-MPLS – RFC 2547 VPNs RSVP-TE – traffic engineering support CR-LDP – constraint based (no longer recommended by IETF) 3.2 Y(J)S MPLS Slide 73 LDP vs. BGP both use TCP for reliable transport (LDP uses UDP for hellos) both are hard-state protocols both use TLV format for parameters BGP LDP multiprotocol (IPv4, IPv6, IPX, MPLS) MPLS only highly complex protocol simpler protocol provides routing / label distribution only label distribution built-in autodiscovery mechanism extendable for autodiscovery 3.2 Y(J)S MPLS Slide 74 LDP major focus of the IETF MPLS WG was the design of LDP based on similar TDP from Cisco LDP sets up a bidirectional LDP session both sides can request or advertise labels LDP usually uses TCP – – – – – needs reliable transport (e.g. what happens if miss a binding) needs in-order delivery (e.g. binding+withdrawal) hard to develop new reliable transport protocols single acknowledgement timer for session piggybacking ACK on data packets Use UDP for discovery (hello) messages periodic keepalive messages (if not received, session terminated) messages encoded in TLV (Type Length Value) form 3.2 Y(J)S MPLS Slide 75 LDP Setup Hello (UDP) Discovery Hello (UDP) Initialization (TCP) Session Initialization (TCP) Label Request (TCP) Distribution Label Distribution (TCP) 3.2 Y(J)S MPLS Slide 76 Discovery Phase LSR periodically multicast transmits hello to “LDP discovery” UDP port – to “all routers on subnet” multicast group – to preconfigured IP address (when not all LSRs on same subnet) (extended discovery) “targeted LDP” LSRs listen on this UDP port for hello messages Hello message contains: – hold time – LSR Identifier when LSR receives Hello from another LSR – it opens a TCP connection to that other LSR (if needed) or (for extended discovery) – it unicast transmits a hello back to the other LSR LDP session can now be established 3.2 Y(J)S MPLS Slide 77 Session Initialization The LSR with higher identifier sends (TCP) a session initialization message to the other LSR session initialization message contains: – – – – LDP Protocol version label distribution and control method timer values label space ranges (not any more !) if receiving LSR accepts these parameters then it transmits a KeepAlive else it transmits a reject 3.2 Y(J)S MPLS Slide 78 Distribution Messages label mapping – downstream LSR advertisement of a label mapping for a FEC two FEC types: host address, IP address prefix label withdrawal – reverse of mapping message – downstream LSR informs upstream LSR that it has revoked a previous binding – upstream LSR can not longer use the label label release – upstream LSR informs downstream LSR that it no longer needs a binding – typically when downstream is no longer next hop and operating in conservative retention mode 3.2 Y(J)S MPLS Slide 79 Request Messages in downstream-on-demand mode upstream LSR must request binding upstream LSR sends label request message when: – FEC in FEC table next hop LSR is LDP peer FEC not in forwarding table – FEC next hop changes upstream LSR doesn’t have a mapping from new next hop – receives FEC label request from upstream LDP peer next hop LSR is LDP peer upstream LSR doesn’t have a mapping from next hop upstream LSR sends label request abort message when: – upstream LSR needs to revoke request before satisfied for example, next hop LSR for FEC has changed 3.2 Y(J)S MPLS Slide 80 Notifications There are two types of notifications: – error notifications (fatal errors - terminate session) – advisory notifications (status messages) LSR sends notification messages when: – received LDP message with unsupported protocol version – received LDP message with unknown type – KeepAlive timer expired – session initialization fails due to unacceptable parameters – etc. 3.2 Y(J)S MPLS Slide 81 LDP state machine LSR periodically transmits hello UDP messages – multicast to “all routers on subnet” group – targeted to preconfigured IP address LSRs listen on this UDP port for hello messages when LSR receives hello from another LSR – it opens a TCP connection to that other LSR or (for extended discovery) – it unicast transmits a hello back to the other LSR LSR with higher ID sends session initialization message other LSR LDP accepts (sends keepalive) or rejects informative or keepalive messages sent 3.2 Y(J)S MPLS Slide 82 LDP packet format header (10B) version (2B) length (2B) LDP-ID (6B) message TLVs (variable) version – presently 1 length - PDU length, excluding version and length fields LDP-ID – identifies label space of sending LDP peer – LSR-ID(4B) globally unique LSR ID – label space ID (2B) for per-port label spaces (zero for per-platform label spaces) message TLVs – zero or more message TLVs (see next page) 3.3 Y(J)S MPLS Slide 83 LDP message TLVs type U (15b) length (2B) message-ID (4B) mandatory parameter TLVs (variable) optional parameter TLVs (variable) U – unknown message bit if message type unknown to receiver U=0 – receiver returns notification to sender U=1 – receiver silently ignores length - message length, excluding type and length fields message-ID – unique ID for message (for matching with returned notification) if there are mandatory parameters, they most appear in a specific order optional parameters may appear in any order 3.3 Y(J)S MPLS Slide 84 All LDP message types Hello (0x0100) Initialization (0x0200) KeepAlive (0x0201) Notification (0x0001) Address (0x0300) Address Withdraw (0x0301) Label Mapping (0x0400) Label Withdraw (0x0402) Label Request (0x0401) Label Release (0x0403) Label Abort Request (0x0404) 3.3 Y(J)S MPLS Slide 85 LDP parameter TLVs U F type (14b) length (2B) value U – unknown message bit if message type unknown to receiver: U=0 – receiver returns notification to sender U=1 – receiver silently ignores F – forward unknown message bit if U=1 and message type unknown to receiver F=0 – do not forward F=1 – forward type - TLV type (FEC TLV, label TLV, address list TLV, hop count TLV, path vector TLV, status TLV ) length - length of value field in bytes 3.3 Y(J)S MPLS Slide 86 FEC TLV type (2B) U=0 F=0 type=0x0100 length (2B) FEC element 1 … there may be more than one FEC element for mapping messages only the FEC elements are not themselves TLVs (no length needed), instead – wildcard FEC (0x01) – prefix FEC (0x02) + address family (IPv4, IPv6, Ethernet, E.164, etc.) + prefix length in bits + prefix – host address FEC (0x03) + address family + length + address 3.3 Y(J)S MPLS Slide 87 Generic Label TLV type (2B) U=0 F=0 type=0x0200 length (2B) label (20 bits) this is the generic label TLV there are also special label TLVs for ATM and FR based MPLS 3.3 Y(J)S MPLS Slide 88 Status TLV type (2B) U F type=0x0300 E F length (2B) status code data (30b) message ID (32b) message type (16b) Status TLVs : mandatory parameters in notification messages optional parameters in other messages U=0 when status in notification message, else U=1 E - fatal error bit E=1 for fatal error E=0 for advisory notification the two F bits are equal and have the normal meaning status code data = 0 means success message ID - the message to which the status refers message type - the message type to which the status refers 3.3 Y(J)S MPLS Slide 89 Example full message label mapping mapping message length=24 U=0 type = 0x0400 (2B) FEC TLV (2B) U=0 F=0 type=0x0100 message-ID (4B) length=8 (2B) prefix FEC element (8B) type = 0x02 family=1(IPv4) prefix-length=16 prefix=192.115/16 label TLV (2B) U=0 F=0 type=0x0200 length=4 (2B) label = 17 3.3 Y(J)S MPLS Slide 90 BGP4 Label Distribution BGP peers exchange VPN routes can easily associate a label with these routes all BGP procedures are immediately available for use for label distribution messages BGP4 is a very extensible protocol – multiprotocol extensions support address families (originally for IPv4,IPv6, etc) – MPLS defines a new address family 3.3 Y(J)S MPLS Slide 91 BGP header (19B) marker (16B) length (2B) marker can be used for authentication type (1B) data (variable) (TCP MD5 signature) length is total BGP PDU length, including header type – – – – OPEN (for session initialization) UPDATE (add, change and withdraw routes) NOTIFICATION (return error messages, terminate session) KEEPALIVE (heartbeat) KEEPALIVE packet consists of 19B header only 3.3 Y(J)S MPLS Slide 92 BGP state machine idle – no session (awaiting session initialization) connect – attempting to connect to peer active – started TCP 3-way handshake (router busy) open sent – have sent OPEN message open confirm – after receiving TCP SYN for OPEN message established – BGP session up and running 3.3 Y(J)S MPLS Slide 93 BGP OPEN version (1B) my AS (2B) hold time (2B) BGP-ID (2B) op len (1B) opt parameters (variable) version (3 or 4) my AS – identifier of autonomous system hold time – max time (sec) between receipt of messages BGP ID – sender’s BGP identifier op len – length (bytes) of optional parameters opt parameters - TLVs 3.3 Y(J)S MPLS Slide 94 BGP UPDATE WR len withdrawn routes (2B) (var) PA len (2B) path attributes (var) Withdrawn Routes – list of routes no longer to be used NLRI (var) (NLRI format- see below) Path Attributes – route specific information (see next page) Network Layer Reachability Information – (classless) routing information len (1B) prefix (variable) the NLRI is a list of address-prefixes each prefix must be masked from the left to the length specified 3.3 Y(J)S MPLS Slide 95 BGP UPDATE - Path Attributes flags (1B) type code (1B) flags O – optional/well-known bit if 1 must be recognized by all BGP implementations if W=1 and unrecognized attribute, BGP sends notification and session closed T – transitive/nontransitive bit if 1 and attribute unrecognized it is passed along, else silently ignored well-known attributes are always transitive C – complete/partial bit L – attribute length bit (for optional transitive attributes only) (=0 attribute length is 1B, =1 length is 2B) type code ORIGIN, AS_PATH, NEXT_HOP, MED, LOCAL_PREF, 3.3 AGGREGATOR, COMMUNITY, ORIGINATOR_ID… Y(J)S MPLS Slide 96 BGP NOTIFICATON error code (1B) error subcode (2B) data (var) all notification messages cause BGP session to close error codes include: – – – – – – message header error open message error update message error hold timer expired state machine error other fatal error 3.3 Y(J)S MPLS Slide 97 D A G C B E F MPLS Traffic Engineering 4.1 Introduction to Traffic Engineering 4.2 DiffServ and IntServ 4.3 TE protocols Y(J)S MPLS Slide 98 Traffic Engineering TE is control of network traffic to achieve specific objectives unfortunately users and providers have contradictory objectives user objectives (QoS) – – – – – – network availability packet loss end-to-end delay round-trip delay packet delay variation (PDV) error rate provider objectives (performance) – – – – – bandwidth utilization resource utilization speed of failure recovery ease of management monetary outlay Y(J)S MPLS 4.1 Slide c99 Network and Traffic Engineering Network Engineering putting the bandwidth where the traffic is – physical cable deployment (thick pipes) – over-provisioning – virtual connection provisioning – violates providers objectives Traffic Engineering putting the traffic where the bandwidth is – explicit traffic routing – route optimization – can it meet user objectives? 4.1 Y(J)S MPLS Slide 100 IP’s Problem A D 1 G C B 0.5 E traffic from A to G 1Gb traffic from B to G 500Mb all links 1Gb except EF 500 Mb F were C,D,E, and F ATM switches there would be no problem (1Gb over ACDG, 500Mb over BCEFG) with standard hop-count cost function, all traffic over CDG resulting in 1.5Gb there (congestion) and CEFG idle with administrative cost on CDG we can force all the traffic to CEFG even worse congestion ! finally with administrative cost and ECMP we can load balance 750 Mb over CDG and CEFG, link EF is still congested ! what can we do? 4.1 Y(J)S MPLS Slide 101 Solution IP’s problem arises from – the forwarding being purely local – but the routing being too global IP routing always optimizes a global (usually additive) metric discrete optimization problem does not take local constraints (e.g. BW of individual links) into account we need to optimize a global metric while taking local constraints into account this is called constraint-based routing discrete optimization with inequality constraints main constraint is BW, but also maximum delay, packet loss, etc. another constraint: explicit include/exclude links/routers 4.1 Y(J)S MPLS Slide 102 MPLS TE MPLS that we have seen so far allows explicit routing – can minimize number of hops – can tailor LSP to needs MPLS-TE LSPs can be setup according to constraints – only include in LSP LSR with sufficient available BW – only include in LSP LSR that guarantees sufficiently low delay traffic engineering achieved by extending base protocols enhanced routing protocols (resource reservation) – OSPF OSPF-TE – ISIS ISIS-TE constraint-based signalling protocols (pinned LSPs and reservation) – RSVP RSVP-TE – LDP CR-LDP (no longer under active development) 4.1 Y(J)S MPLS Slide 103 IP Fixes two approaches to QoS were developed for IP (never popular) IntServ (guaranteed QoS) – – – – define traffic flows (CO approach) guarantee QoS attributes for each flow reserve resources at each router along the flow signaling protocol (RSVP) needed DiffServ (statistical QoS) – – – – – retain CL paradigm no guaranteed QoS attributes classify packets (differentiated) offer special treatment (priority) relative to other packets no resource reservation 4.2 Y(J)S MPLS Slide 104 DiffServ DIffServ was developed in IETF after IntServ RFCs 2474, 2475 IntServ too heavy-weight (and too revolutionary) for most purposes resource reservation is against IP-philosophy if not enough BW, then more democratic for all to suffer if reserve BW and don’t use, then this is simply over-provisioning DiffServ is evolutionary “coarse-grained” approach to IP QoS DiffServ – divides traffic into service classes and allocates resources on a per-class basis – uses 6 bits of ToS byte in IP header to mark packets field is renamed Differentiated Services Code Point no setup or router state required – DSCP defines per-hop behaviors (PHB) tells router how to treat packet – three standard PHBs (BE, AF, EF) 4.2 Y(J)S MPLS Slide 105 DiffServ PHBs Best Effort – standard IP service – QoS depends on momentary network load Assured Forwarding – AF specifies class that determines queue – in addition, three drop-precedence levels (low, med, high) – AF packets from a single source should not be mis-ordered even if have different drop-precedence (i.e. single queue) Expedite Forwarding – EF packet should experience no queuing delays – EF packets should have low loss – implemented by dedicated EF router queue 4.2 Y(J)S MPLS Slide 106 MPLS and DiffServ what does all this have to do with MPLS ? MPLS will have to co-exist with DiffServ IP MPLS provides similar functionality Exp bits in MPLS shim header are similar to DSCPs – only three bits (8 classes) while DiffServ ended up with 6 bits – but 8 service classes is usually more than enough commonly 4 classes are offered (bronze, silver, gold, platinum) LSR can maintain mapping from Exp to PHB e.g. Exp=000 for BE, Exp=001 for AF low drop precedence, etc no new signaling mechanism required LSP with Exp mapping to PHB is called an E-LSP ingress LER assigns the EXP field 4.2 Y(J)S MPLS Slide 107 L-LSP vs. E-LSP with DiffServ each FEC is defined by – destination address – service class there are two ways of implementing the DiffServ mapping L-LSP (Labeled-inferred LSP) – – – – behavior based on label alone support different service classes by using different labels LSP BW allocated from specific queue (class) Exp may be used for drop precedence E-LSP (Exp-inferred LSP) BW % L-LSP L-LSP L-LSP – behavior based on label + Exp field – LSP BW allocated from link – can support 8 different service classes per label 4.2 Y(J)S MPLS Slide 108 IntServ RFCs 2205-2216, 2379-2382 IntServ is an overall QoS architecture (not just RSVP) IntServ is a radical departure from pure IP and requires IntServ-enabled routers IntServ – enables providing end-to-end QoS guarantees for services that need them – defines flows (introduces CO to IP’s CL architecture) flows are classified into three service classes (BE,CLS,GS) – specifies admission control and policing – like all CO architectures, requires signaling protocol (RSVP) IntServ-enabled routers – reserve needed resources along the flow’s path – routers must retain state 4.2 Y(J)S MPLS Slide 109 IntServ CoS Best Effort – – standard IP service QoS depends on momentary network load Controlled Load Service – – – – service equivalent to unloaded network low packet loss most packets will experience delay close to minimum no quantitative guarantees Guaranteed Service – – – bounded worst case delay (no PDV guarantee) low packet loss (zero if node buffers correctly provisioned) quantitative guarantees 4.2 Y(J)S MPLS Slide 110 RSVP RSVP primary signaling protocol for IntServ runs over raw IP or UDP/IP does not setup path, uses path setup by routing protocols sessions identified by source and destination socket numbers requests unidirectional QoS characteristics from network causes routers along path to reserve link and node resources network responds with success/failure routers maintain soft-state, reservations time-out unless refreshed two main message types: PATH and RESV 4.2 Y(J)S MPLS Slide 111 RSVP Messages receivers sender PATH – message from sender to receiver(s) – carries classification info and TSpecs RESV – response of receiver to PATH message – carries session ID and RSpec specifying QoS required – this is the actual request for resource reservation 4.2 Y(J)S MPLS Slide 112 MPLS and IntServ what does all this have to do with MPLS ? MPLS extension of RSVP : RSVP-TE (RFC 3209) can be used as a label distribution protocol for downstream-on-demand binding create and distribute bindings between RSVP flows and labels Note: requests by LSRs and hosts (RSVP only by hosts) uses label instead of source and destination socket numbers extends RSVP by adding new objects (e.g. label) and procedures allows strict/loose explicitly routed LSPs like LDP there is peer discovery, label requests, binding messages QoS and traffic parameters are carried transparently 4.2 Y(J)S MPLS Slide 113 CR-LDP RSVP-TE is not the only way of setting up a LSP for TE Constraint-based Routing LDP (CR-LDP) extends LDP basic LDP lacks – explicit routing – resource reservation so CR-LDP adds – explicit route object, carried as TLV in label request – traffic parameter object peak/committed data rate peak/committed burst sizes etc. and since we are already extending the basic protocol … – path pre-emption priority – path re-optimization (with pinning option) – LSP setup failure notification – automatic LSP failure recovery policies – etc. 4.3 Y(J)S MPLS Slide 114 Setup Procedures Example setup ingress with explicit routes CR-LDP: egress A B C A reserves resources, sends label request w/ explicit route BC & resource req.s B reserves resources and sends label request w/ explicit route C & resource req.s C reserves resources, locally binds label and sends label mapping to B B matches mapping to previous request, remotely binds, sends label mapping to A A remotely binds label RSVP-TE: A sends PATH message to B w/ explicit route BC and resource requirements B forwards PATH message to C after changing explicit route to C C determines required resources, reserves, locally binds label and sends RESV to B B matches, reserves resources, remotely binds, and sends RESV to A A matches, remotely binds label and reserves resources 4.3 Y(J)S MPLS Slide 115 RSVP-TE/CR-LDP Comparison 1/2 CR-LDP extends an MPLS label distribution protocol adding explicit route and resource reservation features RSVP-TE extends a pure IP resource reservation protocol to MPLS requires running two protocols both distribute binding information both support explicit routing, pinning, and resource reservation CR-LDP uses TCP (reliable) message order is guaranteed lost packet delays all processing RSVP-TE uses IP (in core) or UDP/IP (unreliable) needs refreshes for reliability RSVP-TE supported by Cisco and Juniper, and selected by IETF CR-LDP supported by Nortel and Nokia, was favorite of ITU-T 4.3 Y(J)S MPLS Slide 116 RSVP-TE/CR-LDP Comparison 2/2 CR-LDP is hard-state RSVP-TE is soft-state – automatically tracks changes – needs refresh overhead (can be reduced by bundling) both use ordered binding from egress to ingress after first traversing from ingress to egress but CR-LDP reserves resources in forward direction RSVP-TE reserves in backward direction RSVP-TE uses standard IntServ QoS model (TSpec/RSpec) CR-LDP uses its own QoS model (traffic parameters) CR-LDP may be vulnerable to TCP DoS attacks RSVP-TE specifies authentication control 4.3 Y(J)S MPLS Slide 117 OSPF-TE and IS-IS-TE constraint-based routing needs link attribute information most important - available BW link-state protocols have mechanisms to flood link-up/link-down to every router in the domain piggyback attribute as TLV on link-up/link-down messages – OSPF add to Link-State Advertisement (LSA) (RFC 3630) – IS-IS add to Link-State Packets once router receives attribute information it can reserve resource when attribute information changes need to reflood but every allocation changes attributes! to decrease overhead: only flood when change passes threshold inherent timing bounds 4.3 Y(J)S MPLS Slide 118 MPLS Applications 5.1 L3 VPNs 5.2 L2 VPNs 5.3 PWE3 Y(J)S MPLS Slide 119 2547bis (RFC 4364) VPNs CE not peer to CE CE peer to PE C C C CE C PE P P PE C CE C CE is IP router SP label ext label IP Packet Virtual router (peering) model, not tunneling PE maintains Virtual Route Forwarding table for each VPN BGP (with multiprotocol extensions) used for label distribution in order to support private IP addresses in BGP PE prepends 8B Route Distinguisher (unique to site) to IP address 5.1 Y(J)S MPLS Slide 120 BGP MPLS VPNs (2547bis) presently most popular provider managed VPN originally specified in RFC 2547, update in draft called RFC 4364 transports IPv4 (IPv6) traffic in MPLS tunnels uses BGP for route distribution since SPs commonly use BGP for routing 2547 is not an overlay model – CE routers at different sites are not routing peers – they do not directly exchange routing information – they don’t even need to know of each other – so customer needn’t manage a backbone or virtual backbone – no inter-site routing problems 5.1 Y(J)S MPLS Slide 121 BGP MPLS VPNs (cont.) only PE routers maintain VPN information P routers needn’t maintain any customer routing information C routes either manually configured in PE or advertised to PE using BGP, OSPF, etc. PE advertises routes to remote PEs using BGP remote PEs advertise routes to their CEs using BGP, OSPF, etc. IP address overlap solved using Route Distinguisher (RD) 5.1 Y(J)S MPLS Slide 122 L2VPN - VPWS CE AC PE PE AC CE provider network Virtual Private Wire Service is a L2 point-to-point service it emulates a wire supporting the Ethernet physical layer set up MPLS tunnel between PEs set up Ethernet PW inside tunnel CEs appear to be connected by a single L2 circuit (can also make VPWS for ATM, FR, etc.) 5.2 Y(J)S MPLS Slide 123 L2VPN - VPLS AC PE CE AC CE PE for clarity only one VPN is shown PE AC CE VPLS emulates a LAN over an MPLS network set up MPLS tunnel between every pair of PEs (full mesh) set up Ethernet PW inside tunnels, for each VPN instance CEs appear to be connected by a single LAN PE must know where to send Ethernet frames … but this is what an Ethernet bridge does 5.2 Y(J)S MPLS Slide 124 VPLS V B CE CE B V V B CE a VPLS-enabled PE has, in addition to its MPLS functions: VPLS code module (IETF drafts) Bridging module (standard IEEE 802.1D learning bridge, but no STP) SP network (inside rectangle) looks like a single Ethernet bridge! Note: if CE is a router, then PE only sees 1 MAC per customer location 5.2 Y(J)S MPLS Slide 125 Pseudowire Emulation This is a special case of “Pseudowire Emulation Edge to Edge”, or PWE3 Packet Switched Network Customer Edge (CE) Customer Edge (CE) Customer Edge (CE) Customer Edge (PSN) Provider Edge Provider Edge (CE) (PE) (PE) Customer Edge native service PseudoWires (PWs) [tunnels] native service (CE) 5.3 Y(J)S MPLS Slide 126 IETF PWE3 WG In the Internet Area of the Internet Engineering Task Force Native (layer 1,2) services : ATM (port mode, cell mode, AAL5-specific modes) FR Ethernet (DIX, 802.3, VLAN) TDM (SONET/SDH, E1, T1, E3, T3) PSNs IPv4 IPv6 MPLS L2TPv3 5.3 Y(J)S MPLS Slide 127 PWE3 WG Charter Edge-to-edge emulation and maintenance of PWs – tunnel creation and placement out of scope Network interworking, not service interworking Must not exert controls on underlying PSN – but diffserv, RSVP-TE can be used Use RTP when necessary – for real-time functions, clock recovery Realize that emulation will not be perfect – need applicability statement for each native service WG will produce the following documents – framework, requirements, architecture documents – service specific encapsulation documents for each native service 5.3 Y(J)S MPLS Slide 128 Why MPLS for PWE3 ? Much of the PWE work is focused on MPLS Emulated services have QoS and TE requirements – – – – IP is basically a “best effort” service diffserv and RSVP extensions not prevalent MPLS can provide TE guarantees RSVP-TE (CR-LDP) allows TE signaling IP provides no standard connection multiplexing method – – – – – Dictionary: UDP/TCP ports provide application multiplexing RTP uses ports in a nonstandard way L2TP includes a multiplexing mechanism MPLS label stack provides natural multiplexing method Using “inner labels” provides two layers of switching (like ATM VP/VC) ATM-f ITU-T IETF inner label outer label(s) interworking label transport label(s) PW label tunnel label(s) 5.3 Y(J)S MPLS Slide 129 PWE packet format outer label inner label control word Payload • inner and outer labels specify forwarding and multiplexing • outer label is standard MPLS stack • inner label contains PW label • control word • enables detection of out-of-order and lost packets • flags may indicate critical alarm conditions (TDM PWs) • PW PID nibble 5.3 Y(J)S MPLS Slide 130