56
Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 1 MPLS: Application Scenarios for INFN Netgroup Meeting Nov 19 2004 [email protected]

Netgroup, Nov 19 2004MPLS Application Scenarios for INFN1 MPLS: Application Scenarios for INFN Netgroup Meeting Nov 19 2004 [email protected]

  • View
    213

  • Download
    0

Embed Size (px)

Citation preview

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 1

MPLS: Application Scenarios for INFN

Netgroup Meeting

Nov 19 2004

[email protected]

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 2

Outline

• Introduction to MPLS

• MPLS VPNs

• MPLS DiffServ

• GMPLS

• Scenarios

• Some experimental results

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 3

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 19 2004 MPLS Application Scenarios for INFN 4

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 19 2004 MPLS Application Scenarios for INFN 5

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 19 2004 MPLS Application Scenarios for INFN 6

Label

IPv4 Packet MPLS Hdr

Prec: xyz Prec: xyz

Non-MPLS Domain

MPLS Domain

0 1 2 30 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 |

Netgroup, Nov 19 2004 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:1. the packet's next hop,2. the operation to perform on the packet's label stack; this is one of the

following operations:a) replace the label at the top of the label stack with a specified new label,b) pop the label stack, c) 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 packete) the way to encode the label stack when transmitting the packet.

Netgroup, Nov 19 2004 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 19 2004 MPLS Application Scenarios for INFN 9

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 19 2004 MPLS Application Scenarios for INFN

MPLS Virtual Private Networks

10

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 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 19 2004 MPLS Application Scenarios for INFN 12

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 19 2004 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 802.3 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 19 2004 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 19 2004 MPLS Application Scenarios for INFN

MPLS DiffServ

15Presentation_ID © 1999, Cisco Systems, Inc.

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 16

Differentiated Services Field (RFC 2474)

• DS field replaces IPv4 ToS, IPv6 Traffic Class

• DiffServ CodePoint = 6 bits : “xxxxxx” notation

• CU: Currently Unused

DSCPDSCP CUCUDS fieldDS field

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 17

DiffServ Architecture (1/6)

0. Negotiation and agreement of an Service Level Specification/Traffic Conditioning Specification

SLS/TCS

Netgroup, Nov 19 2004 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 19 2004 MPLS Application Scenarios for INFN 19

DiffServ Architecture (3/6)

2. Egress- boundary DiffServ node of source domain applies traffic conditioning to ensure SLS/TCS compliance, hence causing possible re-marking, dropping and shaping

SLS/TCS

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 20

DiffServ Architecture (4/6)

3. Classification according to SLS

4. Conditioning according to TCS

5. Assignment to a BA (DSCP setting)

SLS/TCS

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 21

DiffServ Architecture (5/6)

6. Forwarding according to PHB mapped to set DSCP

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 22

DiffServ Architecture (6/6)

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’

SLS’/TCS’

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 23

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 19 2004 MPLS Application Scenarios for INFN 24

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)

IPv4 Packet MPLS Hdr

Prec: xyz Prec: xyzMPLS EXP: xyz

Non-MPLS Domain

MPLS Domain

0 1 2 30 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 |

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 25

IPv4 Packet

Prec: xyz

FEC_i CoS1 17

FEC_i CoS2 22

FEC_i CoS3 25

FEC_i CoS4 12

Dest-CoS Label

0 1 2 30 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-inferred CoS

• DSCP to Label mapping

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 26

GMPLS

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 27

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 19 2004 MPLS Application Scenarios for INFN 28

LSR/OXC and LSP/lambda commonalities

• LSR/OXC:– 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 19 2004 MPLS Application Scenarios for INFN

MPLS Network

Label Switching Routers(Router or ATM Switch)

Edge Label Switching Routers

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 30

GMPLS Network

Lambda SwitchingEdge Router

Lambda SwitchingEdge Router

Lambda SwitchingEdge Router

LambdaSwitchingRouter

LambdaSwitchingRouter

MPL(ambda)S Domain

Fiber with WDM

LambdaSwitchingRouter

LambdaSwitchingRouter

LambdaSwitchingRouter

OLSR

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 31

Optical Label Switch Router (OLSR)

OCP

OXC

IP Routing andSignaling

IP Routing andSignaling

DW

DM

DW

DM

• tightly-coupled OCP and OXC creates an Optical LabelSwitch Router

• runs IP and MPLS protocols - MPLaS, GMPLS• switches at Fiber and Lambda Level

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 32

Three classes of OXCs

F-OXC

WR-OXC

WT-OXC

Fiber-to-fiber

Wavelengthrouting

Wavelengthtranslating

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 33

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 19 2004 MPLS Application Scenarios for INFN 34

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 19 2004 MPLS Application Scenarios for INFN 35

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 19 2004 MPLS Application Scenarios for INFN 36

Some G-MPLS Label Formats

SDH

Wavelength

Waveband

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 37

Application scenarios

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 38

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 19 2004 MPLS Application Scenarios for INFN 39

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 19 2004 MPLS Application Scenarios for INFN 40

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 19 2004 MPLS Application Scenarios for INFN 41

Experimental activities

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 42

DataTAG• Context:

– DataTAG project (http://www.datatag.org/): CERN, INFN, INRIA, PPARC, Uni. of Amsterdam

– And: Karlsruhe, DFN, GARR and GEANT NOC

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 43

Physical network set-up (DataTAG demo)

DataTAGCNAF

GARR GÉANT DataTagCERN

GARRBackup line

2.4 Gbps

CERNBackup line

2.4 Gbps

......

Dedicated 1 GEthernet interface

Netgroup, Nov 19 2004 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 19 2004 MPLS Application Scenarios for INFN 45

Example

SE1,1

SE1,2

CE1,1

CE1,2

CE1,3

SE2,1

SE2,2

CE2,1

CE2,2

SE3,1

SE3,2

CE3,1

CE3,2

SE3,3

SE3,4

Grid Domain 1

Grid Domain 3

Grid Domain 2

CE3,3

CE3,4

VLAN X

VLAN Y

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 46

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 19 2004 MPLS Application Scenarios for INFN 47

L2 VPNs and DataTAG:Dynamic Layer-2 VPN configuration

C7609T320T320

stm64

C7606M10M10

3com

VLAN1, IP Premium

VLAN2 LBE/Scavenger

Adv Res&Resource Mgr/Grid Information Service

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 48

Diffserv/MPLS Path Elements

JuniperM10

JuniperM10

GÉANT

LBE, 1-1000 Mbps MPLS

IP Premium, 300 Mbps, MPLS

CERN

Congestionpoint

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 49

L2 dynamic VPNs

JuniperM10

JuniperM10

GARR GÉANT

3com C7606

Grid014f, 131.154.99.104

Datagrid4, 131.154.99.68

Datagrid1, 131.154.99.32 w01gva

w04gva

Eth1192.91.239.21

Eth0192.168.1.1

Eth1192.91.238.102

Eth1192.91.238.104

Eth0192.91.239.4

ge-1/0/0so-0/0/0ge-0/0/0ge-0/1/0

Eth1192.168.1.2

VLAN 570192.91.239.0/26IP Premium

VLAN 571 192.91.238.96/27, LBE

VLAN 670192.168.1.0/24IP Premium

User interface, GRIS, AA,MPLS Manager

fe-1/1/1

fe-1/1/1

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 50

Reservation phases

1. Submission of user request through interface

2. 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

3. Authentication and authorization (Globus Gatekeeper of Path Element)

4. MPLS Manager:1. Check for availability of resources over time

2. Router configuration when reservation starts1. Create/modify/destroy

Netgroup, Nov 19 2004 MPLS Application Scenarios for INFN 51

MPLS label switch paths and related connections

JuniperM10

JuniperM10

Grid014f

Datagrid4

Datagrid1 w01gva

w04gva

Eth1192.91.239.21

Eth0192.168.1.1

Eth1192.91.238.102

Eth1192.91.238.104

Eth0192.91.239.4

ge-1/0/0ge-0/1/0

Eth1192.168.1.2

VLAN 570IP Premium

VLAN 571, LBE

VLAN 670IP Premium

User interface, GRIS, AA,MPLS Manager

Netgroup, Nov 19 2004 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 19 2004 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 19 2004 MPLS Application Scenarios for INFN 54

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 19 2004 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 19 2004 MPLS Application Scenarios for INFN 56

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.