MPLS Layer-2 Virtual Private Networks

MPLS Layer-2 Virtual Private NetworksFoundry Networks Delivers Ethernet Services over MPLS

2001 Foundry Networks, Inc.Foundry Proprietary - MPLS Layer 2 VPNs2

Agenda

Foundrys Strategy for Supporting MPLS Layer-2 VPNs Providing Point to Point Connectivity

Specifications & Requirements The Virtual Leased Line (VLL) Service How It Works Application Examples

Providing Full Mesh Connectivity Service Terminology Specifications & Requirements How It Works Application Examples

Foundry Product Offering


Foundrys MPLS Vision/Strategy

Reduce the Burden of Network Administration and Address the Hyper-Aggregation Problem Implement MPLS Traffic Engineering for Route Management

and Data Flow Path Selection Extend Foundrys Global Ethernet Strategy (Layer 2 over SONET)

to Include MPLS-based Transport Systems Implement draft-Martini to Include Switched Ethernet

Infrastructures (MAN Deployments) into MPLS Environments Provide Complete Layer 2, Layer 3, and VPN Services over a

Common MPLS Core Implement Label Distribution Protocol (LDP) for Multi-vendor

Interoperability Offer both Virtual Leased Line and Virtual Private LAN

Segments (Transparent LAN Services)


Support For MPLS Layer-2 VPNs

Virtual Leased Line: The Martini drafts address point to point connectivity only.

However, this allows for offering a Virtual Leased Line (VLL) service

If multiple sites need to be connected, the provider has to provide multiple VLLs

Just like with leased line connectivity, packet switching is done by the subscribers equipment (the Customer Edge - CE device)

Virtual Private LAN Segment (Transparent LAN Services): Provides full mesh connectivity Connects CE equipment as if they were on the same LAN

segment


Agenda






Providing Point to Point Connectivity

Goal: To allow the provider to carry customer layer-2 frames from one endpoint to the other over an IP/MPLS infrastructure

Scenario:The provider offers a service that allows the customer to connect two CE devices at two sites as if they had a leased line between them

Draft-martini is the de facto standard, with some existing implementations Team will consolidate into WG document

Work will be done by two working groups Pseudo Wire Emulation Edge to Edge (PWE3) Provider Provisioned Virtual Private Networks (PPVPN)


Agenda






The Martini Drafts

The Martini drafts introduce the concept of Virtual Circuits (VCs)

Label Switched Paths (LSPs) are used as tunnels, an LSP might carry multiple VCs

To accomplish this, the drafts leverage the MPLS label stacking ability by adding an extra MPLS label that distinguishes the VC used

An MPLS frame traversing a service provider network has two labels: Tunnel Label VC Label

For the LSP

For the VC


The Martini Drafts

draft-martini-l2circuit-trans-mpls-07.txt Distribution of VC labels via Label Distribution Protocol (LDP) Introduces a new VC Forwarding Equivalency Class (FEC) Type

Length Value (TLV), to be used within Label Mapping messages

draft-martini-l2circuit-encap-mpls-03.txt Defines encapsulations for ATM, Frame Relay, Ethernet,

Ethernet VLAN, HDLC, and PPP

PPPor

Enet Hdr.

TunnelLabel

VCLabel

OptionalControlWord

Tagged or untagged Ethernet payload

Format for Ethernet/VLAN Encapsulation:


Agenda






The Virtual Leased Line (VLL) Service The mechanisms specified in the Martini drafts could

be used to offer a Virtual Leased Line (VLL) service for point to point connectivity

The Virtual Leased Line is just an abstraction of the Virtual Circuits involved in realizing the point to point connectivity, making the service more manageable

A VLL is composed of two VCs one in each direction, thus giving it bi-directionality

Provider Edge (PE)-A PE-B

LSPVC

VLL


Provisioning the Service A Virtual Leased Line is given a unique ID, called VLL

ID. The VLL ID is configured on both PE routers having the

end-points of the line On each PE router, the address of the other PE router

called VLL Peer is configured A PE router is configured to accept and forward either

untagged frames from the subscriber, or tagged frames with a certain VLAN ID

PE routers automatically negotiate VC Labels to be used using LDP

Optionally, the administrator may statically configure the VC Labels to be used


Agenda






VC Label Assignment

After a new VLL ID and its VLL-Peer is configured, the VLL controller dynamically assigns a local VC label This is the label for inbound packets to be forwarded to the

local CE end-point VC label is assigned from a label range that has per-platform

scope VC label range is separate from tunnel label range used by

RSVP

PE-A PE-B

Assign inbound VC label XFor VLL-ID 1000

Assign inbound VC label Yfor VLL-ID 1000


VC Label Signaling

The VLL controller Initiates a targeted LDP session to the VLL-Peer IP address Selects a tunnel LSP whose end-point is that VLL-Peer

LSP egress point address must match VLL-Peer address to be considered

However, if the remote and local VLL VC labels are statically configured, there is no need for the LDP session

PE-A PE-BPE-B can be reached by LSP # 10:outgoing tunnel label is M

PE-A can be reached by LSP # 20:outgoing tunnel label is L


VC Label Signaling (cont.)

Once all configurations are complete, a PE router sends an LDP Label-Mapping message to the other end (in downstream unsolicited mode)

The message indicates the binding of a local VC label (in Label TLV) to the VC FEC TLV (introduced by draft-martini)

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| VC tlv |C| VC Type |VC info Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Group ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| VC ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Interface parameters || " || " |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


VC Label Signaling (cont.)

PE router sends an LDP Label-Mapping message to the other end

May send Label-Withdraw message when local CE interface goes down

PE-A PE-B

I bind label X to VLLI bind label X to VLL--ID 1000ID 1000

I bind label Y to VLLI bind label Y to VLL--ID 1000ID 1000

Local label XRemote label Y Local label YRemote label X


Forwarding Frames:CE to Backbone

CE interfaceMPLS Backbone

Apply VC andtunnel labels

Inbound lookupbased on VLAN & port numberor just port number

PE-A

PPPor

Enet Hdr.

TunnelLabel

M

VCLabel

Y

OptionalControlWord


Outgoing MPLS Packet Format:


Forwarding Frames:Backbone to CE

CE interface

MPLS Backbone

PE-B

PPPor

Enet Hdr.

VCLabel

Y

OptionalControlWord


Incoming MPLS Packet Format in the General Case:

Incoming VC label Y indicates VLLpayload, which CE interface to send to, and which VLAN-ID to use

PPPor

Enet Hdr.

TunnelLabel

N1

VCLabel

Y

OptionalControlWord


Incoming MPLS Packet Format in Case of Pen-Ultimate Hop Popping:

1 Tunnel label is changed by transit LSRs on the path


Agenda






VLL Example Application:CE Device Handles Switching

Router at central location responsible for data forwarding among all remotes; switches or routers at remotes

Central Site Router

Multinettingw/ one subnetto each remote

VLL for subnet 1

VLL for subnet 2T

UT

UT

The VLAN-IDs on thesePEs are not required tomatch with the central sitePE

T: taggedUT: untagged

Remote

Remote


VLL Example Application:Service Provider Handles Switching

MPLS Backbone

Service Provider network

Customer 1Site A

One VLAN percustomer

Tagged interfaceshared among VLANs

Edge switches performSA learning, layer-2 frame forwarding, and STP

Customer 2Site C

Customer 1Site C

Customer 2Site A

Customer 2Site BCustomer 1

Site B


Agenda






Providing Full Mesh Connectivity

Building on the mechanisms specified in the Martini drafts

This functionality is currently under development Goal:

To handle the more general case of a Provider offering multiple point connectivity for a customer VPN

Scenario:The provider offers a service that allows the customer to connect multiple CE devices at multiple sites as if they were on one LAN segment

The service provider handles packet switching and offers the service in a manner that is totally transparent to the user


Service Provider View of the Service

PE-1

PE-3

PE-2

Customer ASite-3 CE Device


MPLS BackbonePrivate VLAN 10

Private VLAN 20

Private VLAN 10

Private VLAN 20

Private VLAN 10

Private VLAN 20

tagged


Virtual CircuitLSP Tunnel


Customers View of the Service

PE-3



Private VLAN 10

Private VLAN 20

Private VLAN 10

Private VLAN 20

Private VLAN 10

Private VLAN 20

tagged


Customers CE devices think that they are all in the same subnet and that they are connected through a switch


Agenda






Service Terminology

In this scenario, the provider is said to be offering:

A Virtual Private LAN Segment (VPLS)

or (alternative name):

A Transparent LAN Service Not to be confused with Virtual Private LAN Services which is an IP only solution described in

draft-tsenevir-vpl-ip-00.txt


Agenda






VPLS Defining Documents RFC 2764 A Framework for IP Based Virtual Private Networks:

Provides the general framework for IP Based VPNs MPLS included

draft-lasserre-tls-mpls-00.txt: Describes the forwarding of Ethernet/802.3 frames between

multiple customer sites, as if they were in the same layer-2 broadcast domain

Defines a new parameter VPN ID to identify PE routers participating in the same customer VPN

draft-vkompella-ppvpn-vpsn-mpls-00.txt: Describes MAC address learning and aging Describes MAC address signaling

A single Working Group (WG) document will be formulated


Functional Requirements

As frames are transported over a provider backbone, efficient use of resources is crucial

Frames should be forwarded only over the needed VCs PE routers should be capable of learning Ethernet

source MAC addresses, just like a regular switch A PE router keeps a VPLS Forwarding Table (quite

similar to a bridges MAC table) that distinguishes the entries belonging to the different VPNs

Before forwarding a frame, the PE router checks its VPLS forwarding table to determine which VCs the frame should go over


Functional Requirements (Cont.)

Broadcast or unknown unicast frames are flooded over all outgoing VCs belonging to the VPN

The PE routers have to be connected via VCs forming a full mesh topology

For loop prevention, running an instance of STP per VPN in the provider network would not scale: Solution:

When forwarding frames a PE follows a split-horizon rule: it never forwards a frame from one VC to another in the same VPN


Handling Multicast Frames

Multicast frames are currently handled like broadcasts Extensions for performing smarter multicasts are to be

developed in the future

Possible scenarios: Interaction with 802.1 GMRP IGMP snooping Static MAC multicast filters


Agenda






PE Router Performs Source Address Learning

PE-1

PE-3

PE-2



MPLS Backbone



SA=X VC Label=NVC Label=M

VPLS Forwarding Table

PE-3 associates MAC X with the outgoing VC (VC Label N)


PE Router Performs Forwarding

PE-1

PE-3

PE-2



MPLS Backbone



DA=X VC Label=NVC Label=M

VPLS Forwarding Table

PE-3 Checks its VPLS forwarding table and selects VC Label N

DA=X


Speeding up Convergence

For faster convergence: Whenever a PE router learns a new MAC SA from the

customer side, it signals it using an LDP Address message to its peers

Should a MAC SA age out or should the CE device get disconnected, the PE sends an LDP Address Withdraw message to its peers


MAC Signaling

PE-1

PE-3

PE-2



MPLS Backbone



LDP Msg

SA=Y

LDP

Msg

New MAC?Yes Notify peers.

PE-3 signals the new MAC to speed up convergence


Facilitating Provisioning

VPN membership: Each customer VPN is assigned a unique 7 octet

VPN ID It is defined as a new interface parameter included

in the LDP messages defined in the Martini drafts (VC FEC)

This allows PE routers to signal the VPNs they are members of

Automatic discovery of VPLS capable routers: IGP extensions might be used Still in the works


Agenda






VPLS Example Application:Providing TLS

PE-1

PE-3

PE-2

Customer ASite-1 Router


Customer BSite-3 Switch



MPLS BackbonePrivate VLAN 10

Private VLAN 20

Private VLAN 10

Private VLAN 20

Private VLAN 10

Private VLAN 20



T

T

T

UT

UT

UT

UT UntaggedT Tagged


VPLS Example Application:Dual Homing the Customer

PE-1PE-2

MPLS Backbone

STP

STP

STP

STP

STP

STP

No STP


STP used by the customer but not by the provider

The customer might run and manage their own instance of STP The provider does not run STP on their backbone, they just carry the

customers BPDUs

Customer ASite-2

Customer ASite-1 PE-3PE-4


Agenda






Empower Your MAN with MPLS

Foundry offers a complete MPLS solution for the cost of the nearest competitor!

Exclusive Wire-Speed Layer 2 VPNs Unmatched in the market space. The only vendor to offer a forklift free seamless migration path from

Layer 2 services right through to an MPLS enabled infrastructure. At 480 Gbps aggregated switching capacity, Foundry delivers the

industrys highest performance in the smallest form factor. Take advantage of a full suite of WAN interfaces including ATM, Packet

over SONET/SDH, and 10 Gigabit Ethernet. A complete End-to-end solution from ONE vendor providing the

unmatched Return on Investment (ROI): Consistent software development Common product look and feel Cisco-like Command Line Interface (CLI) across the entire product

line for a reduced learning curve


Foundry MAN Feature Set - Core Next Generation Routing Architecture

Effectively scales from 128 to 480 Gbps of switching capacity

High-performance, low-latency, and Head-of-Line Blocking-free packet forwarding

Fully distributed switching delivers best Price/Performance ratio

Robust Internet Routing Suite Full featured BGP4, OSPF, ISIS Comprehensive MPLS

RSVP/TE Draft-Martini

Wire-speed ACLs and Extended ACLs for Security and Control

RADIUS, AAA, TACACS, & TACACS+ support for Authentication and Verification

Investment Protection All modules seamlessly work across

all NetIron and BigIron chassis Consistent look and feel 10 Gbps Ready

Carrier-Class Features Hot-swap capability enables

components to be added or removed without service disruption

APS for SONET/SDH Redundant Route Processors with

sub-second fail over Redundant AC and/or DC Power

Load Balanced Hot Swappable

Level 3 NEBS Tested

Industry Leading High Density Interfaces

Packet over SONET/SDH ATM 10/100 Mbps Ethernet Gigabit Ethernet 10 Gbps Ethernet


Foundry MAN Feature Set - Edge

802.1w Rapid Spanning Tree Protocol (RSTP) for rapid convergence time of 1 to 5 seconds

802.1s STP per VLAN group provides VLAN and STP scalability, and utilizes dark fiber efficiently

Super VLAN Aggregation Decouples customer-side VLANs from service provider VLANs, and allows VPN like connectivity for 4,096 customers in the Metro core

SuperSpan Super Spanning Tree Protocol allows different STP domains for simplicity, manageability and dramatic improvements in Metro core network scalability

Layer 2 POS Allows Layer 2 VLAN services over existing SONET infrastructure to combine simplicity of Ethernet with reliability of SONET, and provide global VLANs in the Metro


Foundrys MAN Advantages

Complete Solution Layer 2 & 3 Switches and Internet routers with MPLS Traffic Engineering and Draft Martini with industry leading price/performance

Complete Interfaces 10/100 Mbps, 1 Gbps and 10 Gbps Ethernet, OC-3c, OC-12c and OC-48c PoS, and OC-3c ATM

Complete Network Management New IronView Network Manager for centralized management

Industrys First Wire-Speed Rate Limiting Next Generation ASICs provide fine-grain Committed Access Rate functionality

Complete Accounting NetFlow version 1, 5, and 8, Up to 10 collectors, Five aggregation schemes, sFlow and XRMON

IronShield Security Wire-speed ACLs, SYN and ICMP rate limiting, bi-directional NAT, Radius, TACACS/TACACS+ authentication

Thank You!