1. ECSE-6660 Label Switching and MPLS Or
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
Based in part on slides from Prof. Raj Jain (OSU) ,
Kireeti Kompella, Juniper networks,
Peter Ashwood-Smith and Bilel Jamoussi (Nortel Networks),

2. Overview IP-over-ATM to MPLS: History of IP Switching
MPLS: generalization of labels, de-coupling of control plane
Label distribution/setup protocols: RSVP, LDP
Introduction to Traffic Engineering

3. IP: “Best-Effort Philosophy”
Well architected, not necessarily worked out in detail
Realization: can’t predict the future
Architectural decisions:
Make it reasonable
Make it flexible
Make it extensible
stuff above
transport
network
stuff below

4. IP Control Plane Evolution
Again, just good enough (best-effort) …
But again, flexible, extensible
Distance Vector routing was fine for quite a while
Just in time, along came link state (OSPF and IS-IS)
Now a burning question in OSPF/IS-IS is:
Convergence “in a few seconds” is not good enough?
See NANOG June 2002 for interesting videos and papers on how to fix LS-routing for fast convergence
Goal: “Business” IP for service providers…
Make me money – new services, GoS
Don’t lose me money – uptime, SLAs
OSPF/BGP not originally designed to support QoS or multiple services (eg: VoIP, VPNs)

5. ATM – Perfectionist’s Dream
Connection-oriented
Does everything and does it well
Anticipated all future uses and factored them in
Philosophical mismatch with IP
AAL 3/4
AAL 2
AAL 1
AAL 5
stuff above
transport
network
ATM

6. Overlay Model for IP-over-ATM Internetworking
Goal: Run IP over ATM core networks
Why? ATM switches offered performance, predictable behavior and services (CBR, VBR, GFR…)
ISPs created “overlay” networks that presented a virtual topology to the edge routers in their network
Using ATM virtual circuits, the virtual network could be reengineered without changing the physical network
Benefits
Full traffic control
Per-circuit statistics
More balanced flow of traffic across links
Asynchronous Transfer Mode (ATM) switches offered a solution when ISPs required more bandwidth to handle increasing traffic loads. The ISPs who migrated to ATM-based cores discovered that ATM permanent virtual circuits (PVCs) offered precise control over traffic flow across their networks. ISPs came to rely on the high-speed interfaces, deterministic performance, and PVC functionality that ATM switches provided.
Around 1994 or 1995, Internet traffic became so high that ISPs had to migrate their networks to support trunks that were larger than T3 (45 Mbps). Fortunately, OC-3 ATM interfaces (155 Mbps) became available for switches and routers. To obtain the required speed, ISPs had to redesign their networks so that they could use higher speeds supported by a switched core.
An ATM-based core fully supports traffic engineering because it can explicitly map PVCs. Mapping PVCs is done by provisioning an arbitrary virtual topology on top of the network's physical topology. PVCs are mapped from edge to edge to precisely distribute traffic across all links so that they are evenly utilized. This approach eliminates the traffic-magnet effect of least-cost routing, which results in overutilized and underutilized links. The traffic engineering capabilities supported by ATM PVCs made the ISPs more competitive within their market, so they could provide better service to their customers at a lower cost.
Per-PVC statistics provided by the ATM switches facilitate monitoring traffic patterns for optimal PVC placement and management. Network designers initially provision each PVC to support specific traffic engineering objectives, and then they constantly monitor the traffic load on each PVC. If a given PVC begins to experience congestion, the ISP has the information it needs to remedy the situation by modifying either the virtual or physical topology to accommodate shifting traffic loads.

7. Overlay Model (Contd) ATM core ringed by routers
PVCs overlaid onto physical network A
Physical
View B C
In an ATM overlay network, routers surround the edge of the ATM cloud. Each router communicates with every other router by a set of PVCs that are configured across the ATM physical topology. The PVCs function as logical circuits, providing connectivity between edge routers. The routers do not have direct access to information describing the physical topology of the underlying ATM infrastructure. The routers have knowledge only of the individual PVCs that appear to them as simple point-to-point circuits between two routers. The illustration above shows how the physical topology of an ATM core differs from the logical IP overlay topology.
The distinct ATM and IP networks “meet” when the ATM PVCs are mapped to router logical interfaces. Logical interfaces on a router are associated with ATM PVCs, and then the routing protocol works to associate IP prefixes (routes) with the subinterfaces.
Finally, ATM PVCs are integrated into the IP network by running the IGP across each of the PVCs to establish peer relationships and exchange routing information. Between any two routers, the IGP metric for the primary PVC is set such that it is more preferred than the backup PVC. This guarantees that the backup PVC is used only when the primary PVC is not available. Also, if the primary PVC becomes available after an outage, traffic automatically returns to the primary PVC from the backup. A
Logical
View C B

8. Issue 1: Mapping IP data-plane to ATM: Address Resolution Woes!
A variety of server-based address resolution servers:
ATMARP (RFC 1577), LANE server, BUS server, MPOA server, NHRP server….
Use of separate pt-pt and pt-mpt VCs with servers
Multiple servers + backup VCs to them needed for fault tolerance
Separate servers needed in every LOGICAL domain (eg: LIS)
Mismatch between the notion of IP subnet and ATM network sizing
Cut-through forwarding between nodes on same ATM network hard to achieve!

9. Issue 2: Mapping IP control-plane (eg: OSPF) to ATM
Basic OSPF assumes that subnets are pt-pt or offer broadcast capability.
ATM is a Non-Broadcast Multiple Access (NBMA) media
NBMA “segments” support multiple “routers” with pt-pt VCs but do not support data-link broadcast/mcast capability
Each VC is costly => setting up full mesh for OSPF Hello messages is prohibitively expensive!
Two “flooding adjacency” models in OSPF:
Non-Broadcast Multiple Access (NBMA) model
Point-to-Multipoint (pt-mpt) Model
Different tradeoffs…

10. Partial Mesh: NBMA model
1. Neighbor discovery: manually configured
2. Dijkstra SPF views NBMA as a full mesh!

11. Partial Mesh: pt-mpt model

12. NBMA vs Pt-Mpt Subnet Model
Key assumption in NBMA model:
Each router on the subnet can communicate with every other (same as IP subnetmodel)
But this requires a “full mesh” of expensive PVCs at the lower layer!
Many organizations have a hub-and-spoke PVC setup, a.k.a. “partial mesh”
Conversion into NBMA model requires multiple IP subnets, and complex configuration (see fig on next slide)
OSPF’s pt-mpt subnet model breaks the rule that two routers on the same network must be able to talk directly
Can turn partial PVC mesh into a single IP subnet

13. OSPF Designated Routers (DRs): NBMA Case
Instead of sending a separate router-LSA for each router,
one “designated router” can create a network-LSA
for the subnet

14. OSPF Designated Router (DR): NBMA Case
One router elected as a designated router (DR)
Each router in subnet maintains “flooding adjacency” with the DR, I.e., sends acks of LSAs to DR
DR informs each router of other routers on LAN
DR generates the network-LSA on subnet’s behalf after synchronizing with all routers
Complex election protocol for DR in case of failure

15. DR and BDR in OSPF NBMA model
In NBMA model:
DR and BDR only maintain VCs and Hellos with all routers on NBMA
Flooding in NBMA always goes through DR
Multicast not available to optimize LSA flooding.
DR generates network-LSA

16. Summary: IP-to-ATM Overlay Model Drawbacks
IP-to-ATM: control-plane mapping issues
Need a full mesh of ATM PVCs for mapping IP routing
Both NBMA and Pt-Mpt mapping models have drawbacks
IP-to-ATM: data-plane mapping issues
Address resolution (eg: LANE, RFC 1577, MPOA, NHRP) requires a complex distributed server and multicast VC infrastructure
Segmentation-and-Reassembly (SAR) of IP packets into ATM cells can have a multiplier-effect on performance even if one cell in a packet is lost
ATM SAR has trouble scaling to OC-48 and OC-192 speeds
Packet-over-SONET (POS) emerged as an alternative at the link layer
ATM + AAL5 overhead (20%) deemed excessive
A network that deploys a full mesh of ATM PVCs exhibits the traditional “n- squared” problem. For relatively small or moderately sized networks, this is not a major issue. But for core ISPs with hundreds of attached routers, the challenge can be quite significant. For example, when expanding a network from five to six routers, an ISP must increase the number of simplex PVCs from 20 to 30. However, increasing the number of attached routers from 200 to requires the addition of 400 new simplex PVCs—an increase from 39,800 to 40,200 PVCs. These numbers do not include backup PVCs or additional PVCs for networks running multiple services that require more than one PVC between any two routers.
A number of operational challenges are caused by the "n-squared" problem:
New PVCs must be mapped over the physical topology
New PVCs must be tuned so that they have minimal impact on existing PVCs
The large number of PVCs might exceed the configuration and implementation capabilities of the ATM switches
The configuration of each switch and router in the core must be modified
Deploying a full mesh of PVCs also stresses the IGP. This stress results from the number of peer relationships that must be maintained, the challenge of processing "n-cubed" link-state updates in the event of a failure, and the complexity of performing the Dijkstra calculation over a topology containing a significant number of logical links. Any time the topology results in a full mesh, the impact on the IGP is a suboptimal topology that is extremely difficult to maintain. As an ATM core expands, the "n-squared" stress on the IGP compounds.

17. Re-examining Basics: Routing vs Switching

18. IP Routing vs IP Switching

19. MPLS: Best of Both Worlds
PACKET ROUTING
CIRCUIT SWITCHING
HYBRID IP
MPLS+IP
ATM
TDM
Caveat: one cares about combining the best of both worlds
only for large ISP networks that need both features!
Note: the “hybrid” also happens to be a solution that bypasses IP-over-ATM mapping woes!

20. History: Ipsilon’s IP Switching: Concept
Hybrid: IP routing (control plane) +
ATM switching (data plane)

21. Ipsilon’s IP Switching
ATM VCs setup when new IP “flows” seen, I.e.,
“data-driven” VC setup

22. Issues with Ipsilon’s IP switching

23. Tag Switching Key difference: tags can be setup in the background
using IP routing protocols (I.e. control-driven VC setup)

24. Alphabet Soup! MPLS working group in IETF was formed to reach a
common standard

25. MPLS Broad Concept: Route at Edge, Switch in CoreIP IP
#L1 IP
#L2 IP
#L3 IP
IP Forwarding
LABEL SWITCHING
IP Forwarding

26. MPLS Terminology LDP: Label Distribution Protocol
LSP: Label Switched Path
FEC: Forwarding Equivalence Class
LSR: Label Switching Router
LER: Label Edge Router (Useful term not in standards)
MPLS is “multi-protocol” both in terms of the protocols it supports ABOVE it and BELOW it in the protocol stack!

27. MPLS Header IP packet is encapsulated in MPLS header and sent down LSP
IP packet is restored at end of LSP by egress router
TTL is adjusted by default …
IP Packet
32-bit
MPLS Header
MPLS is responsible for directing a flow of IP packets along a predetermined path across a network. This path is called a label-switched path. Label-switched paths are similar to ATM PVCs in that they are simplex in nature; that is, the traffic flows in one direction from the ingress router to a egress router. Duplex traffic requires two label-switched paths; that is, one path to carry traffic in each direction. A label-switched path is created by the concatenation of one or more label-switched hops, allowing a packet to be forwarded from one label-switching router to another label-switching router across the MPLS domain. A label-switching router is a router that supports MPLS-based forwarding.
When an IP packet enters a label-switched path, the ingress router examines the packet and assigns it a label based on its destination, placing the label in the packet’s header. The label transforms the packet from one that is forwarded based on its IP routing information to one that is forwarded based on information associated with the label. The packet is then forwarded to the next router in the label-switched path. The key point in this scheme is that the physical path of the LSP is not limited to what the IGP would choose as the shortest path to reach the destination IP address.

28. MPLS Label Stack Concept
Allows nested tunnels, that are opaque, I.e. do not know or
care what protocol data they carry (a.k.a multi-protocol)

29. MPLS Header Label Used to match packet to LSP Experimental bits
TTL
Label
Used to match packet to LSP
Experimental bits
Carries packet queuing priority (CoS)
Stacking bit: can build “stacks” of labels
Goal: nested tunnels!
Time to live
Copied from IP TTL
An MPLS header consists of:
20-bit label—Used to identify the packet to a particular LSP
Class of service value—Indicates queuing priority through the network. At each hop along the way, the class of service value determines which packets receive preferential treatment within the tunnel.
Stacking bit—Indicates that this MPLS packet has more than one label associated with it. The MPLS implementation in JUNOS Software supports a stacking depth of one.
Time to live value—Contains a limit on the number of router “hops” this MPLS packet may travel through the network. It is decremented at each hop, and if the TTL value drops below one, the packet is discarded.

30. Multi-protocol operation
The abstract notion of a “label” can be mapped to multiple circuit- or VC-oriented technologies!
ATM - label is called VPI/VCI and travels with cell.
Frame Relay - label is called a DLCI and travels with frame.
TDM - label is called a timeslot its implied, like a lane.
X25 - a label is an LCN
Proprietary labels: TAG (in tag switching) etc..
Frequency or Wavelength substitution where “label” is a light frequency/wavelength? (idea in G-MPLS)

31. Label Encapsulation ATM FR Ethernet PPP VPI VCI DLCI “Shim Label”
IP | PAYLOAD
MPLS Encapsulation is specified over various media types. Top labels may use existing format, lower label(s) use a new “shim” label format.

32. MPLS Encapsulation - ATM
ATM LSR constrained by the cell format imposed by existing ATM standards
5 Octets
ATM Header
Format
VPI
VCI PT
CLP
HEC
Option 1
Label
Label
Option 2
Combined Label
Option 3
ATM VPI (Tunnel)
Label
AAL 5 PDU Frame (nx48 bytes) n
••• 1
Network Layer Header
and Packet (eg. IP)
ATM
SAR
Generic Label Encap.
(PPP/LAN format)
AAL5 Trailer
48 Bytes
ATM Header
48 Bytes
• • •
ATM Payload
Top 1 or 2 labels are contained in the VPI/VCI fields of ATM header
- one in each or single label in combined field, negotiated by LDP
Further fields in stack are encoded with ‘shim’ header in PPP/LAN format
- must be at least one, with bottom label distinguished with ‘explicit NULL’
TTL is carried in top label in stack, as a proxy for ATM header (that lacks TTL)

33. MPLS Encapsulation - Frame Relay
Q.922
Header
Generic Encap.
(PPP/LAN Format)
Layer 3 Header and Packet n
••• 1 C/ R E A FE CN BE CN D E E A
DLCI Size = 10, 17, 23 Bits
DLCI
DLCI
Current label value carried in DLCI field of Frame Relay header
Can use either 2 or 4 octet Q.922 Address (10, 17, 23 bytes)
Generic encapsulation contains n labels for stack of depth n
- top label contains TTL (which FR header lacks), ‘explicit NULL’ label value

34. MPLS Encapsulation: PPP & LAN Data Links
MPLS ‘Shim’ Headers (1-n) n
••• 1
Layer 2 Header
(eg. PPP, 802.3)
Network Layer Header
and Packet (eg. IP)
4 Octets
Label Stack
Entry Format
Label
Exp. S
TTL
Label: Label Value, 20 bits (0-16 reserved)
Exp.: Experimental, 3 bits (was Class of Service)
S: Bottom of Stack, 1 bit (1 = last entry in label stack)
TTL: Time to Live, 8 bits
Network layer must be inferable from value of bottom label of the stack
TTL must be set to the value of the IP TTL field when packet is first labelled
When last label is popped off stack, MPLS TTL to be copied to IP TTL field
Pushing multiple labels may cause length of frame to exceed layer-2 MTU
- LSR must support “Max. IP Datagram Size for Labelling” parameter
- any unlabelled datagram greater in size than this parameter is to be fragmented
MPLS on PPP links and LANs uses ‘Shim’ Header Inserted
Between Layer 2 and Layer 3 Headers

35. MPLS Forwarding: Example
An IP packet destined to /32 arrives in SF
San Francisco has route for /16
Next hop is the LSP to New York
/16 IP
New York
San
Francisco
1965
1026
Santa Fe

36. MPLS Forwarding Example
San Francisco pre-pends MPLS header onto IP packet and sends packet to first transit router in the path
/16
New York
San
Francisco IP
1965
Santa Fe

37. MPLS Forwarding Example
Because the packet arrived at Santa Fe with an MPLS header, Santa Fe forwards it using the MPLS forwarding table
MPLS forwarding table derived from mpls.0 switching table
/16
New York
San
Francisco IP
1026
Santa Fe

38. MPLS Forwarding Example
Packet arrives from penultimate router with label 0
Egress router sees label 0 and strips MPLS header
Egress router performs standard IP forwarding decision IP
/16
New York
Labels 0 through 15 are reserved labels, as specified in draft-ietf-mpls-label-encaps-07.txt.
A value of 0 represents the "IPv4 Explicit NULL Label". This label value is only legal when it is the sole label stack entry. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv4 header.
A value of 1 represents the "Router Alert Label". This label value is legal anywhere in the label stack except at the bottom. When a received packet contains this label value at the top of the label stack, it is delivered to a local software module for processing. The actual forwarding of the packet is determined by the label beneath it in the stack. However, if the packet is forwarded further, the Router Alert Label should be pushed back onto the label stack before forwarding. The use of this label is analogous to the use of the "Router Alert Option" in IP packets. Since this label cannot occur at the bottom of the stack, it is not associated with a particular network layer protocol.
A value of 2 represents the "IPv6 Explicit NULL Label".This label value is only legal when it is the sole label stack entry. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv6 header.
A value of 3 represents the "Implicit NULL Label". This is a label that an LSR may assign and distribute, but which never actually appears in the encapsulation. When an LSR would otherwise replace the label at the top of the stack with a new label, but the new label is "Implicit NULL", the LSR will pop the stack instead of doing the replacement. Although this value may never appear in the encapsulation, it needs to be specified in the Label Distribution Protocol, so a value is reserved.
Values 4-15 are reserved for future use. IP
San
Francisco
Santa Fe

39. Label Setup/Signaling: MPLS Using IP Routing Protocols
47.1
47.2
47.3 1 2 3
Destination based forwarding tables as built by OSPF, IS-IS, RIP, etc.

40. Regular IP Forwarding 1
47.1 IP 1 2 IP 3 2 IP 1 3
47.2
47.3 2 IP
IP destination address unchanged in packet header!

41. MPLS Label Distribution1
47.1 3
Request: 47.1 3
Request: 47.1 2 1
Mapping: 0.40 1 2
Mapping: 0.50
47.3 3
47.2 2

42. Label Switched Path (LSP)IP 1
47.1 3 3 2 1 1 2
47.3 3
47.2 2 IP

43. A General Vanilla LSP
#963
#14
#99
#311
#216
#14
#963
#612
#311
#462
#99 #5
- A Vanilla LSP is actually part of a tree from every source to that destination (unidirectional).
- Vanilla LDP builds that tree using existing IP forwarding tables to route the control messages.

44. Explicitly Routed (ER-) LSP
Route= {A,B,C}
#14
#972
#216 B
#14
#972 C A
#462
ER-LSP follows route that source chooses. In other words, the control message to establish the LSP (label request) is source routed.

45. Explicitly Routed (ER-) LSP ContdIP 1
47.1 3 3 2 1 1 2
47.3 3
47.2 2 IP

46. ER LSP - advantages
Operator has routing flexibility (policy-based, QoS-based)
Can use routes other than shortest path
Can compute routes based on constraints in exactly the same manner as ATM based on distributed topology database. (traffic engineering)

47. ER LSP - discord!
Two signaling options proposed in the standards: CR-LDP, RSVP extensions:
CR-LDP = LDP + Explicit Route
RSVP ext = Traditional RSVP + Explicit Route Scalability Extensions
Not going to be resolved any time soon, market will probably have to resolve it.

48. Traffic Engineering
TE: “…that aspect of Internet network engineering dealing with the issue of performance evaluation and performance optimization of operational IP networks …’’
Two abstract sub-problems:
1. Define a traffic aggregate (eg: OC- or T-carrier hierarchy, or ATM PVCs)
2. Map the traffic aggregate to an explicitly setup path
Cannot do this in OSPF or BGP-4 today!
OSPF and BGP-4 offer only a SINGLE path! A B C D 1 2 4 E
Links AC and CD are overloaded A B C D 1 2 E
Can not do this with OSPF A B C D 1 2 E
Links AB and BD are overloaded

49. Why not TE with OSPF/BGP?
Internet connectionless routing protocols designed to find only one route (path)
The “connectionless” approach to TE is to “tweak” (I.e. change) link weights in IGP (OSPF, IS-IS) or EGP (BGP-4) protocols
Assumptions: Quasi-static traffic, knowledge of demand matrix
Limitations:
Performance is fundamentally limited by the single shortest/policy path nature:
All flows to a destination prefix mapped to the same path
Desire to map traffic to different route (eg: for load-balancing reasons) => the single default route MUST be changed
Changing parameters (eg: OSPF link weights) changes routes AND changes the traffic mapped to the routes
Leads to extra control traffic (eg: OSPF floods or BGP-4 update message), convergence problems and routing instability!
Summary: Traffic mapping coupled with route availability in OSPF/BGP!
MPLS de-couples traffic trunking from path setup

50. Traffic Engineering w/ MPLS (Step I)
Engineer unidirectional paths through your network without using the IGP’s shortest path calculation
IGP shortest path
New York
In the traditional layer 3 forwarding paradigm, as a packet travels from one router to the next an independent forwarding decision is made at each hop. The IP network-layer header is analyzed and the next hop is chosen based on this analysis and on the information in the routing table.
In the JUNOS traffic engineering environment, the analysis of the packet header is performed just once—right before the packet enters the engineered path. The packet is assigned a label, which is a short, fixed-length value placed at the front of the packet. Routers in the traffic engineering path use labels as lookup indicies into the label forwarding table. For each label, this table stores forwarding information such as the router interface for which a labeled packet should be forwarded.
San
Francisco
traffic engineered path

51. Traffic Engineering w/ MPLS (Part II)
IP prefixes (or traffic aggregates) can now be bound to MPLE Label Switched Paths (LSPs)
/24
New York
San
Francisco
/16

52. Traffic Aggregates: Forwarding Equivalence Classes
LSR
LSR
LER
LER
LSP
IP1
IP2
IP1
IP2
IP1
#L1
IP2
IP1
#L2
IP2
IP1
#L3
IP2
Packets are destined for different address prefixes, but can be
mapped to common path
The “Forwarding Equivalence Class” is an important concept in MPLS. An FEC is any subset of packets that are treated the same way by a router. By “treated” this can mean, forwarded out the same interface with the same next hop and label. It can also mean given the same class of service, output on same queue, given same drop preference, and any other option available to the network operator.
When a packet enters the MPLS network at the ingress node, the packet is mapped into an FEC. The mapping can also be done on a wide variety of parameters, address prefix (or host), source/destination address pair, or ingress interface. This greater flexibility adds functionality to MPLS that is not available in traditional IP routing.
FECs also allow for greater scalability in MPLS. In Ipsilon’s implementation of IP Switching or in MPOA, their equivalent to an FEC maps to a data flow (source/destination address pair, or source/destination address plus port no.). The limited flexibility and large numbers of (short lived) flows in the Internet limits the applicability of both IP Switching and MPOA. With MPLS, the aggregation of flows into FECs of variable granularity provides scalability that meets the demands of the public Internet as well as enterprise applications.
In the current Label Distribution Protocol specification, only three types of FECs are specified:
- IP Address Prefix
- Router ID
- Flow (port, dest-addr, src-addr etc.)
The spec. states that new elements can be added as required.
FEC = “A subset of packets that are all treated the same way by a router”
The concept of FECs provides for a great deal of flexibility and scalability
In conventional routing, a packet is assigned to a FEC at each hop (i.e. L3 look-up), in MPLS it is only done once at the network ingress

53. Signaled TE Approach (eg: MPLS)
Features:
In MPLS, the choice of a route (and its setup) is orthogonal to the problem of traffic mapping onto a route
Signaling maps global IDs (addresses, path-specification) to local IDs (labels)
FEC mechanism for defining traffic aggregates, label stacking for multi-level opaque tunneling
Issues:
Requires extensive upgrades in the network
Hard to inter-network beyond area boundaries
Very hard to go beyond AS boundaries (even in same organization)
Impossible for inter-domain routing across multiple organizations => inter-domain TE has to be connectionless

54. Hop-by-Hop vs. Explicit Routing
Hop-by-Hop Routing
Explicit Routing
Distributes routing of control traffic
Builds a set of trees either fragment by fragment like a random fill, or backwards, or forwards in organized manner.
Reroute on failure impacted by convergence time of routing protocol
Existing routing protocols are destination prefix based
Difficult to perform traffic engineering, QoS-based routing
Source routing of control traffic
Builds a path from source to dest
Requires manual provisioning, or automated creation mechanisms.
LSPs can be ranked so some reroute very quickly and/or backup paths may be pre-provisioned for rapid restoration
Operator has routing flexibility (policy-based, QoS-based,
Adapts well to traffic engineering
Explicit routing shows great promise for traffic engineering

55. RSVP: “Resource reSerVation Protocol”
A generic QoS signaling protocol
An Internet control protocol
Uses IP as its network layer
Originally designed for host-to-host
Uses the IGP to determine paths
RSVP is not
A data transport protocol
A routing protocol
RFC 2205
The Resource Reservation Protocol (RSVP) is a generic signaling protocol that was originally designed to be used by applications to request and reserve specific Quality of Service (QoS) requirements across an internetwork. Resources are reserved hop-by-hop across the internetwork; each router receives the resource reservation request, establishes and maintains the necessary state for the data flow (if the requested resources are available), and forwards the resource reservation request to the next router along the path.
As this behavior implies, RSVP is an internetwork control protocol, similar to ICMP, IGMP, and routing protocols. It does not transport application data, nor is it a routing protocol. RSVP utilizes unicast ands multicast routing protocols to discover paths through the internetwork by consulting existing routing tables.
The present document describing RSVP is RFC 2205, Resource Reservation Protocol (RSVP)-- Version 1 Functional Specification.

56. Recall: Signaling ideas
Classic scheme: sender initiated
SETUP, SETUP_ACK, SETUP_RESPONSE
Admission control
Tentative resource reservation and confirmation
Simplex and duplex setup; no multicast support

57. RSVP: Internet Signaling
Creates and maintains distributed reservation state
De-coupled from routing & also to support IP multicast model:
Multicast trees setup by routing protocols, not RSVP (unlike ATM or telephony signaling)
Key features of RSVP:
Receiver-initiated: scales for multicast
Soft-state: reservation times out unless refreshed
Latest paths discovered through “PATH” messages (forward direction) and used by RESV mesgs (reverse direction).
Again dictated by needs of de-coupling from IP routing and to support IP multicast model

58. RSVP Path Signaling Example
Signaling protocol sets up path from San Francisco to New York, reserving bandwidth along the way
Seattle
New York
(Egress)
PATH
San
Francisco
(Ingress)
PATH
PATH
Miami

59. RSVP Path Signaling Example
Once path is established, signaling protocol assigns label numbers in reverse order from New York to San Francisco
Seattle
New York
(Egress)
RESV 3
San
Francisco
(Ingress)
1965
RESV
1026
RESV
Miami

60. Call Admission
Session must first declare its QOS requirement and characterize the traffic it will send through the network
R-spec: defines the QOS being requested
T-spec: defines the traffic characteristics
A signaling protocol is needed to carry the R-spec and T-spec to the routers where reservation is required; RSVP is a leading candidate for such signaling protocol

61. Call Admission
Call Admission: routers will admit calls based on their R-spec and T-spec and base on the current resource allocated at the routers to other calls.

62. Summary: Basic RSVP Path Signaling
Reservation for simplex (unidirectional) flows
Ingress router initiates connection
“Soft” state
Path and resources are maintained dynamically
Can change during the life of the RSVP session
Path message sent downstream
Resv message sent upstream
RSVP requests resources for simplex data flows. Each reservation is made for a data flow from a specific sender to a specific receiver. While RSVP messages are exchanged between the sender and receiver, the resulting path itself is unidirectional.
Although the application data flow is from the sender to the receiver, the reservation itself is receiver-initiated. The sender notifies the receiver of a pending flow and characterizes the flow, and the receiver is responsible for requesting the resources. This design choice was made to accommodate heterogeneous receiver requirements, and for multicast flows in which multiple receivers will be joining and leaving a multicast group.
RSVP requests made to routers along the transit path cause each router to either reject the request for lack of resources, or establish a soft state. This is in contrast to a hard state, which is associated with virtual connections that remain established for the duration of the data transfer. Soft state means that the logical path set up by RSVP is not necessarily associated with a physical path through the internetwork. The logical path may change during its lifetime as the result of the sender changing the characterization of the traffic, causing the receiver to modify its reservation request, or the failure of a transit router.
The soft state is maintained by refreshing the soft state periodically. In standard RSVP implementations, this is done by sending PATH and RESV messages across the path. JUNOS uses a “hello” protocol to maintain state and detect node failures; by default, hello messages are sent every 3 seconds. The hello protocol can detect state changes within seconds, instead of several minutes as with standard RSVP implementations. The hello protocol is fully backward-compatible with older RSVP implementations. If a neighboring node does not support hello messages, JUNOS RSVP uses standard soft-state procedures.
Sender
PATH
Router
PATH
RESV
Router
PATH
RESV
Receiver
RESV

63. MPLS Extensions to RSVP
Path and Resv message objects
Explicit Route Object (ERO)
Label Request Object
Label Object
Record Route Object
Session Attribute Object
Tspec Object
For more detail on contents of objects:
daft-ietf-mpls-rsvp-lsp-tunnel-04.txt
Extensions to RSVP for LSP Tunnels
RSVP has been extended for support of MPLS LSPs and Traffic Engineering. These extensions are documented in the Internet draft, Extensions to RSVP for LSP Tunnels, <draft-ietf-mpls-rsvp-lsp-tunnel-04.txt>, September 1999.

64. Explicit Route Object
Used to specify the explicit route RSVP Path messages take for setting up LSP
Can specify loose or strict routes
Loose routes rely on routing table to find destination
Strict routes specify the directly-connected next router
A route can have both loose and strict components
The Explicit Route Object (ERO)is added to an RSVP Path message by the ingress LSR to specify an explicit route for the message, independent of conventional IP routing. The ERO is only to be used when all routers along the explicit route support RSVP and the ERO. The ERO is also only intended to be used for unicast situations.

65. ERO: Strict Route Next hop must be directly connected to previous hop
Egress
LSR C E F
B strict;
C strict;
E strict;
D strict;
F strict;
ERO A B D
Ingress
LSR
Strict

66. ERO: Loose Route
Consult the routing table at each hop to determine the best path: similar to IP routing option concept
Egress
LSR C E F
D loose;
ERO A B D
Ingress
LSR
Loose

67. ERO: Strict/Loose Path
Strict and loose routes can be mixed
Egress
LSR C E F
C strict;
D loose;
F strict;
ERO A B D
Strict
Ingress
LSR
Loose

68. Label Objects Label Request Object
Added to PATH message at ingress LSR
Requests that each LSR provide label to upstream LSR
Label Object
Carried in RESV messages along return path upstream
Provides label to upstream LSR
The Label Request Object can be added to the PATH message by the ingress LSR to request that intermediate routers provide a label binding for the path. The object provides an indication of the network layer protocol that is to be carried over the path, permitting non-IP network layer protocols to be send down the path. When a PATH message containing a Label Request Object arrives at an LSR, the LSR allocates a label for upstream propagation and stores it as part of the path state. When the corresponding RESV message arrives, the label is placed in its Label Object.
The Label Object is carried in RESV messages. For FF and SE styles, a label is associated with each sender. The Label Object carries a label, and when an LSR receives a RESV message it uses the label as the outgoing label associated with the sender. The LSR allocates a new label, or uses the label allocated and stored in path state as a result of the Label Request Object, and places it in the Label Object of the RESV message to be sent to the previous hop. In this way, the Label Object supports the distribution of labels from downstream nodes to upstream nodes.

69. Record Route Object— PATH Message
Added to PATH message by ingress LSR
Adds outgoing IP address of each hop in the path
In downstream direction
Loop detection mechanism
Sends “Routing problem, loop detected” PathErr message
Drops PATH message
The Record Route Object can be added to Path messages to allow the sender to receive information about the actual path the LSP traverses. Each node along the path records its IP address in the RRO, and the RRO is returned to the sender in Resv messages.

70. Session Attribute Object
Added to PATH message by ingress router
Controls LSP
Priority
Preemption
Fast-reroute
Identifies session
ASCII character string for LSP name
The Session Attribute Object can be added to the Path message to control LSP priority, preemption, and fast-reroute.

71. Adjacency Maintenance—Hello Message
New RSVP extension: leverage RSVP for hellos!
Hello message
Hello Request
Hello Acknowledge
Rapid node to node failure detection
Asynchronous updates
3 second default update timer
12 second default dead timer

72. Path Maintenance — Refresh Messages
Maintains reservation of each LSP
Sent every 30 seconds by default
Consists of PATH and RESV messages

73. RSVP Message Aggregation
Bundles up to 30 RSVP messages within single PDU
Controls
Flooding of PathTear or PathErr messages
Periodic refresh messages (PATH and RESV)
Enhances protocol efficiency and reliability
Disabled by default

74. Traffic Engineering: Constrained Routing

75. Signaled vs Constrained LSPs
Common Features
Signaled by RSVP
MPLS labels automatically assigned
Configured on ingress router only
Signaled LSPs
CSPF not used (I.e. normal IP routing is used)
User configured ERO handed to RSVP for signaling
RSVP consults routing table to make next hop decision
Constrained LSPs
CSPF used
Full path computed by CSPF at ingress router
Complete ERO handed to RSVP for signaling

76. Constrained Shortest Path First Algorithm
Modified “shortest path first” algorithm
Finds shortest path based on IGP metric while satisfying additional QoS constraints
Integrates TED (Traffic Engineering Database)
IGP topology information
Available bandwidth
Link color
Modified by administrative constraints
Maximum hop count
Bandwidth
Strict or loose routing
Administrative groups
The ingress router determines the physical path for each LSP by applying a Constrained Shortest Path First (CSPF) algorithm to the information in the TED. CSPF is a shortest-path-first algorithm that has been modified to take into account specific restrictions when calculating the shortest path across the network. Input into the CSPF algorithm includes:
Topology link-state information learned from the IGP and maintained in the TED
Attributes associated with the state of network resources (such as total link bandwidth, reserved link bandwidth, available link bandwidth, and link color) that are carried by IGP extensions and stored in the TED
Administrative attributes required to support traffic traversing the proposed LSP (such as bandwidth requirements, maximum hop count, and administrative policy requirements) that are obtained from user configuration
As CSPF considers each candidate node and link for a new LSP, it either accepts or rejects a specific path component based on resource availability or whether selecting the component violates user policy constraints. The output of the CSPF calculation is an explicit route consisting of a sequence of router addresses that provides the shortest path through the network that meets the constraints. This explicit route is then passed to the signaling component, which establishes forwarding state in the routers along the LSP.

77. Computing the ERO Ingress LSR passes user defined restrictions to CSPF
Strict and loose hops
Bandwidth constraints
Admin Groups
CSPF algorithm
Factors in user defined restrictions
Runs computation against the TED
Determines the shortest path
CSPF hands full ERO to RSVP for signaling

78. Summary: Key Benifits of MPLS
Goal: Low-overhead virtual circuits for IP
Originally designed to make routers faster by leveraging ATM switch cores (bypasses IP-over-ATM overlay problems)
Fixed label lookup faster than longest match used by IP routing
Caveat: Not true anymore!
IP forwarding has broken terabit/s speeds through innovative data-structures (next class) !
PPP-over-SONET (POS) provides a link layer!
Value of MPLS is now purportedly in “traffic engineering”
Same forwarding mechanism can support multiple new services (eg: VoIP, VPNs etc)
Allows network resource optimization at the level of routing (eg: constrained based routing)
Allow survivability and fast-reroute features…
Can be generalized for optical networks (G-MPLS)
It is commonly believed that Multiprotocol Label Switching (MPLS) significantly enhances the forwarding performance of label-switching routers. It is more accurate to say that exact-match lookups, such as those performed by MPLS and ATM switches, have historically been faster than the longest match lookups performed by IP routers. However, recent advances in silicon technology allow ASIC-based route-lookup engines to run just as fast as MPLS or ATM virtual path identifier/virtual circuit identifier (VPI/VCI) lookup engines.
The real benefit of MPLS is that it provides a clean separation between routing (that is, control) and forwarding (that is, moving data). This separation allows the deployment of a single forwarding algorithm—MPLS—that can be used for multiple services and traffic types.
In the future, as ISPs need to develop new revenue-generating services, the MPLS forwarding infrastructure can remain the same while new services are built by simply changing the way packets are assigned to an LSP. For example, packets could be assigned to a label-switched path based on a combination of the destination subnetwork and application type, a combination of the source and destination subnetworks, a specific quality of service (QoS) requirement, an IP multicast group, or a VPN identifier. In this manner, new services can easily be migrated to operate over the common MPLS forwarding infrastructure.