1. MPLS: Application Scenarios for INFN
Netgroup Meeting
Nov
Netgroup, Nov
MPLS Application Scenarios for INFN

2. MPLS Application Scenarios for INFN
Outline
Introduction to MPLS
MPLS VPNs
MPLS DiffServ
GMPLS
Scenarios
Some experimental results
Netgroup, Nov
MPLS Application Scenarios for INFN

3. MPLS Application Scenarios for INFN
MPLS Overview
In a network based on a connectionless network layer protocol, each router makes an independent forwarding decision for that packet. That is, each router analyzes the packet's header, and each router runs a network layer routing algorithm. Each router independently chooses a next hop for the packet, based on its analysis of the packet's header and the results of running the routing algorithm.
Choosing the next hop can therefore be thought of as the composition of two functions.
The first function partitions the entire set of possible packets into a set of "Forwarding Equivalence Classes (FECs)".
The second maps each FEC to a next hop. All packets which belong to a particular FEC and which travel from a particular node will follow the same path.
In conventional IP forwarding, a particular router will typically consider two packets to be in the same FEC if there is some address prefix X in that router's routing tables such that X is the "longest match" for each packet's destination address. As the packet traverses the network, each hop in turn reexamines the packet and assigns it to a FEC.
In MPLS, the assignment of a particular packet to a particular FEC is done just once, as the packet enters the network.
The FEC to which the packet is assigned is encoded as a short fixed length value known as a "label".
In the MPLS forwarding paradigm, once a packet is assigned to a FEC, no further header analysis is done by subsequent routers; all forwarding is driven by the labels.
Netgroup, Nov
MPLS Application Scenarios for INFN

4. MPLS Application Scenarios for INFN
Advantages
MPLS forwarding can be implemented by switches responsible of doing label lookup and replacement (but not capable of supporting routing)
the ingress router may use, in determining the assignment, any information it has about the packet, even if that information cannot be gleaned from the network layer header (e.g. packets arriving on different ports may be assigned to different FECs). Conventional forwarding, on the other hand, can only consider information which travels with the packet in the packet header.
Sometimes it is desirable to force a packet to follow a particular route which is explicitly chosen at or before the time the packet enters the network, rather than being chosen by the normal dynamic routing algorithm as the packet travels (e.g. to support traffic engineering). In conventional forwarding, this requires the packet to carry an encoding of its route along with it ("source routing"). In MPLS, a label can be used to represent the route.
The packet label can also determine a packet's "precedence" or "class of service". In this case, the label represents the combination of a FEC and a precedence or class of service.
Netgroup, Nov
MPLS Application Scenarios for INFN

5. MPLS Application Scenarios for INFN
Some terminology
Label : a short fixed length physically contiguous identifier which is used to identify a FEC, usually of local significance.
Label merging: the replacement of multiple incoming labels for a particular FEC with a single outgoing label.
MPLS domain: a contiguous set of nodes which operate MPLS routing and forwarding and which are also in one Routing orAdministrative Domain.
Labeled packet: is a packet into which a label has been encoded.
The label can reside in an encapsulation header which exists specifically for this purpose.
The label may reside in an existing data link or network layer header, as long as there is a field which is available for that purpose. The particular encoding technique to be used must be agreed to by both the entity which encodes the label and the entity which decodes the label.
Label distribution protocol: a set of procedures by which one LSR informs another of the label/FEC bindings it has made. Several LDP protocols can coexist.
Netgroup, Nov
MPLS Application Scenarios for INFN

6. MPLS Application Scenarios for INFN
Label
| Label | EXP |S| TTL |
Non-MPLS Domain
MPLS Domain
IPv4 Packet
MPLS Hdr
Prec: xyz
Prec: xyz
Netgroup, Nov
MPLS Application Scenarios for INFN

7. Some terminology (cont)
LDPs:
Piggypacking of label information on BGP-4
Constraint-Based LSP Setup using LDP
LDP Specification
Extensions to RSVP for LSP Tunnel
Label stack: labeled packet carries a number of labels, organized as a last-in, first-out stack.
Next Hop Label Forwarding Entry: used when forwarding a labeled packet. It contains the following information:
the packet's next hop,
the operation to perform on the packet's label stack; this is one of the following operations:
replace the label at the top of the label stack with a specified new label,
pop the label stack,
replace the label at the top of the label stack with a specified new label, and then push one or more specified new labels onto the label stack.
It may also contain:
d) the data link encapsulation to use when transmitting the packet
e) the way to encode the label stack when transmitting the packet.
Netgroup, Nov
MPLS Application Scenarios for INFN

8. Generic MPLS Encapsulation
One way to encode the label stack is to define a new protocol to be used as a "shim" between the data link layer and network layer headers.
This shim would really be just an encapsulation of the network layer packet;
it would be "protocol-independent" such that it could be used to encapsulate any network layer. Hence we will refer to it as the "generic MPLS encapsulation".
Netgroup, Nov
MPLS Application Scenarios for INFN

9. MPLS Application Scenarios for INFN
Aggregation
One way of partitioning traffic into FECs is to create a separate FEC for each address prefix which appears in the routing table. However, within a particular MPLS domain, this may result in a set of FECs such that all traffic in all those FECs follows the same route.
For example, a set of distinct address prefixes might all have the same egress node, and label swapping might be used only to get the traffic to the egress node. In this case, within the MPLS domain, the union of those FECs is itself a FEC.
The procedure of binding a single label to a union of FECs which is itself a FEC (within some domain), and of applying that label to all traffic in the union, is known as "aggregation".
Aggregation may reduce the number of labels which are needed to handle a particular set of packets, and may also reduce the amount of label distribution control traffic needed.
Netgroup, Nov
MPLS Application Scenarios for INFN

10. MPLS Virtual Private Networks
Netgroup, Nov
MPLS Application Scenarios for INFN 10

11. Virtual Private Networks
Definition:
“a generic term used to refer to the capability of both private and public networks to support a communication infrastructure connecting geographically dispersed sites where users can communicate among them as if they were in a private network” (RFC 2764)
Netgroup, Nov
MPLS Application Scenarios for INFN

12. MPLS Application Scenarios for INFN
Layer-3 to Layer-1 VPNs
Layer-3:
They interconnect sets of hosts and routers based on Layer-3 addresses (e.g. IP addresses)
Layer-2:
They emulate the functionality of a Local Area Network in a wide area environment
Layer-1:
They connect a number of Customer Edge devices with point-to-point connections operated at Layer-1, based either on optical or Time Division Multiplexing network infrastructures.
Netgroup, Nov
MPLS Application Scenarios for INFN

13. Layer 2 -Virtual Private Services
Customer traffic is mapped to a specific MPLS L2 VPN by configuiring L2 FEC based upon:
Input port ID
VLAN ID
Pseudo-wire: L2 point-to-point MPLS VPN
Virtual Private LAN Services (VPLS)
provides connectivity to geographycally dispersed customers as if they where connected to the LAN
E.g. Ethernet and VLAN 802.1q traffic
Benefits:
No separate layer 2 equipment
VPN service over an existing IP and MPLS backbone
Interoperability issues (RSVP vs LDP)
Netgroup, Nov
MPLS Application Scenarios for INFN

14. Layer 2 and 3 VPNs configuration
Signalling protocol is enabled on Provider Edge routers;
An IGP protocol on the PE and Provider Routers is configured;
An IBGP session is configured between the PE routers;
The vpn routing instance is configured on the PE router
Deployed today as basis of the Managemed Bandwidth Service in GEANT
LSP connections can be set up manually or dynamically (e.g. through RSVP, dynamic configuration not supported in the GEANT network).
Netgroup, Nov
MPLS Application Scenarios for INFN

15. MPLS Application Scenarios for INFN
MPLS DiffServ
Netgroup, Nov
MPLS Application Scenarios for INFN
Presentation_ID
© 1999, Cisco Systems, Inc. 15

16. Differentiated Services Field (RFC 2474)
DS field
DSCP CU
DS field replaces IPv4 ToS, IPv6 Traffic Class
DiffServ CodePoint = 6 bits : “xxxxxx” notation
CU: Currently Unused
Netgroup, Nov
MPLS Application Scenarios for INFN

17. DiffServ Architecture (1/6)
SLS/TCS
0. Negotiation and agreement of an Service Level Specification/Traffic Conditioning Specification
Netgroup, Nov
MPLS Application Scenarios for INFN

18. DiffServ Architecture (2/6)
1. Pre-marking in the source domain
- by the source end-node
- by the Customer Edge router
Netgroup, Nov
MPLS Application Scenarios for INFN

19. DiffServ Architecture (3/6)
SLS/TCS
2. Egress- boundary DiffServ node of source domain applies traffic conditioning to ensure SLS/TCS compliance, hence causing possible re-marking, dropping and shaping
Netgroup, Nov
MPLS Application Scenarios for INFN

20. DiffServ Architecture (4/6)
SLS/TCS
3. Classification according to SLS
4. Conditioning according to TCS
5. Assignment to a BA (DSCP setting)
Netgroup, Nov
MPLS Application Scenarios for INFN

21. DiffServ Architecture (5/6)
6. Forwarding according to PHB mapped to set DSCP
Netgroup, Nov
MPLS Application Scenarios for INFN

22. DiffServ Architecture (6/6)
SLS’/TCS’
If downstream DS domain support same service provisioning policy, same Per Hop Behaviours and DSCP/PHB mappings
Then 7: apply traffic conditioning to enforce SLS/TCS
Else 7’a: SLS’/TCS’ negotiation
7’b: Conditioning according to TCS’
Netgroup, Nov
MPLS Application Scenarios for INFN

23. MPLS Application Scenarios for INFN
Colouring MPLS Frames
Problem: at the ingress of an MPLS network how to convey information about the PHB associated to an incoming IP packet in order to preserve class membership information?
Two methods are possible
EXP bits: they are part of the MPLS shim header; the mapping of DSCPs to EXP codes need to be defined
convenient for Frame-based Interface
MPLS label: for each Forwarding Equivalence Class, different MPLS labels are used to carry IP traffic associated to different Classes of Service
convenient for ATM-based interface
Netgroup, Nov
MPLS Application Scenarios for INFN

24. MPLS Application Scenarios for INFN
Using the EXP bits
Copy of Precedence (from ex-TOS IP header filed) into EXP
Mapping of DSCP into EXP (6-bit filed vs 3-bit field)
| Label | EXP |S| TTL |
Non-MPLS Domain
MPLS Domain
IPv4 Packet
MPLS Hdr
Prec: xyz
MPLS EXP: xyz
Prec: xyz
Netgroup, Nov
MPLS Application Scenarios for INFN

25. MPLS Application Scenarios for INFN
Label-inferred CoS
| Label | EXP |S| TTL |
DSCP to Label mapping
Dest-CoS Label
FEC_i CoS
IPv4 Packet
FEC_i CoS
FEC_i CoS
Prec: xyz
FEC_i CoS
Netgroup, Nov
MPLS Application Scenarios for INFN

26. MPLS Application Scenarios for INFN
GMPLS
Netgroup, Nov
MPLS Application Scenarios for INFN

27. MPLS Application Scenarios for INFN
GMPLS Rationale
Need some control plane for OXCs
Similarities between optical channels and traffic engineered LSPs suggest to use MPLS for OXCs
MPLS control plane is standards-based and IP-centric
Facilitate integration with IP routers & LSRs (paves way for incorporation of DWDM multiplexers on IP routers)
Support traffic engineering functions
Interoperability among diverse devices (routers, switches, ADMs, OXCs etc.)
Provide standards based, multi-vendor interoperability within an optical transport network
Netgroup, Nov
MPLS Application Scenarios for INFN

28. LSR/OXC and LSP/lambda commonalities
Data plane driven by a switching table
LSR: (iif, ingress label)  (oif, egress label)
OXC: (iif, ingress )  (oif, egress )
Switching independent of switching unit payload
LSR & OXC switch based on Label or Lambda
need not recognise packet boundaries or process packet headers (for example if the LSP is realized by an ATM virtual circuit)
LSP/lambda:
unidirectional and point-to-point
Same label/lambda cannot be allocated twice on an interface
Netgroup, Nov
MPLS Application Scenarios for INFN

29. Label Switching Routers Edge Label Switching Routers
MPLS Network
Label Switching Routers
(Router or ATM Switch)
Edge Label Switching Routers
Netgroup, Nov
MPLS Application Scenarios for INFN

30. MPLS Application Scenarios for INFN
GMPLS Network
Lambda
Switching
Router
Lambda
Switching
Router
OLSR
Lambda Switching
Edge Router
Lambda Switching
Edge Router
Lambda
Switching
Router
Lambda
Switching
Router
Lambda
Switching
Router
Lambda Switching
Edge Router
MPL(ambda)S Domain
Fiber with WDM
Netgroup, Nov
MPLS Application Scenarios for INFN

31. Optical Label Switch Router (OLSR)
OCP
OXC
IP Routing and
Signaling
DWDM
tightly-coupled OCP and OXC creates an Optical Label Switch Router
runs IP and MPLS protocols - MPLaS, GMPLS
switches at Fiber and Lambda Level
Netgroup, Nov
MPLS Application Scenarios for INFN

32. MPLS Application Scenarios for INFN
Three classes of OXCs
F-OXC
Fiber-to-fiber
Wavelength
routing
WR-OXC
Wavelength
translating
WT-OXC
Netgroup, Nov
MPLS Application Scenarios for INFN

33. MPLS Application Scenarios for INFN
GMPLS: Introduction
MPLS has been extended to include other LSR types whose forwarding decisions are not based on packets but times slots, wavelengths or physical port numbers.
Hence the notion of LSP has been generalized to:
FSC (fiber switch capable) LSP,
LSC (Lambda Switch Capable) LSP,
TDM LSP.
LSP must start and end on LSR of the same type
New forms of labels are required (also called generalized label) characterized by (see also next slide):
link protection type,
LSP encoding,
LSP payload.
Netgroup, Nov
MPLS Application Scenarios for INFN

34. MPLS Application Scenarios for INFN
G-MPLS Label Request
Example shown is carried in RSVP PATH message
Link Prot. (Protection) Type
desired protection scheme of link
e.g. 1+1, 1:N, ring, etc.
LSP Encoding Type
encoding of LSP
e.g. DS3, GE, Lambda, SONET, etc.
Netgroup, Nov
MPLS Application Scenarios for INFN

35. MPLS Application Scenarios for INFN
G-MPLS Label
Example shown is carried in RSVP RESV message
Link ID
identifies which component link (out of several possible) that label will be allocated on
Label
different formats for fiber, waveband, lambda, TDM and packet
Netgroup, Nov
MPLS Application Scenarios for INFN

36. Some G-MPLS Label Formats
SDH
Wavelength
Waveband
Netgroup, Nov
MPLS Application Scenarios for INFN

37. Application scenarios
Netgroup, Nov
MPLS Application Scenarios for INFN

38. MPLS Application Scenarios for INFN
1. Security and privacy
VPNs can offer security and privacy to applications (e.g. file transfers across Grids) even when relying on data-access protocols that do not guarantee integrity and confidentiality
MPLS Layer-2/Layer-3VPNs can support data isolation by separating, for each VPN, the forwarding control plane, the signalling and the routing information in the intermediate forwarding devices
In addition: with Layer-2 VPNs remote sparse resources can be connected as if they were part of the same LAN
Netgroup, Nov
MPLS Application Scenarios for INFN

39. MPLS Application Scenarios for INFN
2. Quality of Service
VPNs can offer different traffic forwarding behaviors to traffic across the shared public infrastructure. This is achieved by associating a priority level to the traffic exchanged on specific tunnel instances and by enabling the differentiation mechanisms (Differentiated Services)
Advantages (e.g. in case of Grid applications):
Guaranteed bandwidth (e.g. file transfer by deadline, virtual leased line)
Virtual closeness realized between CEs and SEs in remote sites, thanks to the availability of QoS  closeness has to be enabled in the Grid Information Service
Resource discovery in job scheduling gives higher preference to compute resources that are close to the input data
Efficient workload distribution: use of compute resources in small Grid sites
Overall traffic load reduced at the Grid network bottlenecks
and: traffic engineering
Netgroup, Nov
MPLS Application Scenarios for INFN

40. MPLS Application Scenarios for INFN
3. High-speed point-to-point connections for HEP data replication (GMPLS – future)
Very high-speed connectivity between few well-defined Grid nodes can be used to assist the replication of large data files in a wide area Grid.
The use of a dedicated high-speed communication channel avoids contention of multiple flows and improves the efficiency of reliable transport protocols such as TCP
Netgroup, Nov
MPLS Application Scenarios for INFN

41. Experimental activities
Netgroup, Nov
MPLS Application Scenarios for INFN

42. MPLS Application Scenarios for INFN
DataTAG
Context:
DataTAG project ( CERN, INFN, INRIA, PPARC, Uni. of Amsterdam
And: Karlsruhe, DFN, GARR and GEANT NOC
Netgroup, Nov
MPLS Application Scenarios for INFN

43. Physical network set-up (DataTAG demo)
GARR
Backup line
2.4 Gbps
CERN
Backup line
2.4 Gbps .
Dedicated
1 GEthernet interface .
GÉANT
GARR
DataTAG
CNAF
DataTag
CERN
Netgroup, Nov
MPLS Application Scenarios for INFN

44. MPLS-Based Layer-2 VPNs
Ethernet/VLAN traffic is carried by MPLS over the service provide network (PE and P routers) and then converted back to L2 format at the rx site
CE: it selects the output circuit to which specific L2 traffic has to be sent according to:
the VLAN ID in the 802.1Q frame header (VLAN L2 VPN)
the input interface form which the frame was received (Ethernet L2 VPN)
Juniper, Circuit cross-conenct encapsulation
Netgroup, Nov
MPLS Application Scenarios for INFN

45. MPLS Application Scenarios for INFN
Example
CE2,1
SE2,1
Grid
Domain 2
SE2,2
CE2,2
CE1,1
SE1,1
CE1,2
SE3,1
CE3,1
SE1,2
CE1,3
Grid
Domain 3
SE3,2
CE3,2
Grid
Domain 1
SE3,3
CE3,3
SE3,4
CE3,4
VLAN X
VLAN Y
Netgroup, Nov
MPLS Application Scenarios for INFN

46. MPLS Application Scenarios for INFN
Why MPLS?
Interest in testing the technology
A given host can belong to one or more VPNs at a time if native VLAN tagging is enabled
The LSP primary/secondary path can apply non-standard routing policies
A given diffserv packet forwarding treatment can be assigned to the LSPs associated to a given VPN (MPLS EXP field set by the LSP head-end router):
Grid ftp between SEs: if based on enhanced TCP stacks, it can be handled through the Scavenger/Less Than Best Effort service (fairness)
CEs/SEs used for remote visualization with real-time requirements could apply to the IP Premium service
Performance guarantees to individual VOs
Netgroup, Nov
MPLS Application Scenarios for INFN

47. L2 VPNs and DataTAG: Dynamic Layer-2 VPN configuration
stm64
C7606
M10
3com
VLAN1, IP Premium
VLAN2 LBE/Scavenger
Adv Res&Resource Mgr/
Grid Information Service
Netgroup, Nov
MPLS Application Scenarios for INFN

48. Diffserv/MPLS Path Elements
Congestion
point
GÉANT
CERN
Juniper
M10
IP Premium, 300 Mbps, MPLS
Juniper
M10
LBE, Mbps MPLS
Netgroup, Nov
MPLS Application Scenarios for INFN

49. MPLS Application Scenarios for INFN
L2 dynamic VPNs
Grid014f,
Eth0
w04gva
VLAN 570
/26
IP Premium
User interface, GRIS, AA,
MPLS Manager
Eth1
GÉANT
VLAN 571
/27, LBE
GARR
fe-1/1/1
Datagrid4,
Juniper
M10
Juniper
M10
ge-0/1/0
ge-0/0/0
so-0/0/0
ge-1/0/0
Eth1
Eth1
3com
C7606
fe-1/1/1
Eth0
Eth1
VLAN 670
/24
IP Premium
Datagrid1,
w01gva
Netgroup, Nov
MPLS Application Scenarios for INFN

50. MPLS Application Scenarios for INFN
Reservation phases
Submission of user request through interface
Matchmaking, i.e. selection of resources (Path list) that satisfy the requests. Match on:
Path service (IP Premium, Less Than Best Effort, Best-effort)
Path type (Diffserv, Mpls, Lightpath)
Bandwidth (Path max bandwidth ≥ requested bandwidth)
Src/Dst host in Path Src/Dst domain
Authentication and authorization (Globus Gatekeeper of Path Element)
MPLS Manager:
Check for availability of resources over time
Router configuration when reservation starts
Create/modify/destroy
Netgroup, Nov
MPLS Application Scenarios for INFN

51. MPLS label switch paths and related connections
Grid014f
Eth0
w04gva
User interface, GRIS, AA,
MPLS Manager
VLAN 570
IP Premium
Eth1
VLAN 571, LBE
Datagrid4
Juniper
M10
Juniper
M10
ge-0/1/0
ge-1/0/0
Eth1
Eth1
Eth0
Eth1
VLAN 670
IP Premium
Datagrid1
w01gva
Netgroup, Nov
MPLS Application Scenarios for INFN

52. MPLS-based L2 VPN management: features
MPLS LSP:
unidirectional
based on a Diffserv path statically provisioned (IP Premium)
Connects the two CE routers of the two leaf domains
Shared by authorized users/applications generating traffic from the source domain
diffserv paths that support MPLS capabilities (across MPLS-capable transit domains) are indicated by the information system
Netgroup, Nov
MPLS Application Scenarios for INFN

53. MPLS-based L2 VPN management: implementation
Two given CE routers of two different leaf domains are connected by a single diffserv path of a given type (IP Premium, lbe etc)
Each MPLS/diffserv path is statically associated to a given pre-defined VLAN number
VLAN tagging pre-configured statically on end-systems
Router configuration:
Diffserv: marking and policing (IP Premium only) at the ingress router
MPLS L2 VPN: VLAN tagging and encapsulation, LSPs with QoS and CCC Connections (Juniper) on the LSP head-end router
Topology and routing: very difficult to mange dynamically!
Netgroup, Nov
MPLS Application Scenarios for INFN

54. MPLS Application Scenarios for INFN
Router configuration
MPLS L2 VPN Manager:
Perl application using Junoscript libraries (prototype for Juniper routers)
Configuration script parsing
possible operating system/configuration scripts mismatches
configuration errors (rollback)
Configuration add/modify/delete
Configuration locking
Netgroup, Nov
MPLS Application Scenarios for INFN

55. Conclusions & NRN requirements
Results:
Optimal TCP performance on MPLS L2 VPNs between StarLight and CERN – 1 Gbps
MPLS EXP field marking and classification: ok (Juniper)
Diffserv scheduling: ok
Requirements:
On-demand set-up of e2e MPLS LSPs (no stitching)
Handling of MPLS EXP field for QoS
Netgroup, Nov
MPLS Application Scenarios for INFN

56. MPLS Application Scenarios for INFN
Some references
Multiprotocol Label Switching Architecture, RFC 3031, Jan 2001.
Virtual Private LAN Service over MPLS, Lasserre, M. Et alt; work in progress.
MPLS CoS, Clarence Filsfils, CISCO, 1999.
Generalized MPLS Optical Control Plane, J.P. Vasseur, CISCO, 2000.
Netgroup, Nov
MPLS Application Scenarios for INFN