# Presentation: 668016

## MPLS Basics and In-Depth

**BNL Update****June 29, 2004**

**Overview of MPLS Fundamentals, Basic Operation, and In-Depth overview of Service Capabilities**

**Craig Hill**
**Email: crhill@cisco.com**
**Consulting SE – IP Core**
**Federal Area**

## MPLS Brief – Overview and In-depth Session

_**MPLS Overview**_
**This session will provide the fundamentals for understanding MPLS technology basics. The discussion will include MPLS evolution, terminology, functions of labels, label format, label distribution, as well as encapsulations and basic operation of an MPLS-enabled network. Cisco products supporting MPLS will also be briefly covered.**
_**MPLS In-Depth**_
**Difficulty understanding what advantages MPLS can offer and "why" network architects would consider implementing MPLS into the core of their network?  **
**This section will provide in-depth answers to these questions and explain the advantages and "Services" MPLS can offer Federal customers who are either looking to build an MPLS enabled core or utilize a service offering that is MPLS enabled. Services discussed will include VPN, Layer-2 transport, QoS, and IPv6 transport among others.**

## Agenda

**MPLS History**
**Technology Basics**
**Operation Examples**
**Cisco Product Overview**
**Cisco Products Supporting MPLS**

## Evolution of MPLS

**Evolution of MPLS**

**Origins from Tag Switching**
**Proposed in IETF—Later combined with ideas from other proposals from IBM (ARIS), Toshiba (CSR)**

**1996**

**1997**

**1998**

**1999**

**2000**

**2001**

**Time**

**Cisco Calls a****BOF at IETF to ****Standardize**
**Tag Switching**

**Traffic Engineering **
**Deployed**

**MPLS VPN**
**Deployed**

**Large Scale **
**Deployments**

**Cisco Ships **
**MPLS (Tag ****Switching)**

**Cisco Ships**
**MPLS TE**

**MPLS Croup **
**Formally Chartered**
**by IETF**

**2004**

**AToM, VPLS,**
** ****DS-TE Deployed **

## Why MPLS?

**Why MPLS?**

**Integrate best of Layer 2 and Layer 3**
**Intelligence of IP Routing**
** ****performance of high-speed switching**
**Legacy service transport**
**QoS**
**VPN Semantics**
**Link layers include:**
**Ethernet, PoS, ATM, FR**

_**Note:**_** MPLS and IP could be optimal solution for overall IP**
**          ****Services Architecture.**

**Notes:**
The key, high level, benefits that a customer will get from Tag Switching are:
Scalability - the internet is growing very fast and keeping up with this growth is a priority of our customers.  The inherent scalability characteristics of Tag Switching are the very key allowing service providers to build really bigIP backbones. 
Reducing operational costs - Large telco’s and PTTs will see an increase in their operational costs as they combine IP into the mix of ATM service offerings.  Part of the goal of Tag Switching is to make it simpler to combine IP  and ATM by reducing the amount of complexity required when combining these two technologies resulting in lower operational costs.  
Reliability - there are some capabilities of Tag Switching that will make their networks more robust for IP traffic than they would be without Tag Switching.
New Services - finally new services enabled by Tag Switching such as IP VPNs and IP CoS.

## MPLS as a Foundation for Value Added Services

**MPLS as a Foundation for Value Added Services**

**VPNs**

**MPLS**

**Traffic **
**Engineering**

**IP+ATM**

**Network Infrastructure**

**IP+Optical**
**GMPLS**

**Any **
**Transport **
**Over MPLS**

## MPLS Technology Basics

## MPLS Technology Basics

**IP Routing**
**Labels**
**Control and Forwarding Plane Separation**
**Label Distribution**
**MPLS Environment**
**Label-based Forwarding**

## IP Routing

**IP Routing**

**171.69**

**Packets Forwarded Based on IP Address**

**Data**

**Address **
**Prefix**

**128.89**

**171.69**

**1**

**1**

**I/F**

**...**

**Address **
**Prefix**

**128.89**

**171.69**

**0**

**1**

**...**

**0**

**1**

**I/F**

**128.89**

**0**

**1**

**128.89.25.4**

**Data**

** **

**Address **
**Prefix**

**128.89**

**0**

**...**

**...**

**I/F**

**Data**

**Data**

**128.89.25.4**

**128.89.25.4**

**128.89.25.4**

**Route Update**

**Notes:**
Now when a packet comes into a router a look up is done based on the IP address in the packet, at match is obtained, and the packet is forwarded out the appropriate interface.
The packet follows the same process on a hop-by-hop bases through the network until it reaches its destination.

## MPLS Technology Basics

**IP Routing**
**Labels**
**Control and Forwarding Plane Separation**
**Label Distribution**
**MPLS Environment**
**Label-based Forwarding**

## Encapsulations

**Encapsulations**

**Label Header**

**PPP Header**

**Layer 3 Header**

**PPP Header**
**(Packet over SONET/SDH)**

**Label Header**

**Layer 3 Header**

*** LAN MAC Label Header**

**Label Header**

**Frame Relay**

**Layer 3 Header**

**Frame Relay Label Header**

**MAC Header**

*** LAN MAC Label Header also used for MPLS packets over an ATM Forum PVC SNAP Header. (Ethertype = 0x8847/8848)**

**Notes:**
A tag can be as small as three bytes, or may be larger depending on the application and on the specific media type and encapsulation method used.
Tag information can be carried in a packet in a variety of ways: 
between the PPP and Network Layer headers;
as part of the ATM header
as part of the Network Layer header (e.g., using the Flow Label field in IPv6).
It is therefore possible to implement tag switching over virtually any media type including 
point-to-point links
multi-access links
ATM

## Label Header for Packet Media

**Label Header for Packet Media**

**Can be used over Ethernet, 802.3, or PPP links**
**Uses two new Ethertypes/PPP PIDs (in MAC hdr)**
**Contains everything needed at forwarding time**
**One word per label**

**Label = 20 bits ****	****	****COS/EXP = Class of Service, 3 bits**
**S = Bottom of Stack, 1 bit****	****TTL = Time to Live, 8 bits**

**0               1               2               3**

**0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1**

**Tag**

**COS**

**S**

**TTL**

**MTU beyond 1518 for Ethernet can be accounted for when adding labels by the “mpls mtu” command.**

**Notes:**
The tag frame encapsulation uses what’s called a shim header.  It’s a header that sits between the MAC layer header and the layer 3 header in the packet.  It consists of one or more entries that look like this.  
Its a 32-bit word per entry which contains: 
the tag your forwarding on
a 3-bit class of service field
an 8-bit time to live field, and
a 1-bit end of stack.
The end of stack is what allows you to determine when you’re popping a tag, whether this is the last tag on the packet, or whether there are further tags.

## Label Stacking

**Label Stacking**

**Arrange labels in a stack**
**Inner labels can be used to designate services/FECs, etc.**
**E.g. VPNs, fast re-route, alternate forwarding**
**Outer label used to route/switch the MPLS packets in ****the network**
**(e.g. for VPN, outer label used for forwarding to remote PEs and bottom label for differentiating VPN at remote PE).**
**Allows building services such as:**** **
**MPLS VPNs**
**Traffic engineering and fast re-route**
**VPNs over traffic engineered core**
**Any transport over MPLS**

**Inner Label**

**Outer Label**

**IP Header**

**TE Label**

**IGP Label**

**VPN Label**

## MPLS Technology Basics

**IP Routing**
**Labels**
**Control and Forwarding Plane Separation**
**Label Distribution**
**MPLS Environment**
**Label-based Forwarding**

## Control and Forward Plane Separation

**MPLS Process**

**Route**
** ****Updates/**
**Adjacency**

**Label Bind**
**Updates/**
**Adjacency**

**IP Traffic**

**MPLS Traffic**

**Control Plane**

**Data Plane**

## MPLS Technology Basics

**IP Routing**
**Labels**
**Control and Forwarding Plane Separation**
**Label Distribution**
**MPLS Environment**
**Label-based Forwarding**

## Label Distribution Protocol (LDP)

**Defined in RFC 3036 and 3037**
**Used to distribute labels in a MPLS network**
**Forwarding Equivalence Class (FEC)**
**How packets are mapped to LSPs (Label ****Switched Paths)**
**Advertise labels per FEC**** **
**Reach destination a.b.c.d with label x (per IPL3DA in RIB)**
**Neighbor discovery**

_**UDP and TCP Ports**_
**UDP port for LDP Hello messages = 646**
**TCP port for establishing LDP session connections = 646 **

## TDP and LDP

**Tag Distribution Protocol**
**Pre-cursor to LDP**
**Used for Cisco tag switching**
**TDP and LDP supported on the same box**
**Per neighbor/link basis **
**Per target basis**

## RSVP and Label Distribution

**Used in MPLS Traffic Engineering**
**Additions to base RSVP signaling protocol**
**Leverage the admission control mechanism ****of RSVP**
**Label requests are sent in PATH messages and binding is done with RESV messages**

_**Note:**_**  CR-LDP is another option for label distribution, but is no longer used or implemented**

## BGP-Based Label Distribution

**Used in the context of MPLS VPNs**
**Need multi-protocol extensions to BGP**
**Referred to at M-BGP**
**Uses AFI/SAFI **
**Extension to the BGP protocol in order to carry routing information about other protocols**
**	****Multicast**
**	****MPLS**
**	****IPv6**
**	****VPN-IPv4**
**	****Labeled IPv6 unicast (6PE)**
**	****VPN-IPv6 (6VPE)**
**Exchange of Multi-Protocol NLRI must be negotiated at session set up****	****Utilizes BGP Capabilities Advertisement negotiation procedures**
**VPN edge routers need to be BGP peers**
**Label mapping info carried as part of NLRI (Network Layer Reachability Information)**

## MPLS Technology Basics

**IP Routing**
**Labels**
**Control and Forwarding Plane Separation**
**Label Distribution**
**MPLS Environment**
**Label-based Forwarding**

## General Context

**General Context**

**In Core:**
**Forward using labels (as opposed to IP addr)**
**Label indicates service class and destination**

**	****Label Switch Router (LSR)**

**Label Distribution Protocol (LDP/TDP,**
**RSVP,BGP)**

**	****Edge Label Switch Router**

**At Edge (ingress):**
**Classify packets**
**Label them**

**At Edge (egress):**
**Remove Label**

**	****(****PE) – Provider Edge**

**	****(****P) – Provider**

**	****(****CE) – Customer Edge**

**	****(****PE) – Provider Edge**

**Notes:**
We’ve given you broad definitions of what MPLS does in the network.  Now let’s discuss the essential concept of how MPLS actually works.  Let’s start with terminology.
At the edge of the network, traffic is processed, classified, and given an MPLS label that determines how it will travel through the core to its final destination.  
The core devices look at the label, make a switching decision, and sends the packet to the next stop.  This is how ATM switches can act as routers, because all the decisions are made beforehand and stored in switching tables. 

## Operation

**Traditional routing**
**Each router holds entire routing table and forwards to next hop (destination based routing); routes on L3 Destination address**
**MPLS combines L3 routing with label swapping and forwarding**
**MPLS Forwarding**
**Label imposed at ingress (ingress to label-switched portion of network) router.  Generally, all forwarding decisions then made on label only – no routing table lookups but TFIB table lookups.**
**Tag stripped at egress**

## MPLS Technology Basics

**IP Routing**
**Labels**
**Control and Forwarding Plane Separation**
**Label Distribution**
**MPLS Environment**
**Label-based Forwarding**

## MPLS Example:  Routing Information

**MPLS Example:  Routing Information**

**128.89**

**1**

**0**

**1**

**0**

**Routing Updates (OSPF, EIGRP, ...)**

**You Can Reach 128.89 and 171.69 Thru Me**

**You Can Reach 171.69 Thru Me**

**You Can Reach 128.89 Thru Me**

**In **
**Label**

**Address **
**Prefix**

**128.89**

**171.69**

**1**

**1**

**Out**
**I’face**

**Out****Label**

**In **
**Label**

**Address **
**Prefix**

**128.89**

**171.69**

**0**

**1**

**Out**
**I’face**

**Out****Label**

** **

**In **
**Label**

**Address **
**Prefix**

**128.89**

**0**

**Out**
**I’face**

**Out****Label**

**...**

**...**

**...**

**...**

**...**

**...**

**171.69**

**Notes:**
Tag edge routers and tag switches use standard IP routing protocols to identify routes through the network.  Theses fully interoperate with non-tag switching routers
So what tag switching does is it extends the forwarding table by adding a tag field.  One for the incoming tag and  one for the outgoing tag.  Note the topology of the network is discovered using unmodified layer 3 protocols such as OSPF. 

## MPLS Example:  Assigning Labels

**MPLS Example:  Assigning Labels**

**128.89**

**1**

**0**

**1**

**0**

**Label Distribution Protocol (LDP)**
**(downstream allocation)**

**Use Label 4 for 128.89 and ****Use Label 5 for 171.69**

**Use Label 7 for 171.69**

**In **
**Label**

**Address **
**Prefix**

**128.89**

**171.69**

**1**

**1**

**Out**
**I’face**

**Out****Label**

**In **
**Label**

**Address **
**Prefix**

**128.89**

**171.69**

**0**

**1**

**Out**
**I’face**

**Out****Label**

**In **
**Label**

**Address **
**Prefix**

**128.89**

**0**

**Out**
**I’face**

**Out****Label**

**-**

**9**

**...**

**...**

**...**

**...**

**...**

**...**

**...**

**...**

**...**

**...**

**...**

**...**

**9**

**7**

**4**

**5**

**4**

**5**

**-**

**-**

**171.69**

**Use Label 9 for 128.89**

**Notes:**
Tag routers and switches use the tables generated by the standard routing protocols to assign and distribute tag information via the tag distribution protocol (TDP).  Tag routers receive the TDP information and build a forwarding database, which makes use of the tags.
TDP is then used to bind tags to routes and distribute this information to each routers upstream neighbor.

## MPLS Example:  Forwarding Packets

**In **
**Label**

**Address **
**Prefix**

**128.89**

**171.69**

**1**

**1**

**Out**
**I’face**

**Out****Label**

**...**

**...**

**...**

**...**

**4**

**5**

**-**

**-**

**MPLS Example:  Forwarding Packets**

**Label Switch Forwards Based on Label**

**In **
**Label**

**Address **
**Prefix**

**128.89**

**171.69**

**0**

**1**

**Out**
**I’face**

**Out****Label**

**...**

**...**

**...**

**...**

**9**

**7**

**4**

**5**

**In **
**Label**

**Address **
**Prefix**

**128.89**

**0**

**Out**
**I’face**

**Out****Label**

**-**

**9**

**...**

**...**

**...**

**...**

**Data**

**128.89.25.4**

**Data**

**128.89.25.4**

**Data**

**128.89**

**1**

**0**

**1**

**0**

**128.89.25.4**

**4**

**9**

**MPLS network egress point**

**128.89.25.4**

**Data**

**Notes:**
When we get to the first router, the one performing the tag imposition, there’s an IP look-up based on the IP prefix. It finds the forwarding table entry and it discovers that to get to the destination it should use tag x. It sticks that tag on the front of the packet and forwards it along to the next hop tag switch.
 At this point the router can just do pure tag forwarding, gets in the packet with tag x, figures our that the outgoing interface is y, and the outgoing tag replaces the incoming tag.  Note packet is forwarded based solely on the tag without re-analyzing the network layer header.  This provides the essential separation of routing and forwarding referred to earlier.
The packet reaches the tag edge router at the egress point of the network ,where the tag is stripped off and the packet delivered.

## Cisco Products SupportingMPLS

## Cisco Platforms Supporting MPLS(in a Single Slide) 

_**Important:**_**  Some features are dependent on product model, interface modules (i.e. Line**
**Cards & Port Adapters), and/or require a software feature license. **

**2691**
**3631**
**3640**
**3660**
**3725**
**3745**
**7200**
**7300**
**7400**
**7500**
**10000**
**10700**
**12000**
**12000-PRP**
**AS5350**
**IGX 8400-URM/RPM-RP/XF**
**Catalyst 6K/7600 SUP2/MSFC2**
**Cisco 7600 – SUP720-3BXL**

**Platforms shown were derived for supporting MPLS-VPN and LDP.**
**Some lower-end platforms support several basic MPLS CE features Multi-VRF CE (aka VRF-Lite). These include:**
**3550 (Requires EMI)**
**2600 Series Routers**
**Cisco 7600 Supports L2/L3 MPLS Features w/ MSFC2/PFC2**
**New SUP720-3bXL processor, primary choice for MPLS function in Catalyst 6500/Cisco 7600**

_**Platform Support**_

_**Notes**_

## MPLS In-Depth

**Overview of MPLS Services and Applications currently being Deployed**

## Agenda

**MPLS Drivers**
**- ****Reasons for deploying MPLS**
**MPLS Applications**
** ****MPLS VPN – Layer-3**
** ****Detailed Overview**
** ****IOS Examples**
** ****MPLS Layer-2 Transport**
** ****PWE3/AToM**
** ****Application Example**
** ****MPLS Traffic Engineering**
** ****Fast-ReRoute for Bandwidth Protection**
** ****MPLS QoS**
** ****Diffserv over MPLS **
** ****Diffserv TE (DS-TE)**
** ****Guaranteed Bandwidth Service Applications**
**Useful Implementations Combining Multiple MPLS Services**
**IP version 6 (IPv6) Transport Methods over MPLS**
** ****6PE/6VPE (IPv6 Edge and VPN Support)**
**Useful URL’s ****(Reference Information)**

## Why MPLS? - Major Drivers

**Provide IP VPN Services**
**Scalable IP VPN service – Build once and sell many**
**Managed Central Services – Building value add services and offering them across VPNs (i.e. Multicast, Address Mgmt)**
**Managing traffic on the network using MPLS Traffic Engineering**
**Providing tighter SLA/QoS (Guaranteed B/W Services)**
**Protecting bandwidth ****- Bandwidth Protection Services are enabling Service Providers to look at alternate approaches to SONET APS**
**Integrating Layer 2 & Layer 3 Infrastructure**
**Layer 2 services such as Frame Relay and ATM over MPLS**
**Mimic layer 2 services over a highly scalable layer 3 infrastructure**

## Customer Deployment

**We are now up to 225+ (Total – SP+Enterprise) deployed customers in production networks**
**Some case studies Documented**
**Very large deployments include a **_**single**_** customer requiring:**
**30K CEs, ~1000 PEs**
**MPLS VPNs continues to be majority deployments**
**AToM is the majority in the recent deployments**
**TE Catching on fast**
**Simple mechanism – unequal cost load balancing**
**QoS Service offering in the MPLS Services**

## MPLS Applications

## MPLS Layer 3 VPNs

## Virtual Network Models

- Virtual Networks

- Virtual Private Networks

- Virtual Dialup Networks

- Virtual LANs

- Overlay VPN

- Peer-to-Peer VPN

- Layer-2 VPN

- Layer-3 VPN

- Access lists (Shared router)

- Split routing (Dedicated router)

**MPLS/VPN**

- X.25

- F/R

- ATM

- GRE

- IPSec

**Virtual Network Models**

## Overlay Network

**Provider sells a circuit service **
**Customers purchases circuits to connect sites, runs IP **
**N sites, (N*(N-1))/2  circuits for full mesh****—****expensive**
**The big scalability issue ****here is routing peers****—****N sites, each site has N-1 peers**
**Hub and spoke is popular, suffers from the same N-1 number of routing peers**
**Hub and spoke with static routes is simpler, still buying N-1 circuits from hub to spokes**
**Spokes distant from hubs could mean lots of long-haul circuits**

## Peer Network

**Provider sells an MPLS-VPN service**
**Customers purchases circuits to connect sites, runs IP**
**N sites, N circuits into provider**
**Access circuits can be any media ****at any point (FE, POS, ATM, T1, ****dial, etc.)**
**Full mesh connectivity without full mesh of L2 circuits**
**Hub and spoke is also easy to build**
**Spokes distant from hubs connect ****to their local provider’s POP, lower access charge because of ****provider’s size**
**The Internet is a large peer network**

**Provider**
**(MPLS-VPN)**

## MPLS L3 VPNs using BGP (RFC2547)

**End user perspective**
**Virtual Private IP service**
**Simple routing – just point default to provider**
**Full site-site connectivity without the usual drawbacks (routing complexity, scaling, configuration, cost)**
**Major benefit for provider – scalability**

**VPN B**

**VPN C**

**VPN B**

**VPN C**

**VPN A**

**VPN A**

**VPN B**

**VPN C**

**VPN A**

**VPN C**

**VPN B**

**VPN A**

**VPN B**

**VPN C**

## MPLS VPN Topology

**MPLS VPN Topology**

**VPN A/Site 1**

**VPN C/Site 2**

**VPN A/Site 2**

**VPN B/Site 2**

**VPN B/Site 1**

**VPN C/Site 1**

**CE****A1**

**CE****B3**

**CE****A3**

**CE****A2**

**CE****1****B1**

**CE****2****B1**

**PE****1**

**PE****2**

**PE****3**

**P****1**

**P****2**

**P****3**

**16.1/16**

**12.1/16**

**16.2/16**

**11.1/16**

**11.2/16**

**RIP**

**Static**

**RIP**

**RIP**

**BGP**

**Static**

**RIP**

**BGP**

**12.2/16**

**CE****B2**

## VPN Routing and Forwarding Instance (VRF) 

**PE routers maintain separate routing tables**
**Global routing table**
**Contains all PE and P routes (perhaps BGP)**
**Populated by the VPN backbone IGP **
**VRF (VPN routing and forwarding)**
**Routing and forwarding table associated with one or more directly connected sites (CE routers)**
**VRF is associated with any type of interface, whether logical or physical (e.g. sub/virtual/tunnel) **
**Interfaces may share the same VRF if the connected sites share the same routing information**
**Not virtual routers, just virtual routing and forwarding**

## PE Router – Global Routing Table Output

**PE2#sh ip route **
**Gateway of last resort is not set**
**C    192.168.1.0/24 is directly connected, Ethernet0/0**
**     ****192.168.100.0/32 is subnetted, 3 subnets**
**O       192.168.100.1 [110/11] via 192.168.1.1, 00:04:27, Ethernet0/0**
**C       192.168.100.2 is directly connected, Loopback0**
**O       192.168.100.3 [110/11] via 192.168.1.3, 00:04:27, Ethernet0/0**

**CE2**

**PE2**

**192.168.100.2**

**192.168.100.1**

**PE1**

**OSPF**

**Routes from PE1’s Global Routing Table**

## PE Router – VRF Routing Table Output

**PE Router – VRF Routing Table Output**

**PE2#sh ip route vrf RED**
**Routing Table: RED**
**Gateway of last resort is 192.168.100.1 to network 0.0.0.0**
**     ****172.16.0.0/16 is variably subnetted, 8 subnets, 3 masks**
**C       172.16.25.0/30 is directly connected, Serial4/0**
**C       172.16.25.2/32 is directly connected, Serial4/0**
**B       172.16.20.0/24 [20/0] via 172.16.25.2, 00:07:04**
**     ****10.0.0.0/24 is subnetted, 1 subnets**
**B       10.0.0.0 [200/307200] via 192.168.100.1, 00:06:28**
**B*   0.0.0.0/0 [200/0] via 192.168.100.1, 00:07:03**

**CE2**

**PE2**

**172.16.25.2**

**172.16.25.1**

**PE1**

**iBGP VPNv4**

**Routes from PE1**

**10.0.0.0/24**

**172.16.20.0/24**

## Virtual Routing and Forwarding Instances

**Virtual Routing and ****Forwarding Instances**

**Define a unique VRF for interface 0**
**Define a unique VRF for interface 1**
**Packets will never go between int. 0 and 1**
**Uses VPNv4 to exchange VRF routing information between PE’s**
**No MPLS yet...**

**VPN-A**

- VPN-A

**CE**

**VPN-B**

**VRF for VPN-A**

**VRF for VPN-B**

**CE**

**146.12.7.0/24**

**195.12.2.0/24**

**0**

**1**

**Global Routing Table**

**VPN Routing Table**

**PE**

## VRF Route Population

**CE**

**iBGP Domain**

**CE**

**MPLS Domain**

**PE**

**Separate Physical Links**

**Separate router per Customer/VPN**

**VRF Route Population**

**VRF is populated ****locally**** through PE and CE routing protocol exchange**
- RIP Version 2, OSPF, BGP-4, EIGRP, & Static routing
- “connected” is also supported (i.e. Default-gateway is PE)
**Separate routing context for each VRF**
- routing protocol context (BGP-4 & RIP V2)
- separate process (OSPF)

**eBGP, EIGRP,OSPF, RIPv2,Static**

## Carrying VPN Routes in BGP

**VRFs by themselves aren’t all that useful**
**Need some way to get the VRF routing information off the PE and to other Pes**
**This is done with BGP**

## Additions to BGP to Carry MPLS-VPN Info

**RD: Route Distinguisher**
**VPNv4 address family**
**RT: Route Target**
**Label**

## Route Distinguisher

**To differentiate 10.0.0.0/8 in VPN-A from 10.0.0.0/8 in VPN-B**
**64-bit quantity**
**Configured as ASN:YY or IPADDR:YY**
**Almost everybody uses ASN**
**Purely to make a route unique**
**Unique route is now RD:Ipaddr (96 bits) plus a mask on the IPAddr portion**
**So customers don’t see each others routes**

**!**
**ip vrf red**
**rd 1:1**
**route-target export 1:1**
**route-target import 1:1**

## Route Target

**To control policy about who sees what routes**
**64-bit quantity (2 bytes type, 6 bytes value)**
**Carried as an extended community**
**Typically written as ASN:YY**
**Each VRF ‘imports’ and ‘exports’ one or ****more RTs**
**Exported RTs are carried in VPNv4 BGP**
**Imported RTs are local to the box**
**A PE that imports an RT installs that route in its routing table**

**!**
**ip vrf red**
**rd 1:1**
**route-target export 1:1**
**route-target import 1:1**

## VPNv4

**In BGP for IP, 32-bit address + mask makes a unique announcement**
**In BGP for MPLS-VPN, (64-bit RD + 32-bit address) + 32-bit mask makes a unique announcement**
**Since the route encoding is different, need a different address family in BGP**
**VPNv4 = VPN routes for IPv4**
**As opposed to IPv4 or IPv6 or multicast-RPF, etc...**
**VPNv4 announcement carries a label with the route**
**“****If you want to reach this unique address, get me packets with this label on them”**

## MPLS Layer-3 VPNOperation Example

## VRF Population of MP-BGP

- Service Provider Network

- PE-1

- PE-2

- CE

- CE

**PE routers translate into VPN-V4 route**
- Assigns an RD, SOO (if configured) and RT based on configuration
- Re-writes Next-Hop attribute (to PE loopback)
- Assigns a label based on VRF and/or interface
- Sends MP-BGP update to all PE neighbors** **

**BGP, OSPF, RIPv2 update ****149.27.2.0/24****,NH=CE-1**

**VPN-v4 update:****RD:1:27:****149.27.2.0/24,**** ****Next-hop=****PE-1****RT=****VPN-A**
**Label=(****28****)**

**VRF Population of MP-BGP**

**Paris**

**London**

## VRF Population of MP-BGP

- Service Provider Network

- PE-1

- PE-2

- CE

- CE

**BGP, OSPF, RIPv2 update ****149.27.2.0/24****,NH=CE-1**

**Receiving PE routers translate to IPv4**
- Insert the route into the VRF identified by the RT
- attribute (based on PE configuration)** **
**The label associated to the VPN-V4 address will be set on packets forwarded towards the destination**

**VPN-v4 update:****RD:1:27****:149.27.2.0/24****,**** ****Next-hop=****PE-1****RT=****VPN-A**
**Label=(****28****)**

**VPN-v4 update is translated into IPv4 address and put into VRF ****VPN-A**** as RT=VPN-A and optionally  advertised to any attached sites**

**VRF Population of MP-BGP**

**Paris**

**London**

## MPLS/VPN Packet Forwarding

**Between PE and CE, regular IP packets (currently)**
**Within the provider network****—****label stack**
**Outer label: “get this packet to the egress PE”**
**Inner label: “get this packet to the egress CE”**
**MPLS nodes forward packets based on **_**TOP**_** label!!!**
- any subsequent labels are ignored
**Penultimate Hop Popping procedures used one hop prior to egress PE router (shown in example)**

## MPLS/VPN Packet Forwarding

**In Label           FEC             Out Label**
**      ****-****          ****197.26.15.1/32****       ****   41**

**Paris**

**149.27.2.27**

**PE-1**

**London**

**149.27.2.0/24**

**Ingress PE receives normal IP packets**
**PE router performs ****IP Longest Match**** from VPN FIB, finds iBGP next-hop and imposes a stack of labels <IGP, VPN>**

**149.27.2.27**

**28**

**41**

**VPN-A VRF****149.27.2.0/24,**** ****NH=****197.26.15.1****Label=(****28****)**

**MPLS/VPN Packet Forwarding**

## MPLS/VPN Packet Forwarding

**In Label           FEC             Out Label**
**    ****41****        ****197.26.15.1/32****     ****     POP**

**Paris**

**149.27.2.27**

**PE-1**

**London**

**149.27.2.0/24**

**149.27.2.27**

**28**

**41**

**VPN-A VRF****149.27.2.0/24,**** ****NH=****197.26.15.1****Label=(****28****)**

**149.27.2.27**

**28**

**In Label           FEC             Out Label**
**    ****28(V)****     ****149.27.2.0/24****     ****       ****-**

**VPN-A VRF****149.27.2.0/24,**** ****NH=****Paris**

**149.27.2.27**

**Penultimate PE router removes the IGP label**
- Penultimate Hop Popping procedures (implicit-null label)

**Egress PE router uses the VPN label to select which VPN/CE to forward the packet to**

**VPN label is removed and the packet is routed toward the VPN site**

**MPLS/VPN Packet Forwarding**

## Things to Note

**Core does not run VPNv4 BGP!**
**Same principle can be used to run a BGP-free core ****for an IP network**
**CE does not know it’s in an MPLS-VPN**
**Outer label is from LDP/RSVP**
**Getting packet to egress PE is mutually independent to ****MPLS-VPN**
**Inner label is from BGP**
**Inner label is there so the egress PE can have the same network in multiple VRFs**

## VRF Route Population

**CE**

**iBGP Domain**

**CE**

**MPLS Domain**

**PE**

**Separate Physical Links**

**Separate router per Customer/VPN**

**VRF Route Population**

**VRF is populated ****locally**** through PE and CE routing protocol exchange**
- RIP Version 2, OSPF, BGP-4, EIGRP, & Static routing
- “connected” is also supported (i.e. Default-gateway is PE)
**Separate routing context for each VRF**
- routing protocol context (BGP-4 & RIP V2)
- separate process (OSPF)

**eBGP, EIGRP,OSPF, RIPv2,Static**

## Multi-VRF CE (VRF-lite)

**Each VRF separation on the PE is extended to the CE**
**Separation is maintained via layer-2 transport that support “logical” separation (e.g. 802.1Q, FR/ATM VC’s**
**CE router must be capable of supporting VRF’s**
**CE is not required to support MPLS labels**
**Routing protocol options from CE-PE remain the same (e.g. BGP, RIPv2, OSPF, EIGRP, static)**

**iBGP Domain**

**Routing Updates**

**Multi-VRF CE (VRF-lite)**

**CE**

**MPLS Domain**

**PE**

**Single Physical Link**
**Logical Link per VRF**
**Layer-2 must support logical separation**
**802.1q, FR/ATM VC’s**

**Single router supporting**
**Multiple VRF Instances**

**NO Labels Required**

## Customers Connecting to a Layer-3 VPN Service

**What routing protocol is supported by the carrier (CE-PE)?**
**What address space do they allow for CE-PE subnet?**
**What layer-2 transport is required/supported from CE-PE?**
**Do they provide a QoS SLA?**
**Concerning QoS, do they require DSCP or ToS settings from the CE to their PE?**
**Do they manipulate DSCP/ToS based on congestion in their network?**
**What other services do they have on their roadmap of “Service Offerings” (Example:  IPv6, IP Multicast, Tighter QoS SLA offering, other??)**
**Understand the resiliency in the core**
**Do they offer LEC diversification or “bypass”?**

## Validating Cisco MPLS Based IP-VPN as a Secure Network

**Miercom independent testing confirmed Cisco MPLS VPN is secure:**

**Customers network topology is not revealed to the outside world**
**Customers can maintain own addressing plans and the freedom to use either public or private address space**
**Attackers cannot gain access into VPNs or Service Provider’s network**
**Impossible for attacker to insert “spoofed” label into a Cisco MPLS network and thus gain access to a VPN or the MPLS core**

**Test Network Topology**

**http://mier.com/reports/cisco/MPLS-VPNs.pdf**

**Notes:**
In the area of security our solution provides basic security that is comparable to what is provided by Frame Relay/ATM based VPNs. 
Important to stress that this level of security is provided without requiring the use of IPsec.
We also understand that some customers may have security requirements above and beyond what is provided by Frame Relay/ATM based VPNs. For these customers we think that data privacy has to be provided by the customer’s equipment.

## Managed Shared Services Are The Future of Centralized Services

**Managed Shared Services Are The Future of Centralized Services**

**Centralized**
**Services**

**Co-Location**

**Centralized**
**Hosting Services**

**Centralized**
**Application**
**Services**

**L2/L3 Connectivity**

**Data Center Space**

**L2/L3 Connectivity**
**For VPNs**

**Basic Hosting**

**Managed Security**

**Managed Network Services**

**Platform Services**

**E-Comm App Mgmt**

**Business Logic**

**Customer Relation**

**Value Added Services**

- VPN Aware NAT

**IP Address Management**

**VPN Aware HSRP/VRRP**

**Cisco IOS® - Key enabler to Centralized Add-on Services in MPLS-VPN’s**

**Multicast VPN**

**VPN Select**

## mVPN : Concept & Fundamentals

**Receiver 4**

**B1**

**F**

**CE**

**CE**

**CE**

**Receiver 2**

**CE**

**CE**

**MPLS VPN**
**Core **

**CE**

**E**

**The MPLS Core forms a Default MDT for a given Customer**

**Customer CE devices joins the MPLS Core through provider’s PE devices**

**Data-MDT is formed for this High-Bandwidth source**

**A High-bandwidth source for that customer starts sending traffic**

**Interested receivers 1 & 2 join that High Bandwidth source**

**CE**

**B2**

**San Francisco**

## MPLS Layer-2 Transport

## Layer 2 Transport
 L2TPv3 
 draft-ietf-l2tpext-l2tp-base-07.txt
 draft-ietf-l2tpext-l2tpmib-base-01.txt
 MPLS (P2P, formerly draft-martini)
 draft-ietf-pwe3-control-protocol-01.txt
 draft-ietf-pwe3-[atm, frame-relay, ethernet, etc.]
Layer 2 VPN (VPLS)
 draft-lasserre-vkompella-ppvpn-vpls-02.txt 
Auto-Provisioning
 draft-ietf-ppvpn-bgpvpn-auto-02.txt (BGP auto-discovery)

**Layer 2 Transport**
** ****L2TPv3 **
** ****draft-ietf-l2tpext-l2tp-base-07.txt**
** ****draft-ietf-l2tpext-l2tpmib-base-01.txt**
** ****MPLS (P2P, formerly draft-martini)**
** ****draft-ietf-pwe3-control-protocol-01.txt**
** ****draft-ietf-pwe3-[atm, frame-relay, ethernet, etc.]**
**Layer 2 VPN (VPLS)**
** ****draft-lasserre-vkompella-ppvpn-vpls-02.txt**** **
**Auto-Provisioning**
** ****draft-ietf-ppvpn-bgpvpn-auto-02.txt (BGP auto-discovery)**

**Pseudo Wire –****Cisco IETF Technology Adoption**

## 
Layer 2 Transport for MPLS Networks 
HDLC/PPP
Frame Relay
Ethernet (802.1Q)
ATM AAL5 & Cell Relay

**Layer 2 Transport for MPLS Networks **
**HDLC/PPP**
**Frame Relay**
**Ethernet (802.1Q)**
**ATM AAL5 & Cell Relay**

**AToM**
**Any Transport Over MPLS**

## Motivation for AToM

**Protect existing investment while building packet core**
**Frame Relay and ATM**
**Non-IP protocols – SNA, IPX**
**Trunk customer traffic**
**Trunk customer’s IGP across the provider backbone **
**Especially when the customer is connecting over disparate media**
**Provider devices forward customer packets based on Layer 2 information**
**Circuits (ATM/FR), MAC address**
**CPE-based Tunnels (e.g. IPSEC) analogous to circuits**
**Possibility of a new service (VPLS – ****emulated LAN****)**
**Good fit for customers that either **
**Simply want connectivity**
**Have non-IP protocols**

## AToM –VC Information Exchange

**VC labels are exchanged across a ****directed LDP**** session between PE routers**
- Carried in Generic Label TLV within LDP Label Mapping Message (RFC3036 -LDP)
**New LDP FEC element defined to carry VC information**
- FEC element type ‘128 – Virtual Circuit FEC Element’;
- Carried within LDP Label Mapping Message
**VC information exchanged using ****Downstream Unsolicited**** label distribution procedures**
- Described in draft-martini-l2circuit-trans-mpls

**Notes:**
------
1. First, the assumption is that traffic can be delivered between the two end-points.  This is referred to as the Tunnel Label and is the outer most label in PW emulation.  The corresponding path imposed by the tunnel labels is the Tunnel LSP.  This is assumed to be functioning. Note: The tunnel could be GRE encapsulated.  In this case, a Tunnel label is not required as the routers appear to be adjacent.
“The tunnel LSP merely gets packets from R1 to R2, the corresponding label doesn't tell R2 what to do with the payload, and in fact if penultimate hop popping is used, R2 may never even see the corresponding label. “ (draft-martini-l2circuit-trans)

2. We need a method to negotiate a VC Label.  This component is required for a pair of PEs to agree on the how they wish to identify this circuit.  For this, we use a directed LDP session setup between the partipating PEs.  Via this session, the Pes agree on a label they wish to use to identify the pseudo wire.  A Generic Label TLV within the Label Mapping Message has the assigned label.  This process is uni-directional and repeated by the peer.

3. Directed LDP session:
Extended Discovery Mechanism LDP sessions between non-directly connected LSRs are supported by LDP Extended Discovery. To engage in LDP Extended Discovery an LSR periodically sends LDP Targeted Hellos to a specific address. LDP Targeted Hellos are sent as UDP packets addressed to the well-known LDP discovery port at the specific address. An LDP Targeted Hello sent by an LSR carries the LDP Identifier for the label space the LSR intends to use and possibly additional optional information. 
-----
FEC – Type ‘128 – Virtual Circuit FEC Element’

-----
LDP (RFC3036)
Sections:
2.6.2.1 Conservative Label Retention Mode: 
Essentially, in downstream unsolicited mode when all down stream LSR peers send labels to their neighbors, only labels that will be used for forwarding packets are retained.  All others are discarded.

2.6.2.2 Liberal Label Retention Mode
In contrast to Conservative label retention, Liberal label retention keeps all labels received for any particular FEC, regardless of whether it will be used or not.  One benefit, is that the LSR can react to routing changes more quickly as the labels already exist.  The disadvantage is in the case of limited label space, unneeded labels are kept and maintained.

3.5.7.1.4 Downstream Unsolicited Label Advertisement
In general, the downstream LSR is responsible for advertising a label mapping when it wants an upstream LSR to use the label. An upstream LSR may issue a mapping request if it so desires.

3.2 – LDP Procedures
LDP defines messages, TLVs and procedures in the following areas:
 - Peer discovery;
 - Session management;
 - Label distribution;
 - Notification of errors and advisory information. 

Operational Facts:
The directed LDP session operates in downstream, unsolicited mode.
The same VC-ID and VC-Type MUST be assigned in both directions
Group-ID doesn’t need to match
Transported L2 PDUs can only have the headers modified on the egress router (I.E. DLCI re-write, VLAN re-write, etc.)

## AToM –

**PE2**

**PE1**

**CE**

**CE1**

**Bi-directional Label/VCID mapping exchange**

**AToM –**
**Label Mapping Exchange**

**PE2 repeats steps 1-5 so that bi-directional label/VCID mappings are established**

**1. L2 transport route entered on ingress PE**

**2. PE1 starts LDP session with PE2 if one does not already exist**

**3. PE1 allocates VC label for new interface & binds to configured VCID**

**4. PE1 sends label mapping message containing VC FEC TLV & VC label TLV**

**5. PE2 receives VC FEC TLV & VC label TLV that matches local VCID**

**Tunnel Label**

**VC Label**

**PDU**

**Notes:**
An “MPLS L2 transport route” or “xconnect” command is entered on the ingress interface on PE1. 
PE1 starts a remote LDP session with PE2 if there is none already existing. Both PEs receive LDP KeepAlive messages from each other, reach OPERATIONAL state, and are ready to exchange label bindings. 
The physical layer of the ingress interface on PE1 comes up. PE1 realizes there is a VC configured for the ingress interface over which Layer 2 PDUs received from CE1 are forwarded, so it allocates a local VC label and binds it to VC ID configured under the ingress interface. 
PE1 encodes this binding with the VC label TLV and VC FEC TLV and sends it to PE2 in a Label-Mapping message. 
PE1 receives a Label-Mapping message from PE2 with a VC FEC TLV and VC label TLV. In the VC FEC TLV, the VC ID has a match with a locally configured VC ID. The VC label encoded in the VC label TLV is the outgoing VC label that PE1 is going to use when forwarding Layer 2 PDUs to PE2 for that particular VC. 
PE1 might receive a Label-Request message from some other PE with a specific VC FEC TLV at any time during the OPERATIONAL state. PE1 examines the VC ID encoded in the FEC element, and responds to the peer a Label-Mapping with the local VC label corresponding to the VC ID. 
PE2 performs the same steps 1-6 as PE1. Once both exchange the VC labels for a particular VC ID, we say the VC with that VC ID is fully established. 
When one LSP of a VC is taken down for some reason, for example, the CE-PE link goes down, or the VC configuration is removed from one PE router, the PE router must send a Label-Withdraw message to its remote LDP peer to withdraw the VC label it previously advertised. 

## Layer 2 Integration – ATM/FR over MPLS

**Layer 2 Integration – ATM/FR over MPLS**

**PE**

**MPLS Backbone**

**PE**

**ATM/FR**

**CPE Router**

**ATM/FR**

**CPE Router**

**Virtual Circuits**

**Any Transport over MPLS (AToM) Tunnel **
**Cells/frames with labels**

**Virtual Leased Line**

**Two different requirements for the transport of **_**ATM**_** across an MPLS backbone**
- - Transport of AAL5 encapsulated frames (RFC1483);
- - Transport of ATM cells (cell relay)

**AToM FR will support DLCI to DLCI switching**
- Both local and distributed connectivity;
- PE will act as DCE or NNI Interface;
- Different encapsulation may be used on both ends of the PVC e.g Cisco encapsulation on one end and IETF (RFC 1490) encapsulation on the other end

**QoS Options, Mapping: L2********IP********EXP**

## Layer 2 Integration - Ethernet over MPLS

** ****Port-mode**
**Allows a frame coming into an interface to be packed into an MPLS packet**
** ****VLAN-mode**
**Forwards frames from a SRC 802.1Q VLAN to a DST 802.1Q VLAN**

## PPP/HDLC over MPLS

**End to End PPP/HDLC Session**

**PPP/HDLC over MPLS**

**Customer Edge**

**Customer Edge**

**MPLS Network**

**Broadband Access**

**DSL**
**Cable**
**BBFW**

**Content Cache**
**DNS, AAA**

**End to End PPP Session**

**Remote Hosting**
**& Backhaul**

## Example:ATM KG connection over ATM Cell Relay (AToM)

**PE1**

**PE2**

**P**

**L0: 192.168.100.10/32**

**L0: 192.168.100.12/32**

**L0: 192.168.100.11/32**

**2.0/24**

**4.0/24**

**3.0/24**

**.1**

**.1**

**.1**

**.2**

**.2**

**.2**

**192.168.0.0/24**

**FE**

**FE**

**FE**

**OC-3**

**OC-3**

**7505**

**7200**

**7507**

**PVC**
**0/200**

**PVC**
**0/200**

**7505-AToM-PE#sh atm vc**
**               ****VCD /                                     Peak Avg/Min Burst**
**Interface      Name         VPI   VCI Type    Encaps     Kbps    Kbps Cells Sts**
**2/0/0.100      4              0   100 PVC     AAL0     149760     N/A       UP  **

- Pseudo-wire LSP

**Example:****ATM KG connection over ATM Cell Relay (AToM)**

**Notes:**
Example 1 VC Mode Configuration Example
PE1 PE2
mpls label protocol ldp
mpls ldp router-id Loopback0 force
!
interface Loopback0
ip address 12.12.12.12 255.255.255.255
!
interface ATM4/0
pvc 0/100 l2transport
encapsulation aal0
xconnect 13.13.13.13 100 encapsulation mpls
!
interface ATM4/0.300 point-to-point
no ip directed-broadcast
no atm enable-ilmi-trap
pvc 0/300 l2transport
encapsulation aal0
xconnect 13.13.13.13 300 encapsulation mpls
mpls label protocol ldp
mpls ldp router-id Loopback0 force
!

--------------------------------------------------------------------------------
interface Loopback0
ip address 13.13.13.13 255.255.255.255
interface ATM4/0
pvc 0/100 l2transport
encapsulation aal0
xconnect 12.12.12.12 100 encapsulation mpls
!
interface ATM4/0.300 point-to-point
no ip directed-broadcast
no atm enable-ilmi-trap
pvc 0/300 l2transport
encapsulation aal0
xconnect 12.12.12.12 300 encapsulation mpls

## MPLS AToM “show” Output

**7200-AToM-PE# ****show mpls l2 vc****      **
**Local intf     Local circuit        Dest address       VC ID      Status    **
**-------------  --------------------         ---------------        ----------     ----------**
**AT4/0          ATM VPC CELL 0       192.168.100.10     200        UP        **

**7200-AToM-PE# ****show mpls l2 vc detail**
**Local interface: AT2/0/0 up, line protocol up, ATM VPC CELL 0 **
**  ****Destination address: 192.168.100.10, VC ID: 200, VC status: up**
**    ****Preferred path: not configured  **
**    ****Default path: active**
**    ****Tunnel label: imp-null, next hop point2point**
**    ****Output interface: Tu200, imposed label stack {16}**
**  ****Create time: 23:16:48, last status change time: 16:53:49**
**  ****Signaling protocol: LDP, peer 192.168.100.12:0 up**
**    ****MPLS VC labels: local 16, remote 16**
**    ****Group ID: local 0, remote 0**
**    ****MTU: local n/a, remote n/a**
**    ****Remote interface description: **
**  ****Sequencing: receive disabled, send disabled**
**  ****VC statistics:**
**    ****packet totals: receive 9693985, send 777914411**
**    ****byte totals:   receive 581639100, send 3725191700**
**    ****packet drops:  receive 0, send 0**

## Building on the theme – One Network Any Access

**Any to Any connectivity (Future)**
**Interworking between disparate transports**
**Use AToM control plane to do service interworking**

**Frame Relay to ATM**
**Frame Relay to Ethernet**
**Ethernet to ATM**
**Frame Relay to HDLC/PPP**
**Ethernet to POS**
**.**
**.**

**Frame Relay**
**ATM**
**Ethernet**
**PPP**
**Cisco HDLC**

**Frame Relay**
**ATM**
**Ethernet**
**PPP**
**Cisco HDLC**

**MPLS**

## VPLS – Building Blocks Based on: draft-lasserre-vkompella-ppvpn-vpls-02.txt 

**VPLS – Building Blocks**** ****Based on:**** ****draft-lasserre-vkompella-ppvpn-vpls-02.txt**** **

## MPLS Traffic Engineering

**Bandwidth Protection****using****MPLS Traffic Engineering****with**
**Fast ReRoute (FRR)**

## Traffic Engineering - Theory

**MPLS-TE was designed to move traffic along a path other than the IGP shortest path**
**Bring ATM/FR traffic engineering abilities to an IP network**
**Avoid full IGP mesh and n(n – 1)/2 flooding**
**Bandwidth-aware connection setup **
**Fast ReRoute (FRR) is emerging as another application of MPLS-TE**
_**Bandwidth Protection:**_**  Allows for tighter control on bandwidth – packet loss, delay & jitter**
**Minimal packet loss (msec) when a link goes down**
**Can be used in conjunction with MPLS-TE for primary paths, can also be used in standalone **
**Provide Virtual Leased Lines – DS-TE + QoS**
**Intelligent network infrastructure for better bandwidth guarantees (DS-TE, Online Bandwidth Protection, Voice VPNs etc)**

## The Problem with Shortest-Path

**The Problem with Shortest-Path**

**Changing to A->C->D->E ****won’t help**

**Router C**

**Router D**

**Router G**

**80Mb Traffic**

**35Mb Drops!**

**Router A**

**Router B**

**Some links are DS3, some ****are OC-3**

**Router A has 40Mb of traffic for Route F, 40Mb of traffic for Router G**

**Massive (44%) packet loss at Router B->Router E!**

**Router E**

## Path Calculation

**Node**

**Next-Hop**

**Cost**

**B**

**10**

**B**

**F**

**30**

**Tunnel 0**

**C**

**10**

**C**

**D**

**20**

**C**

**E**

**20**

**B**

**G**

**30**

**Tunnel 1**

**Path Calculation**

**PCALC takes bandwidth, other constraints into account**
**Link state protocol advertises “unreserved capacity”**
**Constraints (required bandwidth and policy) are specified for a TE “trunk”**
**End result: Bandwidth used more efficiently!**

**40Mb**

**OC-3**

**OC-3**

**DS3**

**DS3**

**DS3**

**OC-3**

**Router C**

**Router E**

**Router D**

**Router G**

**Router A**

**Router B**

**40Mb**

**OC-3**

## Forwarding Traffic Down a Tunnel

**There are three ways traffic can be forwarded down a TE tunnel**
**Auto-route**
**Static routes**
**Policy routing**
**With the first two, MPLS-TE gets you unequal cost load balancing**

## Fast ReRoute 

**FRR: A mechanism to minimize packet loss during a failure**
_**Pre-provision**_** protection tunnels that carry traffic when a protected resource (link/node) goes down**
**Use MPLS-TE to signal the FRR protection tunnels, taking advantage of the fact that MPLS-TE traffic doesn’t have to follow the IGP shortest path**
**Used as a mechanism (along with DS-TE) for tight SLA offerings for “Guaranteed Bandwidth Services”**

## Link Protection*

**Link Protection***

**Primary Tunnel: A -> B -> D -> E**
**BackUp Tunnel: B -> C -> D (Pre-provisioned)**
**Recovery = ~50ms**

**Router D**

**Router C**

**Router A**

**Router B**

**Router E**

**Router Y**

**Router X**

***Introduced in 12.0(11)ST**

## Node Protection

**Node Protection**

**Primary Tunnel: A -> B -> D -> E -> F**
**BackUp Tunnel: B -> C -> E (Pre-provisioned)**
**Recovery = ~100ms**

**Router E**

**Router C**

**Router A**

**Router B**

**Router F**

**Router Y**

**Router X**

**Router D**

**Introduced in 12.0(22)S**

## Standardization - IETF

**MPLS Working Group**
**Fast Reroute Extensions:**
**draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt**
**Fast Reroute MIB:**
**draft-ietf-mpls-fastreroute-mib-01.txt**
**IETF Drafts**
**Bandwidth Protection**
**draft-vasseur-mpls-backup-computation-01.txt**
**Path Computation (eg. Inter-AS)**
**draft-vasseur-mpls-computation-rsvp-02.txt**

## MPLS QoS

## DiffServ over MPLS

**MPLS doesn’t define a new QoS architecture**
**Most of the work on MPLS QoS has focused on supporting current IP QoS architectures**
**Same traffic conditioning and Per-Hop behaviors as defined by DiffServ**

## Label Header for Packet Media

**Label****	****20 bits**
**EXP****	****Experimental Field, 3 bits**** **
**S****	****Bottom of Stack, 1 Bit**
**TTL****	****Time to Live, 8 Bits**

**0                   1                   2                   3**

**0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1**

**Label**

**EXP**

**S**

**TTL**

**Label Header for Packet Media**

**Can be used over other layer-2 technologies**
**Contains all information needed at forwarding time**
**One 32-bit word per label**
**EXP field size limitation by standards**

**Notes:**
The tag frome encapsulation uses what’s called a shim header.  It’s a header that sits between the MAC layer header and the layer 3 header in the packet.  It consists of one or more entries that look like this.  
Its a 32-bit word per entry which contains: 
the tag your forwarding on
a 3-bit class of service field
an 8-bit time to live field, and
a 1-bit end of stack.
The end of stack is what allows you to determine when you're popping a tag, whether this is the last tag on the packet, or whether there are further tags.

## Diff-Serv Support Over MPLS

**E-LSP**

**LDP/RSVP**

**LDP/RSVP**

**EF**

**AF1**

**Diff-Serv Support Over MPLS**

**Diff-Serv is supported today over MPLS**
**RFC3270**
**Neither more nor less than “plain old” Diff-Serv**
**Example above illustrates support of EF and AF1 on single E-LSP**
**EF (****E****xpedited Forw****arding) ****and AF1 (Assured Forwarding) packets travel on single LSP (single label) but are enqueued in different queues (different EXP values)**

## DiffServ MPLS QoS Implementation

**Enterprise LAN**

**PE**

**CE**

**Enterprise LAN**

**MPLS Core**

**CE**

**PE**

_**CE Out**_
**FR TS**
**LLQ**
**WRED**
**FRF.12**
**cRTP**

_**PE Out**_
**LLQ**
**WRED**

_**P - P**_
**LLQ**
**WRED**

_**PE - P**_
**LLQ**
**WRED**

_**P - PE**_
**LLQ**
**WRED**

_**PE In**_
**Police**
**Mark**

_**Notes:**_
**Traffic Classified by EXP**
** ****Core is MPLS Frame-mode**
** ****LLQ on MPLS packets**
** ****WRED based on EXP**
** ****No need for inbound policy in Core**
**LLQ for Min B/W guarantee**
**Unmanaged CE example shown**

**P**

**P**

**FR Link**

**FR Link**

## Relationship between MPLS TE and MPLS Diff-Serv

**Diff-Serv specified ****independently**** of Routing/Path Computation**
**MPLS Diff-Serv (RFC3270) specified ****independently**** of Routing/Path Computation **
**MPLS TE designed as tool to improve backbone efficiency ****independently**** of QoS:**
** ****MPLS TE compute routes for aggregates across all Classes**
** ****MPLS TE performs admission control over “global” bandwidth pool for all Classes ****(i.e., unaware of bandwidth allocated to each queue)**
**MPLS TE and MPLS Diff-Serv:**
** ****can run simultaneously**
** ****can provide their own benefit (ie TE distributes aggregate load, Diff-Serv provides differentiation)**
** ****are unaware of each other ****(TE cannot provide its benefit on **_**a per class basis**_** such as CAC and constraint based routing)**

## MPLS TE with Best Effort Network

**Find Route and Set-Up Tunnel for ****20 Mb/s (Aggregate) From POP1 to POP4**

**Find Route and Set-Up Tunnel for ****10 Mb/s (Aggregate) From POP2 to POP4**

**CORE**

**POP 4**

**POP**

**POP**

**POP**

**POP 2**

**POP 1**

## MPLS TE with DiffServ Network

**CORE**

**POP 4**

**POP**

**POP**

**POP**

**POP 2**

**POP 1**

**MPLS TE with **_**DiffServ**_** Network**

**Find Route and Set-Up Tunnel for****20 Mb/s (Aggregate) From POP1**
** ****to POP4**

**Find Route and Set-Up Tunnel for ****10 Mb/s (Aggregate) From POP2**
** ****to POP4**

## DiffServ aware Traffic Engineering (DS-TE)

**DS-TE is more than MPLS TE + MPLS DiffServ**
**DS-TE makes MPLS TE aware of DiffServ:**
** ****DS-TE establishes **_**separate**_** tunnels for **_**different**_** classes**
** ****DS-TE takes into account the “bandwidth” available to each class (e.g. to queue) **
** ****DS-TE takes into account separate engineering constraints for each class**
** ****e.g. *****I want to limit Voice traffic to 70% of link max, but I don’t mind having up to 100% of BE traffic*****.**
** ****e.g *****I want overbook ratio of 1 for voice but 3 for BE***
**DS-TE ensures specific QoS level of **_**each**_** DiffServ class is achieved**

## DS-TE Configuration ExampleTunnel Midpoint

- !
- class-map match-all PREMIUM
-  match mpls experimental 5
- !
- class-map match-all BUSINESS
-   match mpls experimental 3 4
- !
- policy-map OUT-POLICY
-   **class GOLD**
**    ****priority ****16384**
-   class SILVER
-     bandwidth 65536
-     random-detect
-   class class-default
-     random-detect
- !
- interface POS1/0
-  ip address 10.150.1.1 255.255.255.0
-  **ip rsvp bandwidth 155000 155000 sub-pool ****16384**
-  service-policy output OUT-POLICY
** **mpls traffic-eng tunnels
-  mpls ip
- !

**Bandwidth**
**Allocation**

## MPLS DS-TE with DiffServ Network

**CORE**

**POP 4**

**POP**

**POP**

**POP**

**POP 1**

**MPLS DS-TE with DiffServ Network**

**Find Route and Set-Up Tunnel for ****5 Mb/s**** ****of EF**** ****From POP1 to POP4**

**Find Route and Set-Up Tunnel for**
**3 Mb/s**** ****of EF**** ****From POP2 to POP4**

**Find Route and Set-Up ****Tunnel for 15 Mb/s ****of BE****From POP1 to POP4**

**Find Route and Set-Up Tunnel for ****7 Mb/s ****of BE**** ****From POP2 to POP4**

**POP 2**

## MPLS QoS Applicationsfor Multi-Service

## MPLS QoS Applications for Multi-Service

**MPLS QoS General**
**MPLS Diffserv**
**MPLS TE**
**MPLS FRR (applies to strict QoS)**
**Diffserv-TE (DS-TE)**
**Combination = Guaranteed Bandwidth Services**
**Applications**
**	****Voice Trunking over TE**
**	****Virtual Leased Line Services**

## Solution 1: Toll Bypass with Voice Network

**Solution 1: Toll Bypass with Voice Network**

**PE**

**PBX with Packet Interface**

**PBX with Packet Interface**

**PSTN – Traditional TDM Network**

**Traditional Phone**

**Traditional Phone**

**Toll Bypass**

**QoS on PE Router**

_***Solution Requirements ***_

**Mapping Traffic to Tunnels**

**TE or **
**DS-TE**

**QoS on Core Routers**

**PE**

**TE Tunnel**

**+**

**+**

**+**

****

## Solution 2: Toll Bypass with Voice/Data Converged Network

**Solution 2: Toll Bypass with Voice/Data Converged Network**

**PE**

**CE**

**PSTN – Traditional TDM Network**

**Enterprise LAN**

**Enterprise LAN**

**Toll Bypass**

**QoS on PE Router**

_***Solution Requirements ***_

**Mapping Traffic to Tunnels**

**TE or**
**DS-TE**

**QoS on Core Routers**

**CE**

**QoS on CE Router**

**PE**

**TE Tunnel**

**PBX with Circuit Emulation Interface**

**+**

**+**

**+**

**+**

****

## Solution 3: Virtual Leased Lines – ATM Networks Using AToM

**Solution 3: Virtual Leased Lines – ATM Networks Using AToM**

**PE**

**MPLS Backbone**

**PE**

**ATM**

**CPE Router**

**ATM**

**CPE Router**

**ATM Virtual Circuits**

**Any Transport over MPLS (AToM) Tunnel **

**DS-TE Tunnel**

**Virtual Leased Line (DS-TE + QoS)**

***TE Tunnel Selection for AToM Attachment VCs***

**Two different requirements for the transport of **_**ATM**_** across an MPLS backbone**
- Transport of AAL5 encapsulated frames (RFC1483);
- Transport of ATM cells (cell relay)

**Future QoS Mapping: L2********IP********EXP**

## DS- TE   -   Standardization - IETF

**Standardization effort initiated by Cisco mid 2000**
**Now major work item of TEWG with broad support from SPs & vendors**
**DS-TE Requirements: on its way to RFC (IETF Last Call)**
**draft-ietf-tewg-diff-te-reqts-06.txt**
**DS-TE Protocol Extensions: Working Group document**
**Draft-ietf-tewg-diff-te-proto-02.txt**
**Consensus on protocol extensions **
**Selection of Bandwidth Constraints model still under discussion**
**Uses the Russian Dolls Bandwidth Constraint Model**

## IPv6 over MPLS(6PE/6VPE) 

## MPLS as a Foundation for Services

**VPNs**

**MPLS**

**Traffic **
**Engineering**

**QoS/**
**Tight**
**SLA’s**

**Network Infrastructure**

**GMPLS**

**Any **
**Transport **
**Over MPLS**

## IPv6 Edge Router (6PE) over MPLS

**144.254.0.0**

**2001:0421::**

**2001:0420::**

**P**

**P**

**P**

**P**

**6PE**

**6PE**

**IPv4**

**IPv6**

**IPv6**

**1****92.76.170****.0**

**1****34.95.0.0**

**2001:0621::**

**IPv4**

**6PE**

**6P****E**

**IPv4**

**IPv6**

**2001:0620::**

**IPv6**

**MP-iBGP sessions**

**v6**

**v6**

**v6**

**v6**

**v4**

**v4**

**v4**

** ****Many Carriers, large ISP and Mobile SP have invested on MPLS infrastructure**
** ****Core devices may be ATM switches, GSR or other vendor’s routers**
** ****Leverages MPLS features, eg. MPLS/VPN, TE, CoS,...**
**Multiple implementation’s options to integrate IPv6**
** *****IPv6 on CE, IPv6 over AToM, IPv6 Edge router (6PE),***** native IPv6 MPLS**
** ****6PE allows the SP to offer IPv6 at lower cost and risk**

**OC48/192**

## IPv6 VPN Provider Edge Router:   6VPE

**V6 and v4**

**V6 and V4**

**V6 and v4**

**CE**

**CE**

**6VPE**

**6VPE**

**6VPE**

**6VPE**

**192.254.10.0**

**2001:0421::**

**2001:0420::**

**1****92.76.10****.0**

**1****45.95.0.0**

**2001:0621::**

**2001:0620::**

**CE**

**IPv6 VPN Provider Edge Router:   6VPE**

**IPv4**
**MPLS**

**V6 and v4**

**1****45.96.0.0**

**Dual Stack IPv4-IPv6 routers**

**Dual Stack IPv4-IPv6 routers**

**For VPN customers (RFC 2547bis), IPv6 VPN service is exactly the same as IPv4 VPN service**
**IPv6 packets transported from 6VPE to 6VPE inside IPv4 LSP’s (IPv4 Core)**
**For ISP offering MPLS/VPN for IPv4 that wish to add IPv6 services as well**
**	****- No modification on the MPLS core**
**	****- Support both IPv4 and IPv6 VPN’s concurrently on the same interfaces**
**	****- Configuration and operations of IPv6 VPN’s exactly like IPv4 VPN’s**

## Generalized MPLS (GMPLS)

**Reduces the multiple layers into a single, integrated, control layer **
**Extends MPLS control plane to address optical layer constraints and attributes**
**Leverages IP layer management simplicity and distributed intelligence**
**Provides sophisticated traffic engineering capabilities for resource management and control**

## UCP GMPLS Phase 4Integrated IP+Optical Intelligence

**IP+Optical**

- GMPLS-Based Standard NNI
- Single MPLS and GMPLS IP+Optical Control Plane

- Concurrent Peer and UNI Overlay Operation
- Topology Visibility for Coordinated Routing and Restoration
- Advanced Smart BW Services

**Metro**
**Multi-Service**
**OTN**

**Metro**
**Multi-Service**
**OTN**

**Router**

**Router**

**UNI**

**Management Plane**

**GMPLS Enabled Control Plane**

## Summary

**MPLS is much more than label switching**
**MPLS allows an IP infrastructure to be “Service Enabled”**
**Allows the SP/Enterprise to offer multiple Services across a **_**single**_** infrastructure**
**AToM allows layer-2 transport across an MPLS infrastructure**
**Combining TE, TE-FRR, and DS-TE, allows very tight SLA’s offerings with high-availability for low-latency applications (e.g. Voice and Virtual Leased Line)**
**MPLS Services will continue to evolve and allow the integration of more Services across a single infrastructure**

## MPLS Further Reading

## Further Reading - Books

**Books**
**MPLS: Technology and Applications****                                                                 by Bruce S. Davie, Yakov Rekhter    ISBN: 1558606564**
**Traffic Engineering with MPLS****                                                                                               by Eric Osborne, Ajay Simha    ISBN: 1587050315**
**MPLS and VPN Architectures, Volume I****                                                                               by Ivan Pepelnjak, Jim Guichard    ISBN: 1587050811**
**MPLS and VPN Architectures, Volume II****                                                                               by Ivan Pepelnjak, Jim Guichard, Jeff Apcar    ISBN: 1587051125**
**Advanced MPLS Design and Implementation****                                                   by Vivek Alwayn    ISBN: 158705020X**

## MPLS Links

**Link to MPLS Home Page (CCO):**
**	**_**[http://www.cisco.com/warp/public/732/Tech/mpls/](http://www.cisco.com/warp/public/732/Tech/mpls/)**_
**MPLS Technical Documents (CCO):**
**	**_**[http://www.cisco.com/warp/public/732/Tech/mpls/mpls_techdoc.shtml](http://www.cisco.com/warp/public/732/Tech/mpls/mpls_techdoc.shtml)**_
**Link to Tunnel Builder Home Page:**
**	**_**[http://www.cisco.com/warp/public/732/Tech/mpls/tb/](http://www.cisco.com/warp/public/732/Tech/mpls/tb/)**_
**Link to MPLS Working Group Page (IETF):**
**	**_**[http://www.ietf.org/html.charters/mpls-charter.html](http://www.ietf.org/html.charters/mpls-charter.html)**_

## Select MPLS RFCs

**Requirements for ****Traffic Engineering**** over MPLS (RFC 2702) **
**Multiprotocol Label Switching ****Architecture**** (RFC 3031)**
**MPLS ****Label Stack**** Encoding (RFC 3032)**
**MPLS using LDP and ****ATM**** VC Switching (RFC 3035)**
**LDP**** Specification (RFC 3036)**
**Carrying Label Information in ****BGP****-4 (RFC 3107)**
**RSVP-TE****: Extensions to RSVP for LSP Tunnels (RFC 3209)**
**MPLS Support of ****Differentiated Services**** (RFC 3270)**
**MPLS/BGP ****VPNs**** (RFC 2547 – Informational, ***** de facto *****standard)**

**All but the first have one or more Cisco co-authors**

## MPLS Links

**Link to MPLS Home Page (CCO):**
**	**_**[http://www.cisco.com/warp/public/732/Tech/mpls/](http://www.cisco.com/warp/public/732/Tech/mpls/)**_
**MPLS Technical Documents (CCO):**
**	**_**[http://www.cisco.com/warp/public/732/Tech/mpls/mpls_techdoc.shtml](http://www.cisco.com/warp/public/732/Tech/mpls/mpls_techdoc.shtml)**_
**Link to Tunnel Builder Home Page:**
**	**_**[http://www.cisco.com/warp/public/732/Tech/mpls/tb/](http://www.cisco.com/warp/public/732/Tech/mpls/tb/)**_
**Link to MPLS Working Group Page (IETF):**
**	**_**[http://www.ietf.org/html.charters/mpls-charter.html](http://www.ietf.org/html.charters/mpls-charter.html)**_

## Presentation_ID

- © 2001, Cisco Systems, Inc. All rights reserved.

## Backup Slides

## Terminology, 1/2

**RR****—****Route Reflector**
**A router (usually not involved in packet forwarding) that distributes BGP routes within a provider’s network**
**PE****—****Provider Edge router**
**The interface between the customer and the MPLS-VPN network; only PEs (and maybe RRs) know anything about MPLS-VPN routes**
**P****—****Provider router**
**A router in the core of the MPLS-VPN network, speaks LDP/RSVP but not VPNv4**
**CE****—****Customer Edge router**
**The customer router which connects to the PE; does not know  anything about labels, only IP (most of the time)**
**LDP****—****Label Distribution Protocol**
**Distributes labels with a provider’s network that mirror the IGP, one way to get from one PE to another**
**LSP****—****Label Switched Path**
**The chain of labels that are swapped at each hop to get from one PE to another**

## Terminology, 2/2

**VPN****—****Virtual Private Network**
**A network deployed on top of another network, where the two networks are separate and never communicate**
**VRF****—****Virtual Routing and Forwarding instance**
**Mechanism in IOS used to build per-interface RIB and FIB**
**VPNv4**
**Address family used in BGP to carry MPLS-VPN routes**
**RD**
**Route Distinguisher, used to uniquely identify the same network/mask from different VRFs (i.e., 10.0.0.0/8 from VPN A and 10.0.0.0/8 from VPN B)**
**RT**
**Route Target, used to control import and export policies, to build arbitrary VPN topologies for customers**